For a project I setup a rcorder project to ingest a videostream via DeckLink HDMI/AJA HDMI and directly encode it in to ProRs (Which is super neat to have btw.)
The Problem of course comes in the form of NTSC and th dredded 59.94 Hz.
For testing purposes I setup a little testbed based on the Roland XS1HD as the source, set to 59.94 Frames and an animatd tstimage coming directly from the image.
After some testing I cam to the conclusion to run th projct with vSync disabled and set th project to a cookRate of 59.94 (which I think is new that this is even possible, so thanks here too) which resulted in no skipped or repeated frames. (Would love to use an external clock but having an internal clock in sync with the video signal is fine.)
When setting the cookRate to 60 Hz i get sometimes and increased Frame Quee Length and of course skipped and repeated frames. But thanks to the excelent feedback in form of the measurements I was able to nail that down.
The problem comes in form of DirectMedia/MediaFoundation and/or our ELgato HD60-X.
This piece of “consumer” hardware is not having it at all with 59.94 CR at all, resulting in erratic behaviour between skipped and repeated frames and strange “SpeedUps” and slow downs in the outputfile.
The only way for me to get a stable output and no skipping/repeating is to set the CR to 60.
But, now the outputfile, which is at 60Hz now, has dropped/repeated frames. The issue is that they do not get reported at all! (but are expected, sure.)
So at some point somewhere in the chain the signal is silently converted from 59.94Hz to 60Hz by repeating a frame every now and then, which makes the Elgato card (and I assume all other Direct/Foundation accessed devices) not fit for professional production use. Question is if this is happening in TDs implementation or even before that.