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

[Jonathan Morley]

Ah yeah that makes a lot of sense, Devin. I will keep that in mind for the ntv2 
avdevice I created for use with our Kona4.

I basically copied the exact structure of the decklink libavdevice as my 
starting point anyway. It isn’t nearly as flexible and focuses exclusively on 
capture (demuxing), but I had the advantage of making something that exactly 
fit our needs for now.

If things work out I would like to do a generalization pass and see if I can 
contribute it back here however unlikely it is that others would use AJA 
hardware with ffmpeg.

Thanks for the information!

> On Jul 16, 2018, at 12:23 PM, Devin Heitmueller  
> wrote:
> 
> 
>> On Jul 16, 2018, at 2:56 PM, Jonathan Morley  wrote:
>> 
>> That is really interesting feedback guys. I have been thinking about things 
>> mostly in a MOV independent timecode track (or tracks) kind of way, but I 
>> know OMF, MXF, AAF, etc handle it more analogously to packet/frame side data.
>> 
>> Usually ffmpeg has some kind of superset of functionality for handling any 
>> one concept in order to be able to handle all the various forms and 
>> implementations. I don’t really see that for timecode though I don’t really 
>> know what that would look like either. Especially given the compromises you 
>> both pointed out.
>> 
>> In my case it turned out that our Decklink Duo 2 was in a duplex state that 
>> caused the first few frames to get dropped and thus miss the opening of the 
>> output format timing wise. That is why it appeared to fail setting the 
>> timecode in the output container. We don’t really need that duplex mode (or 
>> the Decklink at all for that matter) so I think we are set for now.
> 
> I’ve run into this in my decklink libavdevice capture code for a number of 
> other VANC types that result in streams having to be created (e.g. SMPTE 2038 
> and SCTE-104).  The way I approached the problem was to add an option to the 
> demux to *always* create the stream rather than relying on the detecting the 
> presence of the data during the probing phase.  This helps in the case where 
> a few frames may be thrown away, as well as the case where actual data is not 
> necessarily always present (such as SCTE-104 triggers).
> 
> Devin
> ___
> 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

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

[Devin Heitmueller]

> On Jul 16, 2018, at 2:56 PM, Jonathan Morley  wrote:
> 
> That is really interesting feedback guys. I have been thinking about things 
> mostly in a MOV independent timecode track (or tracks) kind of way, but I 
> know OMF, MXF, AAF, etc handle it more analogously to packet/frame side data.
> 
> Usually ffmpeg has some kind of superset of functionality for handling any 
> one concept in order to be able to handle all the various forms and 
> implementations. I don’t really see that for timecode though I don’t really 
> know what that would look like either. Especially given the compromises you 
> both pointed out.
> 
> In my case it turned out that our Decklink Duo 2 was in a duplex state that 
> caused the first few frames to get dropped and thus miss the opening of the 
> output format timing wise. That is why it appeared to fail setting the 
> timecode in the output container. We don’t really need that duplex mode (or 
> the Decklink at all for that matter) so I think we are set for now.

I’ve run into this in my decklink libavdevice capture code for a number of 
other VANC types that result in streams having to be created (e.g. SMPTE 2038 
and SCTE-104).  The way I approached the problem was to add an option to the 
demux to *always* create the stream rather than relying on the detecting the 
presence of the data during the probing phase.  This helps in the case where a 
few frames may be thrown away, as well as the case where actual data is not 
necessarily always present (such as SCTE-104 triggers).

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

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

[Jonathan Morley]

That is really interesting feedback guys. I have been thinking about things 
mostly in a MOV independent timecode track (or tracks) kind of way, but I know 
OMF, MXF, AAF, etc handle it more analogously to packet/frame side data.

Usually ffmpeg has some kind of superset of functionality for handling any one 
concept in order to be able to handle all the various forms and 
implementations. I don’t really see that for timecode though I don’t really 
know what that would look like either. Especially given the compromises you 
both pointed out.

In my case it turned out that our Decklink Duo 2 was in a duplex state that 
caused the first few frames to get dropped and thus miss the opening of the 
output format timing wise. That is why it appeared to fail setting the timecode 
in the output container. We don’t really need that duplex mode (or the Decklink 
at all for that matter) so I think we are set for now.

I will keep my thinking cap on about ffmpeg and timecode though. What I need my 
just be about adding understanding to mov.c and movenc.c for handling densely 
populated independent timecode tracks.

Thanks,
Jon

> On Jul 16, 2018, at 6:32 AM, Devin Heitmueller  
> wrote:
> 
> Hi Marton,
> 
>> 
>> In the current implementation per-frame timecode is stored as 
>> AV_PKT_DATA_STRINGS_METADATA side data, when AVPackets become AVFrames, the 
>> AV_PKT_DATA_STRINGS_METADATA is automatically converted to entries in the 
>> AVFrame->metadata AVDictionary. The dictionary key is "timecode".
>> 
>> There is no "standard" way to store per-frame timecode, neither in packets, 
>> nor in frames (other than the frame side data AV_FRAME_DATA_GOP_TIMECODE, 
>> but that is too specific to MPEG). Using AVFrame->metadata for this is also 
>> non-standard, but it allows us to implement the feature without worrying too 
>> much about defining / documenting it.
> 
> For what it’s worth, I’ve got timecode support implemented here where I 
> turned the uint32 defined in libavutil/timecode.h into a new frame side data 
> type.  I’ve got the H.264 decoder extracting timecodes from SEI and creating 
> these, which then feed it to the decklink output where they get converted 
> into the appropriate VANC packets.  Seems to be working pretty well, although 
> still a couple of edge cases to be ironed out with interlaced content and 
> PAFF streams.
> 
>> 
>> Also it is worth mentioning that the frame metadata is lost when encoding, 
>> so the muxers won't have access to it, unless the encoders export it in some 
>> way, such as packet metadata or side data (they current don't).
> 
> Since for the moment I’m focused on the decoding case, I’ve changed the V210 
> encoder to convert the AVFrame side data into AVPacket side data (so the 
> decklink output can get access to the data), and when I hook in the decklink 
> capture support I will be submitting patches for the H.264 and HEVC encoders.
> 
>>> 
>>> 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 see no conflict, you might implement a timecode "track", but I don't see 
>> why that would make your life any easier.
> 
> The whole notion of supporting via a stream versus side data is a 
> long-standing issue.  It impacts not just timecodes but also stuff like 
> closed captions, SCTE-104 triggers, and teletext.  In some cases like MOV 
> it’s carried in the container as a separate stream; in other cases like 
> MPEG2/H.264/HEVC it’s carried in the video stream.
> 
> At least for captions and timecodes the side data approach works fine in the 
> video stream case but it’s problematic if the data is carried as side data 
> needs to be extracted into a stream.  The only way I could think of doing it 
> was to insert a split filter on the video stream and feed both the actual 
> video encoder and a second encoder instance which throws away the video 
> frames and just acts on the side data to create the caption stream.
> 
> And of course you have same problem in the other direction - if you receive 
> the timecodes/captions via a stream, how to you get it into side data so it 
> can be encoded by the video encoder.
> 
> ---
> Devin Heitmueller - LTN Global Communications
> dheitmuel...@ltnglobal.com
> 
> ___
> 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

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

[Devin Heitmueller]

Hi Marton,

> 
> In the current implementation per-frame timecode is stored as 
> AV_PKT_DATA_STRINGS_METADATA side data, when AVPackets become AVFrames, the 
> AV_PKT_DATA_STRINGS_METADATA is automatically converted to entries in the 
> AVFrame->metadata AVDictionary. The dictionary key is "timecode".
> 
> There is no "standard" way to store per-frame timecode, neither in packets, 
> nor in frames (other than the frame side data AV_FRAME_DATA_GOP_TIMECODE, but 
> that is too specific to MPEG). Using AVFrame->metadata for this is also 
> non-standard, but it allows us to implement the feature without worrying too 
> much about defining / documenting it.

For what it’s worth, I’ve got timecode support implemented here where I turned 
the uint32 defined in libavutil/timecode.h into a new frame side data type.  
I’ve got the H.264 decoder extracting timecodes from SEI and creating these, 
which then feed it to the decklink output where they get converted into the 
appropriate VANC packets.  Seems to be working pretty well, although still a 
couple of edge cases to be ironed out with interlaced content and PAFF streams.

> 
> Also it is worth mentioning that the frame metadata is lost when encoding, so 
> the muxers won't have access to it, unless the encoders export it in some 
> way, such as packet metadata or side data (they current don't).

Since for the moment I’m focused on the decoding case, I’ve changed the V210 
encoder to convert the AVFrame side data into AVPacket side data (so the 
decklink output can get access to the data), and when I hook in the decklink 
capture support I will be submitting patches for the H.264 and HEVC encoders.

>> 
>> 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 see no conflict, you might implement a timecode "track", but I don't see 
> why that would make your life any easier.

The whole notion of supporting via a stream versus side data is a long-standing 
issue.  It impacts not just timecodes but also stuff like closed captions, 
SCTE-104 triggers, and teletext.  In some cases like MOV it’s carried in the 
container as a separate stream; in other cases like MPEG2/H.264/HEVC it’s 
carried in the video stream.

At least for captions and timecodes the side data approach works fine in the 
video stream case but it’s problematic if the data is carried as side data 
needs to be extracted into a stream.  The only way I could think of doing it 
was to insert a split filter on the video stream and feed both the actual video 
encoder and a second encoder instance which throws away the video frames and 
just acts on the side data to create the caption stream.

And of course you have same problem in the other direction - if you receive the 
timecodes/captions via a stream, how to you get it into side data so it can be 
encoded by the video encoder.

---
Devin Heitmueller - LTN Global Communications
dheitmuel...@ltnglobal.com

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

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

[Marton Balint]

On Tue, 10 Jul 2018, Jonathan Morley wrote:


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?


In the current implementation per-frame timecode is stored as 
AV_PKT_DATA_STRINGS_METADATA side data, when AVPackets become AVFrames, 
the AV_PKT_DATA_STRINGS_METADATA is automatically converted to entries in 
the AVFrame->metadata AVDictionary. The dictionary key is "timecode".


There is no "standard" way to store per-frame timecode, neither in 
packets, nor in frames (other than the frame side data 
AV_FRAME_DATA_GOP_TIMECODE, but that is too specific to MPEG). Using 
AVFrame->metadata for this is also non-standard, but it allows us to 
implement the feature without worrying too much about defining / 
documenting it.


Also it is worth mentioning that the frame metadata is lost when encoding, 
so the muxers won't have access to it, unless the encoders export it in 
some way, such as packet metadata or side data (they current don't).




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 see no conflict, you might implement a timecode "track", but I don't see 
why that would make your life any easier.




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.


AVStream->timecode is still set if the first decklink frame has a 
timecode, so anything that worked with your initial patch should work now 
as well. Obvisously this approach has limitations, but it works well for 
some use cases.




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.


I don't think there is any overlap, but I am also not aware of any muxer 
which supports timecode tracks, as separate data streams. Not even movenc 
as far as I see.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jonathan Morley]

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  wrote:
> 
> 
> 
> On Tue, 12 Jun 2018, Dave Rice wrote:
> 
>> 
>>> On Jun 7, 2018, at 5:01 PM, Marton Balint  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 
 , 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=71730=400097=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

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

[Marton Balint]

On Tue, 12 Jun 2018, Dave Rice wrote:




On Jun 7, 2018, at 5:01 PM, Marton Balint  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 
, 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=71730=400097=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

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

[Dave Rice]

> On Jun 7, 2018, at 5:01 PM, Marton Balint  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 
>> , 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=71730=400097=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.
Dave
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Marton Balint]

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


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Dave Rice]

