> On Jun 7, 2018, at 12:12 PM, Dave Rice <d...@dericed.com> wrote:
> 
> 
>> On Jun 6, 2018, at 5:32 PM, Marton Balint <c...@passwd.hu> wrote:
>> 
>> On Wed, 6 Jun 2018, Dave Rice wrote:
>> 
>>>> On Jun 6, 2018, at 4:50 PM, Marton Balint <c...@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
>>  
>> <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180526/185eb219/attachment.obj>
> 
> Thanks for the update. I continued testing and found this very useful, 
> particularly with the side data.
> 
> Before I only tested with vitc but now have a serial cable connected as well 
> and found a source tape that has distinct values for LTC and VITC timecodes. 
> The LTC values are from 1:00:00 to 2:00:00 and the VITC values are from 
> 07:00:00 - 08:00:00.

Realized a mix up here, in the samples below VITC values are in 1:00:00 to 
2:00:00 and the LTC values are from 07:00:00 - 08:00:00

> With the deckcontrol utility at https://github.com/bavc/deckcontrol 
> <https://github.com/bavc/deckcontrol>, I can use the command gettimecode to 
> grab the LTC value:
> 
> deckcontrol gettimecode
> Issued command 'gettimecode'
> TC=07:37:56:21
> Command sucessfully issued
> Error sending command (No error)
> 
> With these patches, I can only grab the vitc values:
> 
> for i in rp188vitc rp188vitc2 rp188ltc rp188any vitc vitc2 serial ; do echo 
> -n "${i}: " ; ./ffprobe -v quiet -timecode_format "$i" -f decklink -draw_bars 
> 0 -audio_input embedded -video_input sdi -format_code ntsc -channels 8 
> -raw_format yuv422p10 -i "UltraStudio Express" -select_streams v 
> -show_entries stream_tags=timecode -of default=nw=1:nk=1 ; echo ; done
> rp188vitc: 
> rp188vitc2: 
> rp188ltc: 
> rp188any: 
> vitc: 01:41:44;06
> vitc2: 01:41:44;21
> serial: 
> 
> Also it may be interesting in cases like this to support accepting multiple 
> timecode inputs at once, such as "-timecode_format vitc+rp188ltc” though it 
> would need to be contextualized more in metadata.
> 
> With a serial cable connected, I can access LTC via the deckcontrol utility 
> but not with this patch.
> 
> ./ffprobe -timecode_format rp188ltc -v debug -f decklink -draw_bars 0 
> -audio_input embedded -video_input sdi -format_code ntsc -channels 8 
> -raw_format yuv422p10 -i "UltraStudio Express"
> ffprobe version N-91240-g3769aafb7c Copyright (c) 2007-2018 the FFmpeg 
> developers
>  built with Apple LLVM version 9.0.0 (clang-900.0.38)
>  configuration: --enable-libfreetype --enable-nonfree --enable-decklink 
> --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include 
> --disable-muxer=mxf --disable-demuxer=mxf
>  libavutil      56. 18.102 / 56. 18.102
>  libavcodec     58. 19.105 / 58. 19.105
>  libavformat    58. 17.100 / 58. 17.100
>  libavdevice    58.  4.100 / 58.  4.100
>  libavfilter     7. 25.100 /  7. 25.100
>  libswscale      5.  2.100 /  5.  2.100
>  libswresample   3.  2.100 /  3.  2.100
> [decklink @ 0x7fe2b8003000] Trying to find mode for frame size 0x0, frame 
> timing 0/0, field order 0, direction 0, mode number 0, format code ntsc
> [decklink @ 0x7fe2b8003000] Found Decklink mode 720 x 486 with rate 29.97(i)
> [decklink @ 0x7fe2b8003000] Using 8 input audio channels
> [decklink @ 0x7fe2b8003000] Unable to find timecode.
>    Last message repeated 5 times
> [decklink @ 0x7fe2b8003000] Probe buffer size limit of 5000000 bytes reached
> Input #0, decklink, from 'UltraStudio Express':
>  Duration: N/A, start: 0.000000, bitrate: 229869 kb/s
>    Stream #0:0, 5, 1/1000000: Audio: pcm_s16le, 48000 Hz, 8 channels, s16, 
> 6144 kb/s
>    Stream #0:1, 6, 1/1000000: Video: v210, 1 reference frame (V210 / 
> 0x30313256), yuv422p10le(bottom first), 720x486, 0/1, 223725 kb/s, 29.97 fps, 
> 29.97 tbr, 1000k tbn, 1000k tbc
> 
> ./ffprobe -timecode_format serial -v debug -f decklink -draw_bars 0 
> -audio_input embedded -video_input sdi -format_code ntsc -channels 8 
> -raw_format yuv422p10 -i "UltraStudio Express"
> ffprobe version N-91240-g3769aafb7c Copyright (c) 2007-2018 the FFmpeg 
> developers
>  built with Apple LLVM version 9.0.0 (clang-900.0.38)
>  configuration: --enable-libfreetype --enable-nonfree --enable-decklink 
> --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include 
> --disable-muxer=mxf --disable-demuxer=mxf
>  libavutil      56. 18.102 / 56. 18.102
>  libavcodec     58. 19.105 / 58. 19.105
>  libavformat    58. 17.100 / 58. 17.100
>  libavdevice    58.  4.100 / 58.  4.100
>  libavfilter     7. 25.100 /  7. 25.100
>  libswscale      5.  2.100 /  5.  2.100
>  libswresample   3.  2.100 /  3.  2.100
> [decklink @ 0x7fb086003000] Trying to find mode for frame size 0x0, frame 
> timing 0/0, field order 0, direction 0, mode number 0, format code ntsc
> [decklink @ 0x7fb086003000] Found Decklink mode 720 x 486 with rate 29.97(i)
> [decklink @ 0x7fb086003000] Using 8 input audio channels
> [decklink @ 0x7fb086003000] Unable to find timecode.
>    Last message repeated 5 times
> [decklink @ 0x7fb086003000] Probe buffer size limit of 5000000 bytes reached
> Input #0, decklink, from 'UltraStudio Express':
>  Duration: N/A, start: 0.000000, bitrate: 229869 kb/s
>    Stream #0:0, 5, 1/1000000: Audio: pcm_s16le, 48000 Hz, 8 channels, s16, 
> 6144 kb/s
>    Stream #0:1, 6, 1/1000000: Video: v210, 1 reference frame (V210 / 
> 0x30313256), yuv422p10le(bottom first), 720x486, 0/1, 223725 kb/s, 29.97 fps, 
> 29.97 tbr, 1000k tbn, 1000k tbc
> 
> Thanks,
> Dave Rice
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to