Hello Aximmetry Support Team,
We would like to ask about two latency-related issues in our genlocked camera tracking environment.
Aximmetry: 2026.3.1 (Build 39093)
Edition: Broadcast & Film Edition, using Aximmetry's native rendering engine (no Unreal Engine)
OS: Windows 11 Home 25H2
CPU / GPU / RAM: Intel Core Ultra 7 265K / NVIDIA GeForce RTX 5080 / 32 GB
Video I/O: DeckLink 8K Pro (Desktop Video 16.2), used for both SDI input and output
Video format: 1920×1080 / 1080i59.94 (59.94 fields/s)
Genlock: Black Burst (BB)
Tracking: Shotoku SPI-Touch / SPI-BOX, Free-D at 59.94 Hz
Free-D connection: BUFFALO RS422-to-USB serial converter, 38400 baud
USB serial latency timer: 2 ms
Tracking Delay: 0.8 frames, adjusted to align the CG movement timing with the camera video
All video equipment and the tracking system are synchronized to the same BB reference, including the Free-D update timing.
We measured the actual delay between the original camera image and Aximmetry's SDI output.
We recorded both the original camera feed and Aximmetry's SDI output on separate channels of an external recorder.
The external recorder was genlocked, and the timecodes for both recordings were recorded using the same timecode reference.
There was no fixed recording delay between the two channels.
We identified corresponding image frames in the two recordings and counted the frame difference.
The results were:
In-to-Out Latency | Input Extra Delay | Measured Video Delay
7 frames | 2 frames | 7 frames
4 frames | 2 frames | 5 frames
Input Extra Delay was kept at 2 frames in both measurements.
When In-to-Out Latency was set to 7 frames, the measured delay was also 7 frames.
However, when it was set to 4 frames, the measured delay was 5 frames.
With the "Every input is genlocked" preset, Input Extra Delay was initially set to 0.3 frames.
However, the CG showed visible jitter during camera movement at this setting.
We had to increase Input Extra Delay to approximately 2 frames to obtain stable CG tracking.
This behavior was observed with the USB serial latency timer set to 2 ms.
The Free-D data was received successfully.
We have also confirmed with the tracking equipment manufacturer that the Free-D output rate is 59.94 Hz and that its update timing is synchronized to the BB reference.
Is it normal for the actual video delay to exceed the configured In-to-Out Latency by 1 frame, as observed with the 4-frame setting?
What internal buffering, frame/field timing, or other factors could explain this difference?
Even when both the video equipment and Free-D tracking are genlocked, is it normal to require approximately 2 frames of Input Extra Delay to avoid CG jitter?
What is the recommended procedure for minimizing Input Extra Delay without introducing CG jitter or compromising tracking stability? In particular, how can we determine whether the need for approximately 2 frames is caused by serial data transfer, buffering, or the timing relationship between video and tracking inputs?
We would appreciate your advice on optimizing latency and tracking stability in this configuration.
Best regards.
Hi titleabo,
1. & 2.
We ran tests in-house and successfully reproduced what you experienced.
We found that the mismatch between the set and the measured In-to-Out Latency comes down to performance.
Under high CPU load, lower latency values can’t be maintained, so the actual latency ends up larger: at a certain load value, we measured 5 frames of delay when 4 frames was set and 7 frames when 7 was set.
When we increased the load further, both measured values were larger than the ones set.
When we decreased the load, both measured values matched up with the set values.
Try reducing your CPU load to fix this. You can monitor the exact value in Composer's ProcessorLoad panel in the bottom right corner.
3. & 4.
The need for a large Input Extra Delay is probably hardware-related, and your serial converter could be the cause.
You mentioned in a previous post that you use the Shotoku VR pedestal, and this tracking system can send data over IP.
We recommend using that connection instead, then checking whether the issue is solved.
Warmest regards,
Adam