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

[Dave Rice]

> On Jun 6, 2018, at 4:50 PM, Marton Balint <cus at passwd.hu> wrote:
> 
> On Mon, 4 Jun 2018, Dave Rice wrote:
> 
>> 
>>>> 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.
>> 
> 
> Hmm, either the decklink drivers became better in hinding the first few NoSignal frames, or maybe that issue only affected to old models? (e.g. DeckLink SDI or DeckLink Duo 1). I did some test with a Mini Recorder, and even the first frame was useful, in this case the timecode was indeed correct.
> 
>>>>> 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.
> 
> I reworked the patch a bit (see attached), and added per-frame timcode support into the PKT_STRINGS_METADATA packet side data, this way the drawtext filter can also be used to blend the timecode into the frames, which seems like a useful feature.


That sounds helpful.

libavdevice/decklink_dec.cpp:734:21: error: unknown type name 'DECKLINK_STR'
                    DECKLINK_STR decklink_tc;

Dave