> On Jun 7, 2018, at 12:12 PM, Dave Rice  wrote:
> 
> 
>> On Jun 6, 2018, at 5:32 PM, Marton Balint  wrote:
>> 
>> On Wed, 6 Jun 2018, Dave Rice wrote:
>> 
 On Jun 6, 2018, at 4:50 PM, Marton Balint  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
>>  
>> 
> 
> 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 
> , 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 

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

[Dave Rice]

> On Jun 6, 2018, at 5:32 PM, Marton Balint  wrote:
> 
> On Wed, 6 Jun 2018, Dave Rice wrote:
> 
>>> On Jun 6, 2018, at 4:50 PM, Marton Balint  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
>  
> 

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.

With the deckcontrol utility at 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
  

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

[Marton Balint]

On Wed, 6 Jun 2018, Dave Rice wrote:




On Jun 6, 2018, at 4:50 PM, Marton Balint  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

is still needed.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Dave Rice]

> On Jun 6, 2018, at 4:50 PM, Marton Balint  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
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [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,
MartonFrom bb69bdab51d46df6ad9ffe934e395dc959904051 Mon Sep 17 00:00:00 2001
From: Jon Morley 
Date: Thu, 31 May 2018 02:45:07 -0700
Subject: [PATCH] avdevice/decklink_dec: capture timecode to metadata when
 requested

If the user provides a valid timecode_format look for timecode of that
format in the capture and if found store it on the video avstream's
metadata.

Slightly modified by Marton Balint to capture per-frame timecode as well.

Signed-off-by: Marton Balint 
---
 doc/indevs.texi |  6 ++
 libavdevice/decklink_common.h   | 12 
 libavdevice/decklink_common_c.h |  1 +
 libavdevice/decklink_dec.cpp| 41 +
 libavdevice/decklink_dec_c.c|  9 +
 5 files changed, 69 insertions(+)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index 6951940a93..632d1e4743 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -326,6 +326,12 @@ Defaults to @samp{2}.
 Sets the decklink device duplex mode. Must be @samp{unset}, @samp{half} or @samp{full}.
 Defaults to @samp{unset}.
 
+@item timecode_format
+Timecode type to include in the frame and video stream metadata. Must be
+@samp{none}, @samp{rp188vitc}, @samp{rp188vitc2}, @samp{rp188ltc},
+@samp{rp188any}, @samp{vitc}, @samp{vitc2}, or @samp{serial}. Defaults to
+@samp{none} (not included).
+
 @item video_input
 Sets the video input source. Must be @samp{unset}, @samp{sdi}, @samp{hdmi},
 @samp{optical_sdi}, @samp{component}, @samp{composite} or @samp{s_video}.
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 8064abdcb9..96b001c2d8 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -93,6 +93,7 @@ struct decklink_ctx {
 BMDDisplayMode bmd_mode;
 BMDVideoConnection video_input;
 BMDAudioConnection audio_input;
+BMDTimecodeFormat tc_format;
 int bmd_width;
 int bmd_height;
 int bmd_field_dominance;
@@ -169,6 +170,17 @@ static const BMDVideoConnection decklink_video_connection_map[] = {
 bmdVideoConnectionSVideo,
 };
 
+static const BMDTimecodeFormat decklink_timecode_format_map[] = {
+(BMDTimecodeFormat)0,
+bmdTimecodeRP188VITC1,
+bmdTimecodeRP188VITC2,
+bmdTimecodeRP188LTC,
+bmdTimecodeRP188Any,
+bmdTimecodeVITC,
+bmdTimecodeVITCField2,
+bmdTimecodeSerial,
+};
+
 HRESULT ff_decklink_get_display_name(IDeckLink *This, const char **displayName);
 int ff_decklink_set_configs(AVFormatContext *avctx, decklink_direction_t direction);
 int ff_decklink_set_format(AVFormatContext *avctx, int width, int height, int tb_num, int tb_den, enum AVFieldOrder field_order, decklink_direction_t direction = DIRECTION_OUT, int num = 0);
diff --git a/libavdevice/decklink_common_c.h 

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

[Dave Rice]

> On Jun 4, 2018, at 12:24 PM, Marton Balint  wrote:
> 
> On Fri, 1 Jun 2018, Dave Rice wrote:
> 
>>> On May 31, 2018, at 5:29 PM, Marton Balint  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?)

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

>>> 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.
Dave
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [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  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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Dave Rice]

> On May 31, 2018, at 5:29 PM, Marton Balint  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.

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

[…]

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

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

[Devin Heitmueller]

> 
> I'd rather see a new AVPacketSideData type which will contain the timecode as 
> a string, so you can set it frame-by-frame.

For what it’s worth, this is what I’ve done on the decklink output side.  I’ve 
introduced a new side data type and I’m able to decode timecodes provided in 
H.264 streams and output them as SDI VANC (i.e. continuous output of timecodes 
as opposed to just the first timecode).

I just haven’t gotten to doing the capture side yet.  It’s on my TODO list 
though.

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

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

[Marton Balint]

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.

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?


I'd rather see a new AVPacketSideData type which will contain the timecode 
as a string, so you can set it frame-by-frame.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jonathan Morley]

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.

As for the other error message my plan is to demote that to a debug.

Thanks,
Jon

> On May 31, 2018, at 1:17 PM, Dave Rice  wrote:
> 
> Hi Jonathan,
> 
>> On May 31, 2018, at 3:56 PM, Jonathan Morley > > wrote:
>> 
>> Well that is helpful information if not a bit disappointing. Perhaps if I 
>> use the SDK calls to get the individual timecode components _and_ check the 
>> drop frame flag I can reassemble what the GetString() method on the 
>> IDeckLinkTimecode class is supposed to provide.
> 
> I tried with another NDF tape and it worked appropriately. So I do have a 
> capture with NDF and another capture with DF timecode as intended. I am still 
> uncertain what’s wrong with the first NDF that I reported before but I’m 
> supposing it’s an issue with that tape rather than your work.
> 
> Here’s the output of the capture of the new NDF tape, note that I’m still 
> getting the "Unable to set timecode” even though the timecode is set.
> 
> ./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 maybendf.mov
> ffmpeg version N-91200-g1616b1be5a Copyright (c) 2000-2018 the FFmpeg 
> developers
>  built with Apple LLVM version 9.0.0 (clang-900.0.38)
>  configuration: --enable-nonfree --enable-decklink 
> --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include
>  libavutil  56. 18.102 / 56. 18.102
>  libavcodec 58. 19.104 / 58. 19.104
>  libavformat58. 17.100 / 58. 17.100
>  libavdevice58.  4.100 / 58.  4.100
>  libavfilter 7. 24.100 /  7. 24.100
>  libswscale  5.  2.100 /  5.  2.100
>  libswresample   3.  2.100 /  3.  2.100
> [decklink @ 0x7fdd75800a00] Found Decklink mode 720 x 486 with rate 29.97(i)
> [decklink @ 0x7fdd75800a00] Unable to set timecode
> Guessed Channel Layout for Input Stream #0.0 : 7.1
> Input #0, decklink, from 'UltraStudio 3D':
>  Duration: N/A, start: 0.00, bitrate: 229869 kb/s
>Stream #0:0: Audio: pcm_s16le, 48000 Hz, 7.1, s16, 6144 kb/s
>Stream #0:1: Video: v210 (V210 / 0x30313256), yuv422p10le(bottom first), 
> 720x486, 223725 kb/s, 29.97 fps, 29.97 tbr, 1000k tbn, 1000k tbc
>Metadata:
>  timecode: 03:48:55:26
> Stream mapping:
>  Stream #0:1 -> #0:0 (v210 (native) -> v210 (native))
>  Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
> Press [q] to stop, [?] for help
> Output #0, mov, to 'maybendf.mov':
>  Metadata:
>encoder : Lavf58.17.100
>Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le(bottom coded 
> first (swapped)), 720x486, q=2-31, 223725 kb/s, 0.03 fps, 30k tbn, 29.97 tbc
>Metadata:
>  timecode: 03:48:55:26
>  encoder : Lavc58.19.104 v210
>Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 7.1, fltp, 469 
> kb/s
>Metadata:
>  encoder : Lavc58.19.104 aac
> frame=   48 fps= 34 q=-0.0 Lsize=   43745kB time=00:00:01.56 
> bitrate=228505.8kbits/s speed=1.12x
> video:43740kB audio:2kB subtitle:0kB other streams:0kB global headers:0kB 
> muxing overhead: 0.007146%
> [aac @ 0x7fdd77801e00] Qavg: 65536.000
> 
>> I will add that to the next patch, but it might be a minute before I get to 
>> it. Thank you again for taking a look.
>> 
>> I guess we got really lucky in our use case.
>> 
>> Thanks,
>> Jon
>> 
>>> On May 31, 2018, at 12:39 PM, Dave Rice >> > wrote:
>>> 
>>> Hi Jonathan,
>>> 
 On May 31, 2018, at 11:41 AM, Jonathan Morley >>>  >> wrote:
 
 Thank you very much, Dave. I am really curious about the df vs ndf since 
 the Blackmagic SDK call I am making doesn’t have any arguments for 
 specifying that kind of distinction. It simply returns what it finds in 
 the SDI stream.
>>> 
>>> I know have a tape known to be NDF and a tape known to be DF. The messages 
>>> I sent before were from DF tapes. When I tried a NDF tape, I get the 
>>> "Unable to find timecode” warning repeatedly and no timecode on the output 
>>> file.
>>> 
>>> ./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 

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

[Dave Rice]

Hi Jonathan,

> On May 31, 2018, at 3:56 PM, Jonathan Morley  wrote:
> 
> Well that is helpful information if not a bit disappointing. Perhaps if I use 
> the SDK calls to get the individual timecode components _and_ check the drop 
> frame flag I can reassemble what the GetString() method on the 
> IDeckLinkTimecode class is supposed to provide.

