Output Sync Test

Understanding Output Synchronisation

Output synchronisation ensures that multiple outputs from a Disguise server, and outputs from multiple servers, render in perfect alignment. It is essential for delivering a seamless visual experience, particularly in live events and XR applications.

When servers are not correctly synchronised this will often appear as tearing as illustrated in the image below:

Tearing between two outputs as viewed on a screen

Understanding the two key methods for achieving output synchronisation is important. These are Framelock and Genlock.

Additionally, if issues arise, it is crucial to follow a precise and scientific testing methodology to ensure accurate troubleshooting.

Key Components

• Framelock:A GPU-based mechanism that synchronises individual outputs within the same server to prevent visual inconsistencies. See the Network Status Widget page.

• Genlock: A synchronisation method that aligns multiple devices to a shared clock source, enabling coordination between Disguise servers and external equipment such as cameras and LED displays. See the Genlock Configuration page.

Testing Methodology

Disguise offers a few simple, easy and effective methods to test output synchronisation, troubleshoot issues, and ensure a flawless performance

Disguise Network Widget

Next to each server in the Network Status Widget there are indicators for Network Status, Genlock Status and Framelock Status. You can hover over each icon to see the sub-status that determines it’s colour. All these status icons should be green in a correctly synchronised system.

The Network Status icon will indicate several statuses. The one most relevant to output synchronisation is “Transport control status”. This must be “In sync” to ensure output synchronisation.

Server FPS

In the bottom right-hand side of the Designer GUI you will see the current FPS of each server in your cluster. If any of these values are not at the target refresh rate this means that that server is “dropping frames” because it is working too hard to keep up. While dropping frames, outputs will not be synchronised.

You can hover over any FPS value to see which server it is referring to. You can also see a list of swerver FPS values in the Network Status Widget.

Basic Colour Layer Test

This test can be used to eliminate variables outside of the XR workflow and verify that a simple shape is outputted across all outputs of a server and additionally check upstream systems such as LED Processors.

To run the Basic Colour Layer Test:

Create a simple colour layer with a keyframe of brightness repeating up and down.

When the output is directed to a range of monitors, it demonstrates the Disguise system’s capability to synchronise video playback. However, if the video appears out of sync across multiple machines, it could indicate an improper Genlock configuration.”

Reducing Variables

To ensure synchronisation, every device in the chain must be Genlocked or Framelocked. If the Disguise system can output video in sync to 2, 3, or 4 LED monitors, but issues like tearing or out-of-sync playback occur when connected to your XR stage or LED processors it indicates that either a converter or an LED processor is not correctly Genlocked. By reducing the number of converters and variables, we can identify which device is not correctly configured.

Performing due diligence here will help validate the core video architecture in your system before moving on to advanced workflows.

XR Workflow Testing

Once video playback has been guaranteed as part of our previous test, we can begin to look at XR workflows. See the Video Receive Delay page.

Completing the Delay Calibration in the XR workflow should now be possible with a single frame of white.

• Camera/LED Genlock: Verify that the camera and LED devices are correctly Genlocked. Most devices usually refer to this a G/LOCK or EXT SYNC. Please see your devices manual in how to observe if its receiving external lock

• Frame Rates: Ensure that all devices are operating at the same frame rate. Ensure that camera devices are setup to the same Genlock source.

• Camera Settings Shutter speed and angle are important to ensure that only a single frame of delivery is captured. These workflows are outlined in the XR workflow guides.

• Clustered rendering: If RX nodes or clusters of Engines are rendering different frames, this can also look like tearing.

It is important to narrow down whether this is the Disguise Video playback, core servers or the render nodes.

Narrowing this down to the colour test will then help you determine if engines are out of sync or if its simply the core system.

Troubleshooting

• Tearing: If tearing occurs, it suggests synchronisation issues. Check frame rates, Genlock settings, and network connections. Is this down to a render node or a core video output system?

• Strobe Layers and Generative Effects: Be aware that these effects may not synchronize across Disguise machines. You should avoid using STROBE/RADAR and CHEVRONS as a method of sync testing.

• Disguise Readout test: Whilst we eluded to both Framelock and Genlock, Disguise also communicates between machines to verify what the current time/frame is and whether displays are in Framelock.

A support engineer may ask you to use the READOUT layer mapped to each screen, filming this in slow motion can be used to provide more scientific data for our team to observe and look at.

Please contact support@disguise.one if you are having issues with output sync.

	Definition	Must be the same to sync
iFrame (Frame number)	Frame index d3 start since d3 start.	Yes
tRender (Seconds)	The frame on the playhead that the local machine is currently rendering.	Yes
tRunning	Starts counting up once you hit play, & resets when you transition from stop to play – similar/same to tRender.	Yes, must be same unless dropping frames
deltaTime	Difference between now and last frame in time, this should equal to 1 fps.	Yes, must be same, unless dropping frames
deltaBeats	Difference between now and last frame in beats, similar/same to deltaTime.	Yes, must be same, unless dropping frames
timerMode	- Network Mode - Normal Mode - Fixed Mode	Yes, must be set as Network
actualTime	Local timer since startup.	No, does not need to be same
frameTime	The time of the last frame update.	Yes, should always be in sync when Genlocked. If not, ensure Genlock is still working on all servers.
actualFrameTime	The time of the last frame update in local machine time.	No, does not need to be same