Hi Marton et al, I am revisiting this now that I have access to the BlackMagic DeckLink Duo again. I see what made it into master and had a few questions.
1) Can you please explain more about storing the timecodes as side packet data in each video packet? Basically is there some convention among demuxers and muxers to handle that specific metadata? 2) Is there any reason not to make a valid timecode track (ala AVMEDIA_TYPE_DATA AVStream) with timecode packets? Would that conflict with the side data approach currently implemented? I have found that (much as you originally predicted) my original approach relies on what could generously be called a race case. Since I was using the decklink demuxer to feed the movenc format writer I was relying on having set the timecode metadata on the video stream before either mov_init or mov_write_header get called (since those two functions create the timecode track for “free” if they detect the metadata initially). This is not really a deterministic approach and seems to be worse than making a valid timecode stream to begin with. What I am trying to understand now is if there is any overlap in responsibility between the video packet side data approach and creating a dedicated timecode data stream. Please let me know what you think. Thanks, Jon > On Jun 12, 2018, at 3:27 PM, Marton Balint <c...@passwd.hu> wrote: > > > > On Tue, 12 Jun 2018, Dave Rice wrote: > >> >>> On Jun 7, 2018, at 5:01 PM, Marton Balint <c...@passwd.hu> wrote: >>> On Thu, 7 Jun 2018, Dave Rice wrote: >>> [...] >>>> 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. >>>> 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. >>> Well, the way I understand it, deckcontrol is using a totally different >>> timecode source: the RS422 deck control interface. In contrast, the >>> timecode capture in the patch is using the SDI (video) source. >>> If the deck does not put the LTC timecode into SDI line 10, then the driver >>> won't be able to capture it if you specify 'rp188ltc'. I am not sure >>> however why 'serial' does not work, but from a quick look at the SDK maybe >>> that only works if you use the deck control capture functions… >> > >> I see at >> https://forum.blackmagicdesign.com/viewtopic.php?f=12&t=71730&p=400097&hilit=bmdTimecodeSerial#p400097 >> >> <https://forum.blackmagicdesign.com/viewtopic.php?f=12&t=71730&p=400097&hilit=bmdTimecodeSerial#p400097> >> that capturing bmdTimecodeSerial is an issue there too, so this is likely >> an issue with the sdk rather than with your patch. Otherwise I’ve been >> testing this more and find it really useful. Hope to see this merged. > > Pushed, thanks for testing. > > Regards, > Marton > _______________________________________________ > 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