I tried with another NDF tape and it worked appropriately. So I do have a 
capture with NDF and another capture with DF timecode as intended. I am still 
uncertain what’s wrong with the first NDF that I reported before but I’m 
supposing it’s an issue with that tape rather than your work.

Here’s the output of the capture of the new NDF tape, note that I’m still 
getting the "Unable to set timecode” even though the timecode is set.

./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 maybendf.mov
ffmpeg version N-91200-g1616b1be5a Copyright (c) 2000-2018 the FFmpeg developers
  built with Apple LLVM version 9.0.0 (clang-900.0.38)
  configuration: --enable-nonfree --enable-decklink 
--extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include
  libavutil  56. 18.102 / 56. 18.102
  libavcodec 58. 19.104 / 58. 19.104
  libavformat58. 17.100 / 58. 17.100
  libavdevice58.  4.100 / 58.  4.100
  libavfilter 7. 24.100 /  7. 24.100
  libswscale  5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
[decklink @ 0x7fdd75800a00] Found Decklink mode 720 x 486 with rate 29.97(i)
[decklink @ 0x7fdd75800a00] Unable to set timecode
Guessed Channel Layout for Input Stream #0.0 : 7.1
Input #0, decklink, from 'UltraStudio 3D':
  Duration: N/A, start: 0.00, bitrate: 229869 kb/s
Stream #0:0: Audio: pcm_s16le, 48000 Hz, 7.1, s16, 6144 kb/s
Stream #0:1: Video: v210 (V210 / 0x30313256), yuv422p10le(bottom first), 
720x486, 223725 kb/s, 29.97 fps, 29.97 tbr, 1000k tbn, 1000k tbc
Metadata:
  timecode: 03:48:55:26
Stream mapping:
  Stream #0:1 -> #0:0 (v210 (native) -> v210 (native))
  Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, mov, to 'maybendf.mov':
  Metadata:
encoder : Lavf58.17.100
Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le(bottom coded 
first (swapped)), 720x486, q=2-31, 223725 kb/s, 0.03 fps, 30k tbn, 29.97 tbc
Metadata:
  timecode: 03:48:55:26
  encoder : Lavc58.19.104 v210
Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 7.1, fltp, 469 
kb/s
Metadata:
  encoder : Lavc58.19.104 aac
frame=   48 fps= 34 q=-0.0 Lsize=   43745kB time=00:00:01.56 
bitrate=228505.8kbits/s speed=1.12x
video:43740kB audio:2kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: 0.007146%
[aac @ 0x7fdd77801e00] Qavg: 65536.000

> I will add that to the next patch, but it might be a minute before I get to 
> it. Thank you again for taking a look.
> 
> I guess we got really lucky in our use case.
> 
> Thanks,
> Jon
> 
>> On May 31, 2018, at 12:39 PM, Dave Rice  wrote:
>> 
>> Hi Jonathan,
>> 
>>> On May 31, 2018, at 11:41 AM, Jonathan Morley >> > wrote:
>>> 
>>> Thank you very much, Dave. I am really curious about the df vs ndf since 
>>> the Blackmagic SDK call I am making doesn’t have any arguments for 
>>> specifying that kind of distinction. It simply returns what it finds in the 
>>> SDI stream.
>> 
>> I know have a tape known to be NDF and a tape known to be DF. The messages I 
>> sent before were from DF tapes. When I tried a NDF tape, I get the "Unable 
>> to find timecode” warning repeatedly and no timecode on the output file.
>> 
>> ./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 devlin5.mov
>> ffmpeg version N-91200-g1616b1be5a Copyright (c) 2000-2018 the FFmpeg 
>> developers
>> built with Apple LLVM version 9.0.0 (clang-900.0.38)
>> configuration: --enable-nonfree --enable-decklink 
>> --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include
>> libavutil  56. 18.102 / 56. 18.102
>> libavcodec 58. 19.104 / 58. 19.104
>> libavformat58. 17.100 / 58. 17.100
>> libavdevice58.  4.100 / 58.  4.100
>> libavfilter 7. 24.100 /  7. 24.100
>> libswscale  5.  2.100 /  5.  2.100
>> libswresample   3.  2.100 /  3.  2.100
>> [decklink @ 0x7f9f6680] Found Decklink mode 720 x 486 with rate 29.97(i)
>> [decklink @ 0x7f9f6680] Unable to find timecode.
>>   Last message repeated 5 times
>> Guessed Channel Layout for Input Stream #0.0 : 7.1
>> Input #0, decklink, from 'UltraStudio 3D':
>> Duration: N/A, start: 0.00, bitrate: 229869 kb/s
>>   Stream #0:0: Audio: pcm_s16le, 48000 Hz, 7.1, s16, 6144 kb/s
>>   Stream #0:1: 

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

[Jonathan Morley]

Well that is helpful information if not a bit disappointing. Perhaps if I use 
the SDK calls to get the individual timecode components _and_ check the drop 
frame flag I can reassemble what the GetString() method on the 
IDeckLinkTimecode class is supposed to provide.

I will add that to the next patch, but it might be a minute before I get to it. 
Thank you again for taking a look.

I guess we got really lucky in our use case.

Thanks,
Jon

> On May 31, 2018, at 12:39 PM, Dave Rice  wrote:
> 
> Hi Jonathan,
> 
>> On May 31, 2018, at 11:41 AM, Jonathan Morley > > wrote:
>> 
>> Thank you very much, Dave. I am really curious about the df vs ndf since the 
>> Blackmagic SDK call I am making doesn’t have any arguments for specifying 
>> that kind of distinction. It simply returns what it finds in the SDI stream.
> 
> I know have a tape known to be NDF and a tape known to be DF. The messages I 
> sent before were from DF tapes. When I tried a NDF tape, I get the "Unable to 
> find timecode” warning repeatedly and no timecode on the output file.
> 
> ./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 devlin5.mov
> ffmpeg version N-91200-g1616b1be5a Copyright (c) 2000-2018 the FFmpeg 
> developers
>  built with Apple LLVM version 9.0.0 (clang-900.0.38)
>  configuration: --enable-nonfree --enable-decklink 
> --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include
>  libavutil  56. 18.102 / 56. 18.102
>  libavcodec 58. 19.104 / 58. 19.104
>  libavformat58. 17.100 / 58. 17.100
>  libavdevice58.  4.100 / 58.  4.100
>  libavfilter 7. 24.100 /  7. 24.100
>  libswscale  5.  2.100 /  5.  2.100
>  libswresample   3.  2.100 /  3.  2.100
> [decklink @ 0x7f9f6680] Found Decklink mode 720 x 486 with rate 29.97(i)
> [decklink @ 0x7f9f6680] Unable to find timecode.
>Last message repeated 5 times
> Guessed Channel Layout for Input Stream #0.0 : 7.1
> Input #0, decklink, from 'UltraStudio 3D':
>  Duration: N/A, start: 0.00, bitrate: 229869 kb/s
>Stream #0:0: Audio: pcm_s16le, 48000 Hz, 7.1, s16, 6144 kb/s
>Stream #0:1: Video: v210 (V210 / 0x30313256), yuv422p10le(bottom first), 
> 720x486, 223725 kb/s, 29.97 fps, 29.97 tbr, 1000k tbn, 1000k tbc
> Stream mapping:
>  Stream #0:1 -> #0:0 (v210 (native) -> v210 (native))
>  Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
> Press [q] to stop, [?] for help
> Output #0, mov, to 'devlin5.mov':
>  Metadata:
>encoder : Lavf58.17.100
>Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le(bottom coded 
> first (swapped)), 720x486, q=2-31, 223725 kb/s, 29.97 fps, 30k tbn, 29.97 tbc
>Metadata:
>  encoder : Lavc58.19.104 v210
>Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 7.1, fltp, 469 
> kb/s
>Metadata:
>  encoder : Lavc58.19.104 aac
> [decklink @ 0x7f9f6680] Unable to find timecode.
>Last message repeated 15 times
> [decklink @ 0x7f9f6680] Unable to find timecode.0:00.70 
> bitrate=200517.8kbits/s speed= 1.4x
>Last message repeated 14 times
> [decklink @ 0x7f9f6680] Unable to find timecode.0:01.20 
> bitrate=211246.0kbits/s speed= 1.2x
>Last message repeated 14 times
> [decklink @ 0x7f9f6680] Unable to find timecode.0:01.70 
> bitrate=214431.3kbits/s speed=1.13x
>Last message repeated 14 times
> [decklink @ 0x7f9f6680] Unable to find timecode.0:02.20 
> bitrate=217121.0kbits/s speed= 1.1x
>Last message repeated 14 times
> [decklink @ 0x7f9f6680] Unable to find timecode.0:02.70 
> bitrate=221142.3kbits/s speed=1.07x
>Last message repeated 14 times
> [decklink @ 0x7f9f6680] Unable to find timecode.0:03.20 
> bitrate=221288.2kbits/s speed=1.06x
> 
> So when inputing DF this appears to work while Media Express gets it wrong by 
> writing the timecode with a NDF flag.
> However when inputing NDF no timecode is communicated.
> 
> I ran this to check if somehow I was called the wrong timecode 
> 
> 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 3D" -select_streams v -show_entries 
> stream_tags=timecode -of default=nw=1:nk=1 ; echo ; done
> 
> rp188vitc: 
> rp188vitc2: 
> rp188ltc: 
> rp188any: 
> vitc: 
> vitc2: 
> serial: 
> 
> I may try to find another NDF tape to make sure this isn’t a fluke.
> 
>> And when I skimmed the movenc timecode handling it doesn’t seem to make any 
>> assumptions or changes either.
> 
> I’ve replicated it with Matroska which simply moves the timecode into 
> metadata as a string.
> 
>> Please keep me posted. Meanwhile I will look into what could be causing all 

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

[Dave Rice]

Hi Jonathan,

> On May 31, 2018, at 11:41 AM, Jonathan Morley  wrote:
> 
> Thank you very much, Dave. I am really curious about the df vs ndf since the 
> Blackmagic SDK call I am making doesn’t have any arguments for specifying 
> that kind of distinction. It simply returns what it finds in the SDI stream.

I know have a tape known to be NDF and a tape known to be DF. The messages I 
sent before were from DF tapes. When I tried a NDF tape, I get the "Unable to 
find timecode” warning repeatedly and no timecode on the output file.

./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 devlin5.mov
ffmpeg version N-91200-g1616b1be5a Copyright (c) 2000-2018 the FFmpeg developers
  built with Apple LLVM version 9.0.0 (clang-900.0.38)
  configuration: --enable-nonfree --enable-decklink 
--extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include
  libavutil  56. 18.102 / 56. 18.102
  libavcodec 58. 19.104 / 58. 19.104
  libavformat58. 17.100 / 58. 17.100
  libavdevice58.  4.100 / 58.  4.100
  libavfilter 7. 24.100 /  7. 24.100
  libswscale  5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
