Video Timings
When outputting video from d3, we can use various timing methods. A timing method is a set of parameters that define aspects such as:
- Horizontal blanking: The interval between the end of one line and the start of the next.
- Vertical blanking: The interval between frames.
The values for these parameters can vary depending on the chosen method.
Considerations for video timings
Section titled “Considerations for video timings”-
The type of timing used may need to be compatible with downstream devices to ensure a specific type of timing will be understood at the other end. For example, some monitors may not display the video at all if the timing format is unsupported.
-
The video timing will adjust the amount of data the video stream requires, so if devices are limited on bandwidth, then some timing modes may not be able to be used.
Timing mode selection in the Feed screen
Section titled “Timing mode selection in the Feed screen”In the Feed screen, users can select the timing mode for each output, provided it’s an HDMI or DisplayPort VFC, or a direct output (e.g. from the EX range). The available timing modes are:
- SMPTE
- CVT
- CVT Reduced Blanking (CVT-RB)
- CVT Reduced Blanking 2 (CVT-RB2)
- AUTO
How AUTO timing works
Section titled “How AUTO timing works”When AUTO is selected for one or more outputs, d3 will attempt to find a common timing method across all outputs. This provides more chance of achieving genlock across different VFC types and generally smoother output requiring less single output adjustments to stay synchronised. We do this in two passes.
First pass
Section titled “First pass”The first pass will simply find the best timing method for each single output by testing each method in the following order until one fits within the bandwidth constraints of the output type:
- DMT (not directly selectable)
- SMPTE (CEA)
- CVT
- CVT-RB
- CVT-RB2
Each output type has a different bandwidth limit. For example:
- DisplayPort 1.4: ~26 Gbps
- DisplayPort 1.2: ~17 Gbps
- HDMI 2.0: ~14.4 Gbps
- DVI: ~8 Gbps
Higher resolutions, frame rates, bit depths and colour formats require more bandwidth, which can affect the timing mode the first pass selects.
Second pass
Section titled “Second pass”On the second pass d3 will find the best timing method, which was chosen in the first path and which is within the bandwidth limit for all AUTO outputs and assign all of them that method.
Combining AUTO timing with chosen timings
Section titled “Combining AUTO timing with chosen timings”If there are outputs with chosen (non-AUTO) timings mixed with outputs using AUTO timing, d3 will use the chosen timing on each AUTO output where it fits within the bandwidth limit of that output. If it exceeds the bandwidth limit, we fall back on choosing a timing using the first pass process.
If more than one specific timing method is used, d3 will choose the higher-ranking method for the outputs using AUTO. Higher ranking is decided by how many outputs are using it, and then the order of best to worst is described above. For example, if we have four outputs and two are assigned CVT-RB and one is assigned SMPTE and one AUTO, the AUTO output will be assigned CVT-RB. If we have four outputs and one is CVT-RB, one SMPTE and two AUTO, d3 will assign the AUTO outputs to SMPTE because it’s ranked higher than CVT-RB.
Bandwidth and colour format
Section titled “Bandwidth and colour format”The colour format also affects bandwidth usage:
- RGB Full (RGB 4:4:4), RGB Limited, YCbCr 4:4:4: ~3 bytes per pixel
- YCbCr 4:2:2: ~2 bytes per pixel
- YCbCr 4:2:0: ~1.5 bytes per pixel
Passthrough vs non-passthrough VFCs
Section titled “Passthrough vs non-passthrough VFCs”-
With passthrough VFCs (e.g. HDMI, DP), the timing mode set on the GPU output via EDID is passed directly to the connected device.
-
With non-passthrough VFCs (e.g. QSDI, QDVI, IP), we convert the GPU timing mode:
- QSDI: The GPU uses CVT-RB, while the QSDI VFC outputs use SMPTE/CEA, which is standard for SDI devices.
- IP cards: Typically use CVT-RB2, unless running under 25fps, where CVT or AUTO might be used.
We do not currently support genlocking IP outputs with other VFCs, but this is a planned improvement that we hope to make available in future.
Genlock Basics
Section titled “Genlock Basics”Genlock is the process of synchronising the display of each frame on each output of a machine to an external clock signal. This external signal is typically distributed to multiple machines, allowing them to stay in perfect sync — essential for multi-display or multi-machine setups.
A similar concept applies to internal genlock, also known as framelock, where one output on a machine acts as the timing master, and the other outputs synchronise to it.
Key Points:
-
Synchronisation Scope: Genlock applies only to outputs that are outputting nearly identical amounts of data. This means the resolution, frame rate, and format must match across all outputs being genlocked.
-
Resolution Limitations: Attempting to genlock outputs using different resolutions usually results in failure — typically, only one will successfully genlock while others will not.
-
Output Type: Genlock operates at the GPU output level, not at the VFC (Video Format Converter) output level. So synchronisation happens before any format conversions are applied downstream.
Genlock ensures that multiple displays or machines present frames in lockstep, which is crucial for seamless visuals in video walls, immersive environments, or high-end simulation systems. But to work properly, all genlocked outputs must match in resolution and timing characteristics.
Read more about Genlock Configuration here.
Timing Differences
Section titled “Timing Differences”When using different timings across outputs, the amount of data being transmitted can vary enough that genlock no longer works — even if the resolution is the same. This is because genlock relies not only on resolution, but also on how data is clocked out of the outputs.
It’s common to encounter genlock issues when using different VFCs in the same machine. Different VFCs often default to different timing modes depending on the output type, which can disrupt genlock synchronisation.
Troubleshooting
Section titled “Troubleshooting”1. Avoid Mixing Incompatible Timing Modes
Section titled “1. Avoid Mixing Incompatible Timing Modes”Genlock requires outputs to use very similar timings, not just the same resolution and frame rate.
If one output is using SMPTE and another uses CVT, genlock may fail even if the resolutions match.
Solution: Manually set a consistent timing mode (e.g. CVT or CVT-RB2) across all outputs.
Do not leave any outputs on AUTO if you are using different VFC types.
2. Be Cautious When Mixing VFC Types
Section titled “2. Be Cautious When Mixing VFC Types”Some VFC types (e.g. QSDI or IP-VFC) use fixed timing modes internally (such as CVT), while others (like HDMI or DP) allow timing selection.
If mixing passthrough cards (e.g. HDMI + DP):
- Choose a specific timing manually for each.
If mixing passthrough and non-passthrough cards:
- Try aligning GPU timings manually to match the known default of the non-passthrough card (e.g. CVT for QSDI).
3. SMPTE Timing May Not Genlock with Some Cards
Section titled “3. SMPTE Timing May Not Genlock with Some Cards”If you’re using SMPTE timing on an HDMI or DP output and cannot genlock with other VFCs (e.g. QSDI), try switching to:
- CVT-RB when pairing with QSDI
- CVT-RB2 when pairing with IP-VFC
4. Check for Bandwidth Conflicts
Section titled “4. Check for Bandwidth Conflicts”For high resolutions (especially with DP1.4 or 4K outputs), the selected timing mode must also be within the bandwidth limits of the VFC.
A timing mode that exceeds the card’s capabilities will fail silently or block genlock.
5. Use Consistent Output Settings Across Machines
Section titled “5. Use Consistent Output Settings Across Machines”If synchronising multiple machines, make sure:
- The same timing mode, resolution, and framerate is used across all outputs that require genlock.
- Avoid AUTO timing modes in multi-machine setups unless fully matched.