Timecode Drifts on Aximmetry Gateway

We are attempting to implement multi-camera virtual production operation using Aximmetry DE Composer 2025.1 running on multiple EC2 instances in AWS, with Aximmetry Gateway 2025.1.

A Timecode Master has been prepared, and timecode is embedded into both VITC and LTC fields of the SDI signal via Videotron MUX-70U.


Over several days, while monitoring the Timecode value in the Video In node, I noticed timecode drift occurring on multiple machines.

I reset the Timecode Master and changed the Timecode sent to the Gateway, but the timecode visible in the Composer's Video In remained unchanged.

The following are the troubleshooting steps attempted:

・Toggling the Gateway's TimecodeMaster check - did not fix it

・Unplugging and replugging the SDI cable - did not fix it

・Reselected the SDI input device: Fixed

・Stopped and restarted the Gateway service: Fixed

The Gateway application had been running continuously for about 4-5 days.

I want to confirm whether this phenomenon of timecode synchronization breaking is a known issue and what countermeasures exist.

   Satoshi Watanabe

Comments

Eifert@Aximmetry
  -  

Hi Satoshi,

Unfortunately, the Gateway's documentation was a bit misleading regarding what the Timecode Master does, which might have caused some confusion. We have now corrected the documentation to clarify this point. The Timecode Master does not perform any syncing.

  • If Timecode Master is checked, the timecode from the selected video input will be used as the timecode source for all video streams.
  • If Timecode Master is unchecked, Aximmetry’s base timecode will be used as the source for all video streams.

I'm not sure under what circumstances or where you experienced timecode drift. However, if you want to synchronize every video input to each other based on timecode, it would be very hard to do with a multi-machine setup running on multiple EC2 instances in AWS. Instead, you would need to perform the timecode synchronization on another computer or device that receives all the final outputs.
In that scenario, as long as your video sources are already connected to a timecode/genlock source, they should arrive at the capture card simultaneously. Therefore, there should not be any issue with Gateway overwriting their timecode.

Note that timecode synchronization between tracking data and video sources is a separate topic. You can manage this within Gateway using the tracking panel's TC sync option. Further information can be found here: https://aximmetry.com/learn/virtual-production-workflow/starting-with-aximmetry/aximmetry-gateway/using-aximmetry-gateway/#camera-tracking 

Changing the Timecode Master while a stream is running will not work for various reasons. To apply such changes or to reset the timecode, you will likely need to stop and then start the stream again:

Warmest regards,

Satoshi Watanabe
  -  

Hi Eifert,

Thank you very much for your detailed explanation and for updating the documentation regarding the Timecode Master. I now understand that it does not perform synchronization, and that was very helpful.

However, I wasn’t trying to use it for synchronization. What I observed was that the timecode itself sometimes did not match the one embedded in the SDI signal, and I referred to this phenomenon as “drift.”
Since this occurred not only on a specific machine but across all Gateway machines, I wondered if there might be a specification-related limitation—such as a maximum duration for continuous operation during which timecode can be processed correctly. That’s why I reached out to ask.

I’d like to ask a follow-up question regarding the TC Sync option in the tracking panel.
From what I observed, the tracking data we receive does not seem to carry same timecode values, which makes me wonder: does TC Sync actually align the transmission timing of tracking data based on timecode, or is it performing a different kind of synchronization?
I’d appreciate it if you could clarify what exactly TC Sync is synchronizing—whether it’s aligning tracking data to video frames, or simply tagging data with timecode for reference.

Thanks again for your support!

Warm regards,

Eifert@Aximmetry
  -  

Hi Satoshi,

If you are not using a Master Timecode, the timecode will differ from the embedded timecode in the SDI signal, since Gateway will use its internal timecode.

However, the main issue (which I didn’t realize when I wrote my previous post) is that the maximum timecode value is 23:59:59:FF (24 hours) for almost every video format and SDI format. This means that if you use the timecode for anything longer than a day, you will encounter issues as they will likely reset the timecode and will start counting again from 0.


TC Sync aligns the tracking data with the video input’s frames based on their timecodes. To make this work, you need a timecode generator that supplies the same timecode to both your tracking device and your camera.
In cases where the same hardware is generating both the video and tracking data, such as a PTZ camera, the device may embed an identical timecode in both the tracking and video signals, since it is producing both streams.

Bottom line is that Aximmetry cannot tell your devices what timecode they should use and when. You usually need special hardware (
timecode generator) for that and connect that to your devices.

You can read more about Timecode Sync in the camera compound (which works similarly to the Gateway) here: 
https://aximmetry.com/learn/virtual-production-workflow/green-screen-production/tracked-camera-workflow/inputs-tracked-camera/#timecode-sync 

Warmest regards,