[decklink @ 0x7f9f6680] Found Decklink mode 720 x 486 with rate 29.97(i)
[decklink @ 0x7f9f6680] Unable to find timecode.
Last message repeated 5 times
Guessed Channel Layout for Input Stream #0.0 : 7.1
Input #0, decklink, from 'UltraStudio 3D':
  Duration: N/A, start: 0.00, bitrate: 229869 kb/s
Stream #0:0: Audio: pcm_s16le, 48000 Hz, 7.1, s16, 6144 kb/s
Stream #0:1: Video: v210 (V210 / 0x30313256), yuv422p10le(bottom first), 
720x486, 223725 kb/s, 29.97 fps, 29.97 tbr, 1000k tbn, 1000k tbc
Stream mapping:
  Stream #0:1 -> #0:0 (v210 (native) -> v210 (native))
  Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, mov, to 'devlin5.mov':
  Metadata:
encoder : Lavf58.17.100
Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le(bottom coded 
first (swapped)), 720x486, q=2-31, 223725 kb/s, 29.97 fps, 30k tbn, 29.97 tbc
Metadata:
  encoder : Lavc58.19.104 v210
Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 7.1, fltp, 469 
kb/s
Metadata:
  encoder : Lavc58.19.104 aac
[decklink @ 0x7f9f6680] Unable to find timecode.
Last message repeated 15 times
[decklink @ 0x7f9f6680] Unable to find timecode.0:00.70 
bitrate=200517.8kbits/s speed= 1.4x
Last message repeated 14 times
[decklink @ 0x7f9f6680] Unable to find timecode.0:01.20 
bitrate=211246.0kbits/s speed= 1.2x
Last message repeated 14 times
[decklink @ 0x7f9f6680] Unable to find timecode.0:01.70 
bitrate=214431.3kbits/s speed=1.13x
Last message repeated 14 times
[decklink @ 0x7f9f6680] Unable to find timecode.0:02.20 
bitrate=217121.0kbits/s speed= 1.1x
Last message repeated 14 times
[decklink @ 0x7f9f6680] Unable to find timecode.0:02.70 
bitrate=221142.3kbits/s speed=1.07x
Last message repeated 14 times
[decklink @ 0x7f9f6680] Unable to find timecode.0:03.20 
bitrate=221288.2kbits/s speed=1.06x

So when inputing DF this appears to work while Media Express gets it wrong by 
writing the timecode with a NDF flag.
However when inputing NDF no timecode is communicated.

I ran this to check if somehow I was called the wrong timecode 

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 3D" -select_streams v -show_entries 
stream_tags=timecode -of default=nw=1:nk=1 ; echo ; done

rp188vitc: 
rp188vitc2: 
rp188ltc: 
rp188any: 
vitc: 
vitc2: 
serial: 

I may try to find another NDF tape to make sure this isn’t a fluke.

> And when I skimmed the movenc timecode handling it doesn’t seem to make any 
> assumptions or changes either.

I’ve replicated it with Matroska which simply moves the timecode into metadata 
as a string.

> Please keep me posted. Meanwhile I will look into what could be causing all 
> the error chatter.

Thanks!

> Thanks,
> Jon
> 
>> On May 31, 2018, at 7:59 AM, Dave Rice  wrote:
>> 
>> 
>>> On May 31, 2018, at 5:49 AM, Jonathan Morley  wrote:
>>> 
>>> Please take a look at my latest patches.
>>> 
>>> NOTE: I no longer have the hardware to test this work!
>> 
>> I tested these patches with an Ultrastudio 3D.
>> 
>> I find that in some cases it provides the “Unable to set timecode” warning 
>> although it does provide the timecode value. Such as:
>> 
>> ./ffmpeg -timecode_format vitc -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 signs.mov
>> ffmpeg 

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

[Jonathan Morley]

Hi Dave,

I took a closer look at these messages. I can see why the “Unable to find 
timecode” messages are repeated. That is sort of correctly reporting that the 
current video stream does not have a valid timecode, however reporting it as an 
error seems unnecessary. How would changing it to a debug message sound?

As for the “Unable to set timecode” I am still not sure how that could happen 
unless the way I am testing for the uninitialized ctx->first_tc is 
inconsistent. I will have to hear back from Marton I believe.

Thanks,
Jon

> On May 31, 2018, at 7:59 AM, Dave Rice  wrote:
> 
> 
>> On May 31, 2018, at 5:49 AM, Jonathan Morley  wrote:
>> 
>> Please take a look at my latest patches.
>> 
>> NOTE: I no longer have the hardware to test this work!
> 
> I tested these patches with an Ultrastudio 3D.
> 
> I find that in some cases it provides the “Unable to set timecode” warning 
> although it does provide the timecode value. Such as:
> 
> ./ffmpeg -timecode_format vitc -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 signs.mov
> ffmpeg version N-91200-g1616b1be5a Copyright (c) 2000-2018 the FFmpeg 
> developers
>  built with Apple LLVM version 9.0.0 (clang-900.0.38)
>  configuration: --enable-nonfree --enable-decklink 
> --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include
>  libavutil  56. 18.102 / 56. 18.102
>  libavcodec 58. 19.104 / 58. 19.104
>  libavformat58. 17.100 / 58. 17.100
>  libavdevice58.  4.100 / 58.  4.100
>  libavfilter 7. 24.100 /  7. 24.100
>  libswscale  5.  2.100 /  5.  2.100
>  libswresample   3.  2.100 /  3.  2.100
> [decklink @ 0x7f8711802600] Found Decklink mode 720 x 486 with rate 29.97(i)
> [decklink @ 0x7f8711802600] Unable to set timecode
> Guessed Channel Layout for Input Stream #0.0 : 7.1
> Input #0, decklink, from 'UltraStudio 3D':
>  Duration: N/A, start: 0.00, bitrate: 229869 kb/s
>Stream #0:0: Audio: pcm_s16le, 48000 Hz, 7.1, s16, 6144 kb/s
>Stream #0:1: Video: v210 (V210 / 0x30313256), yuv422p10le(bottom first), 
> 720x486, 223725 kb/s, 29.97 fps, 29.97 tbr, 1000k tbn, 1000k tbc
>Metadata:
>  timecode: 00:59:53;25
> Stream mapping:
>  Stream #0:1 -> #0:0 (v210 (native) -> v210 (native))
>  Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
> Press [q] to stop, [?] for help
> Output #0, mov, to 'signs.mov':
>  Metadata:
>encoder : Lavf58.17.100
>Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le(bottom coded 
> first (swapped)), 720x486, q=2-31, 223725 kb/s, 0.03 fps, 30k tbn, 29.97 tbc
>Metadata:
>  timecode: 00:59:53;25
>  encoder : Lavc58.19.104 v210
>Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 7.1, fltp, 469 
> kb/s
>Metadata:
>  encoder : Lavc58.19.104 aac
> frame=  407 fps= 30 q=-0.0 Lsize=  371576kB time=00:00:13.54 
> bitrate=224697.2kbits/s speed=1.01x
> video:370879kB audio:685kB subtitle:0kB other streams:0kB global headers:0kB 
> muxing overhead: 0.003177%
> [aac @ 0x7f8711805800] Qavg: 30894.625
> 
> Another comment is that if I start the recording with ffmpeg before I play 
> through a source I get spammed with timecode errors such as:
> 
> ./ffmpeg -timecode_format vitc -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 notplaying.mov
> ffmpeg version N-91200-g1616b1be5a Copyright (c) 2000-2018 the FFmpeg 
> developers
>  built with Apple LLVM version 9.0.0 (clang-900.0.38)
>  configuration: --enable-nonfree --enable-decklink 
> --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include
>  libavutil  56. 18.102 / 56. 18.102
>  libavcodec 58. 19.104 / 58. 19.104
>  libavformat58. 17.100 / 58. 17.100
>  libavdevice58.  4.100 / 58.  4.100
>  libavfilter 7. 24.100 /  7. 24.100
>  libswscale  5.  2.100 /  5.  2.100
>  libswresample   3.  2.100 /  3.  2.100
> [decklink @ 0x7fe313803000] Found Decklink mode 720 x 486 with rate 29.97(i)
> [decklink @ 0x7fe313803000] Unable to find timecode.
>Last message repeated 5 times
> Guessed Channel Layout for Input Stream #0.0 : 7.1
> Input #0, decklink, from 'UltraStudio 3D':
>  Duration: N/A, start: 0.00, bitrate: 229869 kb/s
>Stream #0:0: Audio: pcm_s16le, 48000 Hz, 7.1, s16, 6144 kb/s
>Stream #0:1: Video: v210 (V210 / 0x30313256), yuv422p10le(bottom first), 
> 720x486, 223725 kb/s, 29.97 fps, 29.97 tbr, 1000k tbn, 1000k tbc
> Stream mapping:
>  Stream #0:1 -> #0:0 (v210 (native) -> v210 (native))
>  Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
> Press [q] to stop, [?] for help
> Output #0, mov, to 'notplaying.mov':
>  Metadata:
>encoder : Lavf58.17.100
>Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le(bottom coded 
> first (swapped)), 720x486, 

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

[Jonathan Morley]

Thank you very much, Dave. I am really curious about the df vs ndf since the 
Blackmagic SDK call I am making doesn’t have any arguments for specifying that 
kind of distinction. It simply returns what it finds in the SDI stream. And 
when I skimmed the movenc timecode handling it doesn’t seem to make any 
assumptions or changes either.

Please keep me posted. Meanwhile I will look into what could be causing all the 
error chatter.

Thanks,
Jon

