I would like to emphasize how important this is with simple example I have put together. This is a quick sketch of setup I have used for following example.
(EDIT: Ah, I have spotted that there is AUX instead of ANC on the image. Sorry about that.)
Here you can see that I am using professional camera and blackmagic video i/o card. Both devices use the same tri-level sync signal as input reference - to ensure they have exactly the same “clock” and no drift is happening between them.
The camera has dedicated timecode input - when used, camera is embedding this external timecode into SDI ancillary data (lets call this VITC for now, even though I am not 100% sure if these ancillary data contain timecode embedded as VITC, but I guess they are) - this is the data TD can’t read at the moment.
Apart from dedicated TC input, camera also has XLR audio input (for generic microphones). LTC plugged into this port gets embedded into one SDI audio channel.
Here comes the fun part. You can see that I have utilized both of these inputs in order to demonstrate problems with LTC in audio channel. I would like to show that decoding LTC from audio inside of TD isn’t stable and in certain situations could make whole timecode based synchronization very problematic… In following examples I am comparing timecode decoded from audio channel (LTC) with timecode embedded in SDI ancillary data (VITC).
Since TD can’t read VITC, I have configured SDI video output on camera in a way that is renders external timecode information on top of video feed. This way we can be 100% sure that video frame that we get from Blackmagic i/o card is correctly stamped with corresponding VITC information (even though it is baked into video signal, but that is fine for this test ).
Now we can decode LTC from audio and compare it to VITC. Please feel free to take a look at this video to see both timecodes side by side (white is VITC, yellow is LTC, trail is showing LTC).
Please note that project on video is running at 50fps, while timecode is 25fps (this is absolutely normal situation as SMPTE doesn’t define anything above 30fps - therefore when having 50fps project, you have to use 25fps timecode). Please also note that due to my very simple LTC offset compensation (this is more of a “deep” LTC topic and I won’t go into detail what is happening there), there are incorrect numbers reported on limit values (frame 50 should be 0) - but this isn’t really a problem in this case, you can just ignore it.
If you observe reported values closely, you can see that there are moments where LTC drifts away from VITC and then, after a while, it gets back to correct values again.
So the question becomes - why is this happening? I believe there are two common cases that cause such behavior. One is V-Sync and the other one is drop-frame situation. When you have V-Sync enabled, audio input buffer in TD (provided by Blackmagic) is likely to “drift” on various UI related events, or even without them.
Take a look at this video or this one to see how is the buffer literally “drifting” back and forth. This behavior causes LTC sync word to arrive at different frame once drift occurs - resulting in incorrect timecode. This makes it impossible to use LTC decoding with V-Sync. Sometimes it is possible to go without using V-Sync in entire project, but this isn’t always the case. Take a look here to see the same setup with V-Sync disabled (no drift occurs).
As I have said previously, this also happens on drop-frame situations. This means that if you have a frame-drop, audio will drift for a short time until it “snaps back into place”. This again renders decoding LTC in audio channel (provided by Blackmagic video i/o) useless. All of this could be resolved by implementing reading VITC values directly from Blackmagic i/o (or AJA).
I am sorry for such a long read, but I wanted to let you know why it is important (and it became quite long since it is a complitaced topic). I don’t think this is a problem with TD - it is just a way audio is being handled in general (please correct me if I am wrong)… If you know about any way of completely eliminating the drift in input audio buffer, I would be more than happy to try it out. But for now I feel like VITC is the way to go. Thanks for reading.