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

Jonathan Morley jmorley at pixsystem.com
Tue Jul 17 15:52:18 EEST 2018


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 <dheitmueller at ltnglobal.com> wrote:
> 
> 
>> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



More information about the ffmpeg-devel mailing list