> On May 31, 2018, at 7:59 AM, Dave Rice  wrote:
> 
> 
>> On May 31, 2018, at 5:49 AM, Jonathan Morley  wrote:
>> 
>> Please take a look at my latest patches.
>> 
>> NOTE: I no longer have the hardware to test this work!
> 
> I tested these patches with an Ultrastudio 3D.
> 
> I find that in some cases it provides the “Unable to set timecode” warning 
> although it does provide the timecode value. Such as:
> 
> ./ffmpeg -timecode_format vitc -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 signs.mov
> ffmpeg version N-91200-g1616b1be5a Copyright (c) 2000-2018 the FFmpeg 
> developers
>  built with Apple LLVM version 9.0.0 (clang-900.0.38)
>  configuration: --enable-nonfree --enable-decklink 
> --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include
>  libavutil  56. 18.102 / 56. 18.102
>  libavcodec 58. 19.104 / 58. 19.104
>  libavformat58. 17.100 / 58. 17.100
>  libavdevice58.  4.100 / 58.  4.100
>  libavfilter 7. 24.100 /  7. 24.100
>  libswscale  5.  2.100 /  5.  2.100
>  libswresample   3.  2.100 /  3.  2.100
> [decklink @ 0x7f8711802600] Found Decklink mode 720 x 486 with rate 29.97(i)
> [decklink @ 0x7f8711802600] Unable to set timecode
> Guessed Channel Layout for Input Stream #0.0 : 7.1
> Input #0, decklink, from 'UltraStudio 3D':
>  Duration: N/A, start: 0.00, bitrate: 229869 kb/s
>Stream #0:0: Audio: pcm_s16le, 48000 Hz, 7.1, s16, 6144 kb/s
>Stream #0:1: Video: v210 (V210 / 0x30313256), yuv422p10le(bottom first), 
> 720x486, 223725 kb/s, 29.97 fps, 29.97 tbr, 1000k tbn, 1000k tbc
>Metadata:
>  timecode: 00:59:53;25
> Stream mapping:
>  Stream #0:1 -> #0:0 (v210 (native) -> v210 (native))
>  Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
> Press [q] to stop, [?] for help
> Output #0, mov, to 'signs.mov':
>  Metadata:
>encoder : Lavf58.17.100
>Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le(bottom coded 
> first (swapped)), 720x486, q=2-31, 223725 kb/s, 0.03 fps, 30k tbn, 29.97 tbc
>Metadata:
>  timecode: 00:59:53;25
>  encoder : Lavc58.19.104 v210
>Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 7.1, fltp, 469 
> kb/s
>Metadata:
>  encoder : Lavc58.19.104 aac
> frame=  407 fps= 30 q=-0.0 Lsize=  371576kB time=00:00:13.54 
> bitrate=224697.2kbits/s speed=1.01x
> video:370879kB audio:685kB subtitle:0kB other streams:0kB global headers:0kB 
> muxing overhead: 0.003177%
> [aac @ 0x7f8711805800] Qavg: 30894.625
> 
> Another comment is that if I start the recording with ffmpeg before I play 
> through a source I get spammed with timecode errors such as:
> 
> ./ffmpeg -timecode_format vitc -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 notplaying.mov
> ffmpeg version N-91200-g1616b1be5a Copyright (c) 2000-2018 the FFmpeg 
> developers
>  built with Apple LLVM version 9.0.0 (clang-900.0.38)
>  configuration: --enable-nonfree --enable-decklink 
> --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include
>  libavutil  56. 18.102 / 56. 18.102
>  libavcodec 58. 19.104 / 58. 19.104
>  libavformat58. 17.100 / 58. 17.100
>  libavdevice58.  4.100 / 58.  4.100
>  libavfilter 7. 24.100 /  7. 24.100
>  libswscale  5.  2.100 /  5.  2.100
>  libswresample   3.  2.100 /  3.  2.100
> [decklink @ 0x7fe313803000] Found Decklink mode 720 x 486 with rate 29.97(i)
> [decklink @ 0x7fe313803000] Unable to find timecode.
>Last message repeated 5 times
> Guessed Channel Layout for Input Stream #0.0 : 7.1
> Input #0, decklink, from 'UltraStudio 3D':
>  Duration: N/A, start: 0.00, bitrate: 229869 kb/s
>Stream #0:0: Audio: pcm_s16le, 48000 Hz, 7.1, s16, 6144 kb/s
>Stream #0:1: Video: v210 (V210 / 0x30313256), yuv422p10le(bottom first), 
> 720x486, 223725 kb/s, 29.97 fps, 29.97 tbr, 1000k tbn, 1000k tbc
> Stream mapping:
>  Stream #0:1 -> #0:0 (v210 (native) -> v210 (native))
>  Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
> Press [q] to stop, [?] for help
> Output #0, mov, to 'notplaying.mov':
>  Metadata:
>encoder : Lavf58.17.100
>Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le(bottom coded 
> first (swapped)), 720x486, q=2-31, 223725 kb/s, 29.97 fps, 30k tbn, 29.97 tbc
>Metadata:
>  encoder : 

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

[Dave Rice]

> On May 31, 2018, at 5:49 AM, Jonathan Morley  wrote:
> 
> Please take a look at my latest patches.
> 
> NOTE: I no longer have the hardware to test this work!

I tested these patches with an Ultrastudio 3D.

I find that in some cases it provides the “Unable to set timecode” warning 
although it does provide the timecode value. Such as:

./ffmpeg -timecode_format vitc -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 signs.mov
ffmpeg version N-91200-g1616b1be5a Copyright (c) 2000-2018 the FFmpeg developers
  built with Apple LLVM version 9.0.0 (clang-900.0.38)
  configuration: --enable-nonfree --enable-decklink 
--extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include
  libavutil  56. 18.102 / 56. 18.102
  libavcodec 58. 19.104 / 58. 19.104
  libavformat58. 17.100 / 58. 17.100
  libavdevice58.  4.100 / 58.  4.100
  libavfilter 7. 24.100 /  7. 24.100
  libswscale  5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
[decklink @ 0x7f8711802600] Found Decklink mode 720 x 486 with rate 29.97(i)
[decklink @ 0x7f8711802600] Unable to set timecode
Guessed Channel Layout for Input Stream #0.0 : 7.1
Input #0, decklink, from 'UltraStudio 3D':
  Duration: N/A, start: 0.00, bitrate: 229869 kb/s
Stream #0:0: Audio: pcm_s16le, 48000 Hz, 7.1, s16, 6144 kb/s
Stream #0:1: Video: v210 (V210 / 0x30313256), yuv422p10le(bottom first), 
720x486, 223725 kb/s, 29.97 fps, 29.97 tbr, 1000k tbn, 1000k tbc
Metadata:
  timecode: 00:59:53;25
Stream mapping:
  Stream #0:1 -> #0:0 (v210 (native) -> v210 (native))
  Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, mov, to 'signs.mov':
  Metadata:
encoder : Lavf58.17.100
Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le(bottom coded 
first (swapped)), 720x486, q=2-31, 223725 kb/s, 0.03 fps, 30k tbn, 29.97 tbc
Metadata:
  timecode: 00:59:53;25
  encoder : Lavc58.19.104 v210
Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 7.1, fltp, 469 
kb/s
Metadata:
  encoder : Lavc58.19.104 aac
frame=  407 fps= 30 q=-0.0 Lsize=  371576kB time=00:00:13.54 
bitrate=224697.2kbits/s speed=1.01x
video:370879kB audio:685kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: 0.003177%
[aac @ 0x7f8711805800] Qavg: 30894.625

Another comment is that if I start the recording with ffmpeg before I play 
through a source I get spammed with timecode errors such as:

./ffmpeg -timecode_format vitc -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 notplaying.mov
ffmpeg version N-91200-g1616b1be5a Copyright (c) 2000-2018 the FFmpeg developers
  built with Apple LLVM version 9.0.0 (clang-900.0.38)
  configuration: --enable-nonfree --enable-decklink 
--extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include
  libavutil  56. 18.102 / 56. 18.102
  libavcodec 58. 19.104 / 58. 19.104
  libavformat58. 17.100 / 58. 17.100
  libavdevice58.  4.100 / 58.  4.100
  libavfilter 7. 24.100 /  7. 24.100
  libswscale  5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
[decklink @ 0x7fe313803000] Found Decklink mode 720 x 486 with rate 29.97(i)
[decklink @ 0x7fe313803000] Unable to find timecode.
Last message repeated 5 times
Guessed Channel Layout for Input Stream #0.0 : 7.1
Input #0, decklink, from 'UltraStudio 3D':
  Duration: N/A, start: 0.00, bitrate: 229869 kb/s
Stream #0:0: Audio: pcm_s16le, 48000 Hz, 7.1, s16, 6144 kb/s
Stream #0:1: Video: v210 (V210 / 0x30313256), yuv422p10le(bottom first), 
720x486, 223725 kb/s, 29.97 fps, 29.97 tbr, 1000k tbn, 1000k tbc
Stream mapping:
  Stream #0:1 -> #0:0 (v210 (native) -> v210 (native))
  Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, mov, to 'notplaying.mov':
  Metadata:
encoder : Lavf58.17.100
Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le(bottom coded 
first (swapped)), 720x486, q=2-31, 223725 kb/s, 29.97 fps, 30k tbn, 29.97 tbc
Metadata:
  encoder : Lavc58.19.104 v210
Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 7.1, fltp, 469 
kb/s
Metadata:
  encoder : Lavc58.19.104 aac
[decklink @ 0x7fe313803000] Unable to find timecode.
Last message repeated 14 times
[decklink @ 0x7fe313803000] Unable to find timecode.0:00.66 
bitrate=210543.0kbits/s speed=1.33x
Last message repeated 14 times
[decklink @ 0x7fe313803000] Unable to find timecode.0:01.16 
bitrate=217281.3kbits/s speed=1.17x
Last message repeated 14 times
[decklink @ 0x7fe313803000] Unable to find timecode.0:01.66 
bitrate=218719.7kbits/s speed=1.11x
Last message repeated 

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

[Jonathan Morley]

Please take a look at my latest patches.

NOTE: I no longer have the hardware to test this work!

On Wed, May 30, 2018 at 11:04 AM, Marton Balint  wrote:

>
>
> On Tue, 29 May 2018, Jonathan Morley wrote:
>
> Thank you Marton, That makes sense to me, but can you please clarify which
>> context is the most appropriate to use?
>>
>
> Just put it in decklink_ctx in the Status section.
>
> Don't forget to free it in ff_decklink_read_close.
>
>
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


0001-lavd-decklink_common-Move-DECKLINK_-string-functions.patch
Description: Binary data


0002-lavd-decklink-Capture-first-valid-timecode-to-metada.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jonathan Morley]

Thank you. I will add that and get you a new patch for review.

> On May 30, 2018, at 11:04 AM, Marton Balint  wrote:
> 
> 
> 
> On Tue, 29 May 2018, Jonathan Morley wrote:
> 
>> Thank you Marton, That makes sense to me, but can you please clarify which 
>> context is the most appropriate to use?
> 
> Just put it in decklink_ctx in the Status section.
> 
> Don't forget to free it in ff_decklink_read_close.
> 
> 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

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

[Marton Balint]

On Tue, 29 May 2018, Jonathan Morley wrote:


Thank you Marton, That makes sense to me, but can you please clarify which 
context is the most appropriate to use?


Just put it in decklink_ctx in the Status section.

Don't forget to free it in ff_decklink_read_close.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jonathan Morley]

Thank you Marton, That makes sense to me, but can you please clarify which 
context is the most appropriate to use?

Thanks,
Jon

> On May 29, 2018, at 1:41 AM, Marton Balint  wrote:
> 
> 
> 
> On Sat, 26 May 2018, Jonathan Morley wrote:
> 
>> Attaching again from another mail client.
> 
> Thanks. There is one issue I found:
> 
> You are setting >video_st->metadata from the VideoInputFrameArrived 
> callback. That runs in a separate thread from the main thread handling 
> read_packet calls, and you can only invalidate video_st->metadata in the main 
> thread. So I suggest to store the timecode string in a context variable, and 
> do av_dict_set in ff_decklink_read_packet after avpacket_queue_get.
> 
> 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

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

