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

[Marton Balint]

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?)

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

Thanks,
Marton