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

Dave Rice dave at dericed.com
Mon Jun 4 21:07:50 EEST 2018

> On Jun 4, 2018, at 12:24 PM, Marton Balint <cus at passwd.hu> wrote:
> On Fri, 1 Jun 2018, Dave Rice wrote:
>>> On May 31, 2018, at 5:29 PM, Marton Balint <cus at passwd.hu> wrote:
>>> On Thu, 31 May 2018, Jonathan Morley wrote:
>>>> Thank you for the clarification, Dave. It might be that the Blackmagic approach to collecting timecode doesn’t work for that one source because it is in the horizontal space (HANC) instead of the vertical (VANC). I am not sure. Sadly I don’t think my solution is all encompassing, but it does seem to help in enough cases I would like to get it integrated with master.
>>>> I am still a bit thrown about the initial “Unable to set timecode” error, but believe it to be initialization related. I will wait to hear back from Marton on my overall approach and see what I can do to clean that up.
>>> av_dict_set returns < 0 on error, so the condition seems wrong.
>>>> As for the other error message my plan is to demote that to a debug.
>>> That is a good idea.
>> +1
>>> On the other hand, I believe the usefulness of this is in its current form is still very limited, because typically the first few frames are NoSignal frames, how the end user supposed to know which frame is the one with the first valid timecode?
>> In my testing the timecode value set here has corrected been associated with the first video frame (maintaining the timecode-to-first-frame relationship as found on the source video stream). Although only having first timecode value known is limiting, I think this is still quite useful. This function also mirrors how BlackMagic Media Express and Adobe Premiere handle capturing video+timecode where only the first value is documented and all subsequent values are presumed.
> Could you give me an example? (e.g. ffmpeg command line?)

./ffmpeg -timecode_format vitc2 -f decklink -draw_bars 0 -audio_input embedded -video_input sdi -format_code ntsc -channels 8 -raw_format yuv422p10 -i "UltraStudio 3D" -c:v v210 -c:a aac output.mov

This worked for me to embed a QuickTime timecode track based upon the timecode value of the first frame. If the input contained non-sequential timecode values then the timecode track would not be accurate from that point onward, but creating a timecode track based only upon the initial value is what BlackMagic Media Express and Adobe Premiere are doing anyhow.

>>> I'd rather see a new AVPacketSideData type which will contain the timecode as a string, so you can set it frame-by-frame.
>> Using side data for timecode would be preferable, but the possibility that a patch for that may someday arrive shouldn’t completely block this more limited patch.
> I would like to make sure the code works reliably even for the limited use case and no race conditions are affectig the way it works.

Feel welcome to suggest any testing. I’ll have access for testing again tomorrow.

More information about the ffmpeg-devel mailing list