[Marton Balint]

On Sat, 26 May 2018, Jonathan Morley wrote:


Attaching again from another mail client.


Thanks. There is one issue I found:

You are setting >video_st->metadata from the VideoInputFrameArrived 
callback. That runs in a separate thread from the main thread 
handling read_packet calls, and you can only invalidate 
video_st->metadata in the main thread. So I suggest to store the timecode 
string in a context variable, and do av_dict_set in 
ff_decklink_read_packet after avpacket_queue_get.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jonathan Morley]

Attaching again from another mail client.

On Sat, May 26, 2018 at 12:23 AM, Marton Balint  wrote:

>
>
> On Fri, 25 May 2018, Jonathan Morley wrote:
>
> Attached are the two patches to address your feedback, Marton. Please
>> advise.
>>
>>
> Your mail contains no attachments as far as I see.
>
>
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


0001-lavd-decklink_common-Move-DECKLINK_-string-functions.patch
Description: Binary data


0002-lavd-decklink-Capture-first-valid-timecode-to-metadata.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Marton Balint]

On Fri, 25 May 2018, Jonathan Morley wrote:


Attached are the two patches to address your feedback, Marton. Please advise.



Your mail contains no attachments as far as I see.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jonathan Morley]

Also please include the frame rate coming from the ultrastudio. I suspect
there is a mismatch in the works.

On Fri, May 25, 2018 at 7:36 PM Dave Rice  wrote:

>
>
> > On May 25, 2018, at 17:15, Jonathan Morley 
> wrote:
> >
> > Thank you for trying it out, Dave.
> >
> > 1) Can you please tell me more about how you tested?
>
> J30 digibeta deck playing a Betacam SP with SDI to an Ultrastudio 3D with
> ffmpeg with your patch and configured with decklink.
>
> > 2) Did you run a capture command with ffmpeg after patching?
>
> Yes. And I should have shared that command in my email. From memory it was
> something like: ffmpeg -f decklink
> $input-format-options-for-an-sd-ntsc-input -i “Ultrastudio 3D” -c:v v210
> -c:a aac output.mov
>
> > 3) What was the target output you we using?
>
> QuickTime since the -metadata timecode=# tag works well there.
>
> I can test more on Tuesday. Thanks for this work!
>
> > Thanks,
> > Jon
> > ___
> > 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
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jonathan Morley]

On Fri, May 25, 2018 at 7:36 PM Dave Rice  wrote:

>
>
> > On May 25, 2018, at 17:15, Jonathan Morley 
> wrote:
> >
> > Thank you for trying it out, Dave.
> >
> > 1) Can you please tell me more about how you tested?
>
> J30 digibeta deck playing a Betacam SP with SDI to an Ultrastudio 3D with
> ffmpeg with your patch and configured with decklink.
>
> > 2) Did you run a capture command with ffmpeg after patching?
>
> Yes. And I should have shared that command in my email. From memory it was
> something like: ffmpeg -f decklink
> $input-format-options-for-an-sd-ntsc-input -i “Ultrastudio 3D” -c:v v210
> -c:a aac output.mov


Do you think you could share with me the contents of
$input-format-options-for-an-sd-ntsc-input?

>
>
> > 3) What was the target output you we using?
>
> QuickTime since the -metadata timecode=# tag works well there.
>
> I can test more on Tuesday. Thanks for this work!
>
> > Thanks,
> > Jon
> > ___
> > 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
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Dave Rice]

> On May 25, 2018, at 17:15, Jonathan Morley  wrote:
> 
> Thank you for trying it out, Dave.
> 
> 1) Can you please tell me more about how you tested?

J30 digibeta deck playing a Betacam SP with SDI to an Ultrastudio 3D with 
ffmpeg with your patch and configured with decklink. 

> 2) Did you run a capture command with ffmpeg after patching?

Yes. And I should have shared that command in my email. From memory it was 
something like: ffmpeg -f decklink $input-format-options-for-an-sd-ntsc-input 
-i “Ultrastudio 3D” -c:v v210 -c:a aac output.mov

> 3) What was the target output you we using?

QuickTime since the -metadata timecode=# tag works well there.

I can test more on Tuesday. Thanks for this work!

> Thanks,
> Jon
> ___
> 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

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

[Jonathan Morley]

Thank you for trying it out, Dave.

1) Can you please tell me more about how you tested?

2) Did you run a capture command with ffmpeg after patching?

3) What was the target output you we using?

Thanks,
Jon
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Dave Rice]

> On May 25, 2018, at 1:08 PM, Jonathan Morley  wrote:
> 
>> On May 25, 2018, at 8:32 AM, Marton Balint > > wrote:
>> 
>> On Fri, 25 May 2018, Jonathan Morley wrote:
>> 
>>> I apologize in advance for the formatting of this message. My mail
>>> configuration impeded my efforts to use ‘—send-email’.
>> 
>> Your mail is corrupted by new lines, attach the .patch file if you cannot 
>> resolve this.
> 
> Will do! Sorry about that. The mail server’s auth setup kept me from using 
> ‘—send-email’ directly. I will send future patches as attachments.

Here is a copy of my adjustments for the patch so that I could apply it for 
testing. https://gist.github.com/dericed/af69d60a99ad235b17722a64ea9413ba 

