> On Jun 6, 2018, at 4:50 PM, Marton Balint <[email protected]> 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
_______________________________________________
ffmpeg-devel mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
