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.

1. 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?

2. What internal buffering, frame/field timing, or other factors could explain this difference?

3. 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?

4. 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.