>>> This commit did pass 'make fate’ though the use of these changes requires
>>> decklink hardware so I did not add any new fate tests. By default the new
>>> optional behavior is skipped for old behavior.
>>> 
>>> ---
>>> libavdevice/decklink_common.cpp | 30 -
>>> libavdevice/decklink_common.h   | 42 ++
>>> +++
>> 
>> Why is this huge chunk of function movement needed? If there is a good 
>> reason to do that, then split it into a separate patch, if there is not, 
>> then just get rid of it.
> 
> The move here was so that I could make use of the cross platform safe 
> DECKLINK string methods. I was only able to test with linux and build on mac, 
> but I wanted to do my best to make a contribution that _could_ work on all 
> platforms. I can break this into two patches if you prefer. 
> 
>>> libavdevice/decklink_common_c.h |  1 +
>>> libavdevice/decklink_dec.cpp| 19 +++
>>> libavdevice/decklink_dec_c.c|  9 +
>>> 5 files changed, 71 insertions(+), 30 deletions(-)
>>> 
>>> diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.
>>> cpp
>>> index d8cced7c74..aab9d85b94 100644
>>> --- a/libavdevice/decklink_common.cpp
>>> +++ b/libavdevice/decklink_common.cpp
>>> @@ -77,36 +77,6 @@ static IDeckLinkIterator
>>> *decklink_create_iterator(AVFormatContext
>>> *avctx)
>>>  return iter;
>>> }
>>> 
>>> -#ifdef _WIN32
>>> -static char *dup_wchar_to_utf8(wchar_t *w)
>>> -{
>>> -char *s = NULL;
>>> -int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
>>> -s = (char *) av_malloc(l);
>>> -if (s)
>>> -WideCharToMultiByte(CP_UTF8, 0, w, -1, s, l, 0, 0);
>>> -return s;
>>> -}
>>> -#define DECKLINK_STROLECHAR *
>>> -#define DECKLINK_STRDUP dup_wchar_to_utf8
>>> -#define DECKLINK_FREE(s) SysFreeString(s)
>>> -#elif defined(__APPLE__)
>>> -static char *dup_cfstring_to_utf8(CFStringRef w)
>>> -{
>>> -char s[256];
>>> -CFStringGetCString(w, s, 255, kCFStringEncodingUTF8);
>>> -return av_strdup(s);
>>> -}
>>> -#define DECKLINK_STRconst __CFString *
>>> -#define DECKLINK_STRDUP dup_cfstring_to_utf8
>>> -#define DECKLINK_FREE(s) CFRelease(s)
>>> -#else
>>> -#define DECKLINK_STRconst char *
>>> -#define DECKLINK_STRDUP av_strdup
>>> -/* free() is needed for a string returned by the DeckLink SDL. */
>>> -#define DECKLINK_FREE(s) free((void *) s)
>>> -#endif
>>> -
>>> HRESULT ff_decklink_get_display_name(IDeckLink *This, const char
>>> **displayName)
>>> {
>>>  DECKLINK_STR tmpDisplayName;
>>> diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
>>> index 57ee7d1d68..8c5f8e9f06 100644
>>> --- a/libavdevice/decklink_common.h
>>> +++ b/libavdevice/decklink_common.h
>>> @@ -34,6 +34,36 @@
>>> #define DECKLINK_BOOL bool
>>> #endif
>>> 
>>> +#ifdef _WIN32
>>> +static char *dup_wchar_to_utf8(wchar_t *w)
>>> +{
>>> +char *s = NULL;
>>> +int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
>>> +s = (char *) av_malloc(l);
>>> +if (s)
>>> +WideCharToMultiByte(CP_UTF8, 0, w, -1, s, l, 0, 0);
>>> +return s;
>>> +}
>>> +#define DECKLINK_STROLECHAR *
>>> +#define DECKLINK_STRDUP dup_wchar_to_utf8
>>> +#define DECKLINK_FREE(s) SysFreeString(s)
>>> +#elif defined(__APPLE__)
>>> +static char *dup_cfstring_to_utf8(CFStringRef w)
>>> +{
>>> +char s[256];
>>> +CFStringGetCString(w, s, 255, kCFStringEncodingUTF8);
>>> +return av_strdup(s);
>>> +}
>>> +#define DECKLINK_STRconst __CFString *
>>> +#define DECKLINK_STRDUP dup_cfstring_to_utf8
>>> +#define DECKLINK_FREE(s) CFRelease(s)
>>> +#else
>>> +#define DECKLINK_STRconst char *
>>> +#define DECKLINK_STRDUP av_strdup
>>> +/* free() is needed for a string returned by the DeckLink SDL. */
>>> +#define DECKLINK_FREE(s) free((void *) s)
>>> +#endif
>>> +
>>> class decklink_output_callback;
>>> class decklink_input_callback;
>>> 
>>> @@ -64,6 +94,7 @@ struct decklink_ctx {
>>>  BMDDisplayMode bmd_mode;
>>>  BMDVideoConnection video_input;
>>>  BMDAudioConnection audio_input;
>>> +BMDTimecodeFormat tc_format;
>>>  int bmd_width;
>>>  

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

[Jonathan Morley]

Attached are the two patches to address your feedback, Marton. Please advise.

Thanks,
Jon



> On May 25, 2018, at 8:32 AM, Marton Balint  wrote:
> 
> 
> 
> On Fri, 25 May 2018, Jonathan Morley wrote:
> 
>> I apologize in advance for the formatting of this message. My mail
>> configuration impeded my efforts to use ‘—send-email’.
> 
> Your mail is corrupted by new lines, attach the .patch file if you cannot 
> resolve this.
> 
>> 
>> This commit did pass 'make fate’ though the use of these changes requires
>> decklink hardware so I did not add any new fate tests. By default the new
>> optional behavior is skipped for old behavior.
>> 
>> ---
>> libavdevice/decklink_common.cpp | 30 -
>> libavdevice/decklink_common.h   | 42 ++
>> +++
> 
> Why is this huge chunk of function movement needed? If there is a good reason 
> to do that, then split it into a separate patch, if there is not, then just 
> get rid of it.
> 
>> libavdevice/decklink_common_c.h |  1 +
>> libavdevice/decklink_dec.cpp| 19 +++
>> libavdevice/decklink_dec_c.c|  9 +
>> 5 files changed, 71 insertions(+), 30 deletions(-)
>> 
>> diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.
>> cpp
>> index d8cced7c74..aab9d85b94 100644
>> --- a/libavdevice/decklink_common.cpp
>> +++ b/libavdevice/decklink_common.cpp
>> @@ -77,36 +77,6 @@ static IDeckLinkIterator
>> *decklink_create_iterator(AVFormatContext
>> *avctx)
>>   return iter;
>> }
>> 
>> -#ifdef _WIN32
>> -static char *dup_wchar_to_utf8(wchar_t *w)
>> -{
>> -char *s = NULL;
>> -int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
>> -s = (char *) av_malloc(l);
>> -if (s)
>> -WideCharToMultiByte(CP_UTF8, 0, w, -1, s, l, 0, 0);
>> -return s;
>> -}
>> -#define DECKLINK_STROLECHAR *
>> -#define DECKLINK_STRDUP dup_wchar_to_utf8
>> -#define DECKLINK_FREE(s) SysFreeString(s)
>> -#elif defined(__APPLE__)
>> -static char *dup_cfstring_to_utf8(CFStringRef w)
>> -{
>> -char s[256];
>> -CFStringGetCString(w, s, 255, kCFStringEncodingUTF8);
>> -return av_strdup(s);
>> -}
>> -#define DECKLINK_STRconst __CFString *
>> -#define DECKLINK_STRDUP dup_cfstring_to_utf8
>> -#define DECKLINK_FREE(s) CFRelease(s)
>> -#else
>> -#define DECKLINK_STRconst char *
>> -#define DECKLINK_STRDUP av_strdup
>> -/* free() is needed for a string returned by the DeckLink SDL. */
>> -#define DECKLINK_FREE(s) free((void *) s)
>> -#endif
>> -
>> HRESULT ff_decklink_get_display_name(IDeckLink *This, const char
>> **displayName)
>> {
>>   DECKLINK_STR tmpDisplayName;
>> diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
>> index 57ee7d1d68..8c5f8e9f06 100644
>> --- a/libavdevice/decklink_common.h
>> +++ b/libavdevice/decklink_common.h
>> @@ -34,6 +34,36 @@
>> #define DECKLINK_BOOL bool
>> #endif
>> 
>> +#ifdef _WIN32
>> +static char *dup_wchar_to_utf8(wchar_t *w)
>> +{
>> +char *s = NULL;
>> +int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
>> +s = (char *) av_malloc(l);
>> +if (s)
>> +WideCharToMultiByte(CP_UTF8, 0, w, -1, s, l, 0, 0);
>> +return s;
>> +}
>> +#define DECKLINK_STROLECHAR *
>> +#define DECKLINK_STRDUP dup_wchar_to_utf8
>> +#define DECKLINK_FREE(s) SysFreeString(s)
>> +#elif defined(__APPLE__)
>> +static char *dup_cfstring_to_utf8(CFStringRef w)
>> +{
>> +char s[256];
>> +CFStringGetCString(w, s, 255, kCFStringEncodingUTF8);
>> +return av_strdup(s);
>> +}
>> +#define DECKLINK_STRconst __CFString *
>> +#define DECKLINK_STRDUP dup_cfstring_to_utf8
>> +#define DECKLINK_FREE(s) CFRelease(s)
>> +#else
>> +#define DECKLINK_STRconst char *
>> +#define DECKLINK_STRDUP av_strdup
>> +/* free() is needed for a string returned by the DeckLink SDL. */
>> +#define DECKLINK_FREE(s) free((void *) s)
>> +#endif
>> +
>> class decklink_output_callback;
>> class decklink_input_callback;
>> 
>> @@ -64,6 +94,7 @@ struct decklink_ctx {
>>   BMDDisplayMode bmd_mode;
>>   BMDVideoConnection video_input;
>>   BMDAudioConnection audio_input;
>> +BMDTimecodeFormat tc_format;
>>   int bmd_width;
>>   int bmd_height;
>>   int bmd_field_dominance;
>> @@ -140,6 +171,17 @@ static const BMDVideoConnection
>> decklink_video_connection_map[] = {
>>   bmdVideoConnectionSVideo,
>> };
>> 
>> +static const BMDTimecodeFormat decklink_timecode_format_map[] = {
>> +(BMDTimecodeFormat)0,
>> +bmdTimecodeRP188VITC1,
>> +bmdTimecodeRP188VITC2,
>> +bmdTimecodeRP188LTC,
>> +bmdTimecodeRP188Any,
>> +bmdTimecodeVITC,
>> +bmdTimecodeVITCField2,
>> +bmdTimecodeSerial,
>> +};
>> +
>> HRESULT ff_decklink_get_display_name(IDeckLink *This, const char
>> **displayName);
>> int ff_decklink_set_configs(AVFormatContext *avctx, decklink_direction_t
>> direction);
>> int ff_decklink_set_format(AVFormatContext *avctx, int width, int height,
>> int tb_num, int tb_den, enum 

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

[Jonathan Morley]

That sounds great, Kieran!

The plan with AJA is to leverage the open source ntv2_v4l2 (AJA video for linux 
driver) to capture audio, video, and timecode over SDI to a standard video for 
linux virtual device (aka /dev/video0). Then use the ffmpeg support for v4l2 to 
read it in and again set the TC string on the video stream metadata. I am just 
getting started after hearing confirmation from the AJA dev that he would add 
TC support to the ntv2_v4l2. In general video for linux could work as a 
consistent interface for this when capturing.

Sincerely,
Jon

> On May 25, 2018, at 10:47 AM, Kieran O Leary  wrote:
> 
> Hi Jonathan,
> 
> On Fri, May 25, 2018 at 6:32 PM, Jonathan Morley  
> wrote:
>> Hi Kieran,
>> 
>> To answer your question, this change basically takes the first valid TC as a 
>> string and sticks it in the video’s avstream metadata dictionary where other 
>> muxers and encoders look. It does not make an independent timecode 
>> track/stream with samples per frame. That is why I called the patch 
>> “limited”. However there doesn’t seem to be many if any parts of ffmpeg that 
>> use dedicated timecode streams with individual samples. That is why it still 
>> seemed worth submitting my work back as we move on to other solutions.
> 
> It sounds great to me! I think that this type of timecode (just
> storing first value as a string string) is all I've ever really seen
> in the real world(I work in the Irish Film Archive and we have several
> thousand video tapes as well). This is how AJA Control Room and
> Blackmagic Media Express work anyhow. I'm hoping that this will allow
> open source archival capture tools like
> https://github.com/amiaopensource/vrecord to be able to capture
> timecode.
> 
> I look forward to trying it out, as our goal is to be able to use
> vrecord in order to capture tape to FFV1/Matroska. Matroska doesn't
> support data tracks (yet), but ffmpeg does store the starting timecode
> string as a Matroska Tag when it detects a timecode track in a source
> video. I would love if capturing to Matroska from tape could store
> that starting timecode value, but it's a completely seperate issue to
> this patch.
> 
>> 
>> I hope that still helps you in your case. I will stay the course to address 
>> Marton’s feedback and get this in there.
> 
> yeah it's great, I'm also interested in your AJA work as we also have
> AJA hardware, though as there's no open SDK for AJA, I'm not sure how
> this would integrate into FFmpeg.
> 
> Best,
> 
> Kieran.
> ___
> 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

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

[Kieran O Leary]

Hi Jonathan,

On Fri, May 25, 2018 at 6:32 PM, Jonathan Morley  wrote:
> Hi Kieran,
>
> To answer your question, this change basically takes the first valid TC as a 
> string and sticks it in the video’s avstream metadata dictionary where other 
> muxers and encoders look. It does not make an independent timecode 
> track/stream with samples per frame. That is why I called the patch 
> “limited”. However there doesn’t seem to be many if any parts of ffmpeg that 
> use dedicated timecode streams with individual samples. That is why it still 
> seemed worth submitting my work back as we move on to other solutions.

It sounds great to me! I think that this type of timecode (just
storing first value as a string string) is all I've ever really seen
in the real world(I work in the Irish Film Archive and we have several
thousand video tapes as well). This is how AJA Control Room and
Blackmagic Media Express work anyhow. I'm hoping that this will allow
open source archival capture tools like
https://github.com/amiaopensource/vrecord to be able to capture
timecode.

I look forward to trying it out, as our goal is to be able to use
vrecord in order to capture tape to FFV1/Matroska. Matroska doesn't
support data tracks (yet), but ffmpeg does store the starting timecode
string as a Matroska Tag when it detects a timecode track in a source
video. I would love if capturing to Matroska from tape could store
that starting timecode value, but it's a completely seperate issue to
this patch.

>
> I hope that still helps you in your case. I will stay the course to address 
> Marton’s feedback and get this in there.

yeah it's great, I'm also interested in your AJA work as we also have
AJA hardware, though as there's no open SDK for AJA, I'm not sure how
this would integrate into FFmpeg.

Best,

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

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

[Jonathan Morley]

Hi Kieran,

To answer your question, this change basically takes the first valid TC as a 
string and sticks it in the video’s avstream metadata dictionary where other 
muxers and encoders look. It does not make an independent timecode track/stream 
with samples per frame. That is why I called the patch “limited”. However there 
doesn’t seem to be many if any parts of ffmpeg that use dedicated timecode 
streams with individual samples. That is why it still seemed worth submitting 
my work back as we move on to other solutions.

I hope that still helps you in your case. I will stay the course to address 
Marton’s feedback and get this in there.

Thanks,
Jon

> On May 25, 2018, at 8:59 AM, Kieran O Leary  wrote:
> 
> I'd love to see some documentation and to know how timecode is stored in
> the output file. This looks like a really welcome development!
> ___
> 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

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

[Jonathan Morley]

> On May 25, 2018, at 8:32 AM, Marton Balint  wrote:
> 
> 
> 
> On Fri, 25 May 2018, Jonathan Morley wrote:
> 
>> I apologize in advance for the formatting of this message. My mail
>> configuration impeded my efforts to use ‘—send-email’.
> 
> Your mail is corrupted by new lines, attach the .patch file if you cannot 
> resolve this.

Will do! Sorry about that. The mail server’s auth setup kept me from using 
‘—send-email’ directly. I will send future patches as attachments.

>> 
>> This commit did pass 'make fate’ though the use of these changes requires
>> decklink hardware so I did not add any new fate tests. By default the new
>> optional behavior is skipped for old behavior.
>> 
>> ---
>> libavdevice/decklink_common.cpp | 30 -
>> libavdevice/decklink_common.h   | 42 ++
>> +++
> 
> Why is this huge chunk of function movement needed? If there is a good reason 
> to do that, then split it into a separate patch, if there is not, then just 
> get rid of it.

The move here was so that I could make use of the cross platform safe DECKLINK 
string methods. I was only able to test with linux and build on mac, but I 
wanted to do my best to make a contribution that _could_ work on all platforms. 
I can break this into two patches if you prefer. 

>> libavdevice/decklink_common_c.h |  1 +
>> libavdevice/decklink_dec.cpp| 19 +++
>> libavdevice/decklink_dec_c.c|  9 +
>> 5 files changed, 71 insertions(+), 30 deletions(-)
>> 
>> diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.
>> cpp
>> index d8cced7c74..aab9d85b94 100644
>> --- a/libavdevice/decklink_common.cpp
>> +++ b/libavdevice/decklink_common.cpp
>> @@ -77,36 +77,6 @@ static IDeckLinkIterator
>> *decklink_create_iterator(AVFormatContext
>> *avctx)
>>   return iter;
>> }
>> 
>> -#ifdef _WIN32
>> -static char *dup_wchar_to_utf8(wchar_t *w)
>> -{
>> -char *s = NULL;
>> -int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
>> -s = (char *) av_malloc(l);
>> -if (s)
>> -WideCharToMultiByte(CP_UTF8, 0, w, -1, s, l, 0, 0);
>> -return s;
>> -}
>> -#define DECKLINK_STROLECHAR *
>> -#define DECKLINK_STRDUP dup_wchar_to_utf8
>> -#define DECKLINK_FREE(s) SysFreeString(s)
>> -#elif defined(__APPLE__)
>> -static char *dup_cfstring_to_utf8(CFStringRef w)
>> -{
>> -char s[256];
>> -CFStringGetCString(w, s, 255, kCFStringEncodingUTF8);
>> -return av_strdup(s);
>> -}
>> -#define DECKLINK_STRconst __CFString *
>> -#define DECKLINK_STRDUP dup_cfstring_to_utf8
>> -#define DECKLINK_FREE(s) CFRelease(s)
>> -#else
>> -#define DECKLINK_STRconst char *
>> -#define DECKLINK_STRDUP av_strdup
>> -/* free() is needed for a string returned by the DeckLink SDL. */
>> -#define DECKLINK_FREE(s) free((void *) s)
>> -#endif
>> -
>> HRESULT ff_decklink_get_display_name(IDeckLink *This, const char
>> **displayName)
>> {
>>   DECKLINK_STR tmpDisplayName;
>> diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
>> index 57ee7d1d68..8c5f8e9f06 100644
>> --- a/libavdevice/decklink_common.h
>> +++ b/libavdevice/decklink_common.h
>> @@ -34,6 +34,36 @@
>> #define DECKLINK_BOOL bool
>> #endif
>> 
>> +#ifdef _WIN32
>> +static char *dup_wchar_to_utf8(wchar_t *w)
>> +{
>> +char *s = NULL;
>> +int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
>> +s = (char *) av_malloc(l);
>> +if (s)
>> +WideCharToMultiByte(CP_UTF8, 0, w, -1, s, l, 0, 0);
>> +return s;
>> +}
>> +#define DECKLINK_STROLECHAR *
>> +#define DECKLINK_STRDUP dup_wchar_to_utf8
>> +#define DECKLINK_FREE(s) SysFreeString(s)
>> +#elif defined(__APPLE__)
>> +static char *dup_cfstring_to_utf8(CFStringRef w)
>> +{
>> +char s[256];
>> +CFStringGetCString(w, s, 255, kCFStringEncodingUTF8);
>> +return av_strdup(s);
>> +}
>> +#define DECKLINK_STRconst __CFString *
>> +#define DECKLINK_STRDUP dup_cfstring_to_utf8
>> +#define DECKLINK_FREE(s) CFRelease(s)
>> +#else
>> +#define DECKLINK_STRconst char *
>> +#define DECKLINK_STRDUP av_strdup
>> +/* free() is needed for a string returned by the DeckLink SDL. */
>> +#define DECKLINK_FREE(s) free((void *) s)
>> +#endif
>> +
>> class decklink_output_callback;
>> class decklink_input_callback;
>> 
>> @@ -64,6 +94,7 @@ struct decklink_ctx {
>>   BMDDisplayMode bmd_mode;
>>   BMDVideoConnection video_input;
>>   BMDAudioConnection audio_input;
>> +BMDTimecodeFormat tc_format;
>>   int bmd_width;
>>   int bmd_height;
>>   int bmd_field_dominance;
>> @@ -140,6 +171,17 @@ static const BMDVideoConnection
>> decklink_video_connection_map[] = {
>>   bmdVideoConnectionSVideo,
>> };
>> 
>> +static const BMDTimecodeFormat decklink_timecode_format_map[] = {
>> +(BMDTimecodeFormat)0,
>> +bmdTimecodeRP188VITC1,
>> +bmdTimecodeRP188VITC2,
>> +bmdTimecodeRP188LTC,
>> +bmdTimecodeRP188Any,
>> +bmdTimecodeVITC,
>> +

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

[Kieran O Leary]

I'd love to see some documentation and to know how timecode is stored in
the output file. This looks like a really welcome development!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Marton Balint]

On Fri, 25 May 2018, Jonathan Morley wrote:


I apologize in advance for the formatting of this message. My mail
configuration impeded my efforts to use ‘—send-email’.


Your mail is corrupted by new lines, attach the .patch file if you cannot 
resolve this.




This commit did pass 'make fate’ though the use of these changes requires
decklink hardware so I did not add any new fate tests. By default the new
optional behavior is skipped for old behavior.

---
libavdevice/decklink_common.cpp | 30 -
libavdevice/decklink_common.h   | 42 ++
+++


Why is this huge chunk of function movement needed? If there is a good 
reason to do that, then split it into a separate patch, if there is not, 
then just get rid of it.



libavdevice/decklink_common_c.h |  1 +
libavdevice/decklink_dec.cpp| 19 +++
libavdevice/decklink_dec_c.c|  9 +
5 files changed, 71 insertions(+), 30 deletions(-)

diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.
cpp
index d8cced7c74..aab9d85b94 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -77,36 +77,6 @@ static IDeckLinkIterator
*decklink_create_iterator(AVFormatContext
*avctx)
   return iter;
}

-#ifdef _WIN32
-static char *dup_wchar_to_utf8(wchar_t *w)
-{
-char *s = NULL;
-int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
-s = (char *) av_malloc(l);
-if (s)
-WideCharToMultiByte(CP_UTF8, 0, w, -1, s, l, 0, 0);
-return s;
-}
-#define DECKLINK_STROLECHAR *
-#define DECKLINK_STRDUP dup_wchar_to_utf8
-#define DECKLINK_FREE(s) SysFreeString(s)
-#elif defined(__APPLE__)
-static char *dup_cfstring_to_utf8(CFStringRef w)
-{
-char s[256];
-CFStringGetCString(w, s, 255, kCFStringEncodingUTF8);
-return av_strdup(s);
-}
-#define DECKLINK_STRconst __CFString *
-#define DECKLINK_STRDUP dup_cfstring_to_utf8
-#define DECKLINK_FREE(s) CFRelease(s)
-#else
-#define DECKLINK_STRconst char *
-#define DECKLINK_STRDUP av_strdup
-/* free() is needed for a string returned by the DeckLink SDL. */
-#define DECKLINK_FREE(s) free((void *) s)
-#endif
-
HRESULT ff_decklink_get_display_name(IDeckLink *This, const char
**displayName)
{
   DECKLINK_STR tmpDisplayName;
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 57ee7d1d68..8c5f8e9f06 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -34,6 +34,36 @@
#define DECKLINK_BOOL bool
#endif

+#ifdef _WIN32
+static char *dup_wchar_to_utf8(wchar_t *w)
+{
+char *s = NULL;
+int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
+s = (char *) av_malloc(l);
+if (s)
+WideCharToMultiByte(CP_UTF8, 0, w, -1, s, l, 0, 0);
+return s;
+}
+#define DECKLINK_STROLECHAR *
+#define DECKLINK_STRDUP dup_wchar_to_utf8
+#define DECKLINK_FREE(s) SysFreeString(s)
+#elif defined(__APPLE__)
+static char *dup_cfstring_to_utf8(CFStringRef w)
+{
+char s[256];
+CFStringGetCString(w, s, 255, kCFStringEncodingUTF8);
+return av_strdup(s);
+}
+#define DECKLINK_STRconst __CFString *
+#define DECKLINK_STRDUP dup_cfstring_to_utf8
+#define DECKLINK_FREE(s) CFRelease(s)
+#else
+#define DECKLINK_STRconst char *
+#define DECKLINK_STRDUP av_strdup
+/* free() is needed for a string returned by the DeckLink SDL. */
+#define DECKLINK_FREE(s) free((void *) s)
+#endif
+
class decklink_output_callback;
class decklink_input_callback;

@@ -64,6 +94,7 @@ struct decklink_ctx {
   BMDDisplayMode bmd_mode;
   BMDVideoConnection video_input;
   BMDAudioConnection audio_input;
+BMDTimecodeFormat tc_format;
   int bmd_width;
   int bmd_height;
   int bmd_field_dominance;
@@ -140,6 +171,17 @@ static const BMDVideoConnection
decklink_video_connection_map[] = {
   bmdVideoConnectionSVideo,
};

+static const BMDTimecodeFormat decklink_timecode_format_map[] = {
+(BMDTimecodeFormat)0,
+bmdTimecodeRP188VITC1,
+bmdTimecodeRP188VITC2,
+bmdTimecodeRP188LTC,
+bmdTimecodeRP188Any,
+bmdTimecodeVITC,
+bmdTimecodeVITCField2,
+bmdTimecodeSerial,
+};
+
HRESULT ff_decklink_get_display_name(IDeckLink *This, const char
**displayName);
int ff_decklink_set_configs(AVFormatContext *avctx, decklink_direction_t
direction);
int ff_decklink_set_format(AVFormatContext *avctx, int width, int height,
int tb_num, int tb_den, enum AVFieldOrder field_order, decklink_direction_t
direction = DIRECTION_OUT, int num = 0);
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_
c.h
index 08e9f9bbd5..32a5d70ee1 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -50,6 +50,7 @@ struct decklink_cctx {
   DecklinkPtsSource video_pts_source;
   int audio_input;
   int video_input;
+int tc_format;
   int draw_bars;
   char *format_code;
   int raw_format;
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index