Ah yeah that makes a lot of sense, Devin. I will keep that in mind for the ntv2 avdevice I created for use with our Kona4.
I basically copied the exact structure of the decklink libavdevice as my starting point anyway. It isn’t nearly as flexible and focuses exclusively on capture (demuxing), but I had the advantage of making something that exactly fit our needs for now. If things work out I would like to do a generalization pass and see if I can contribute it back here however unlikely it is that others would use AJA hardware with ffmpeg. Thanks for the information! > On Jul 16, 2018, at 12:23 PM, Devin Heitmueller <dheitmuel...@ltnglobal.com> > wrote: > > >> 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
