> On Jul 16, 2018, at 2:56 PM, Jonathan Morley <jmor...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
