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

[Marton Balint]

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.

Regards,
Marton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-avdevice-decklink_dec-capture-timecode-to-metadata-w.patch
Type: text/x-patch
Size: 8946 bytes
Desc: 
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180606/e749fb59/attachment.bin>