[FFmpeg-devel] [PATCH] Limited timecode support for lavd/decklink

[Devin Heitmueller]

> On Jul 16, 2018, at 2:56 PM, Jonathan Morley <jmorley at pixsystem.com> wrote:
> 
> That is really interesting feedback guys. I have been thinking about things mostly in a MOV independent timecode track (or tracks) kind of way, but I know OMF, MXF, AAF, etc handle it more analogously to packet/frame side data.
> 
> Usually ffmpeg has some kind of superset of functionality for handling any one concept in order to be able to handle all the various forms and implementations. I don’t really see that for timecode though I don’t really know what that would look like either. Especially given the compromises you both pointed out.
> 
> In my case it turned out that our Decklink Duo 2 was in a duplex state that caused the first few frames to get dropped and thus miss the opening of the output format timing wise. That is why it appeared to fail setting the timecode in the output container. We don’t really need that duplex mode (or the Decklink at all for that matter) so I think we are set for now.

I’ve run into this in my decklink libavdevice capture code for a number of other VANC types that result in streams having to be created (e.g. SMPTE 2038 and SCTE-104).  The way I approached the problem was to add an option to the demux to *always* create the stream rather than relying on the detecting the presence of the data during the probing phase.  This helps in the case where a few frames may be thrown away, as well as the case where actual data is not necessarily always present (such as SCTE-104 triggers).

Devin