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

[Marton Balint]

On Wed, 6 Jun 2018, Dave Rice wrote:

>
>> 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;

The patch I sent only replaces the second patch, the first one:

http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180526/185eb219/attachment.obj

is still needed.

Regards,
Marton