On Wed, 6 Jun 2018, Dave Rice wrote:
On Jun 6, 2018, at 4:50 PM, Marton Balint <c...@passwd.hu> wrote:
On Mon, 4 Jun 2018, Dave Rice wrote:
In my testing the timecode value set here has corrected been associated with
the first video frame (maintaining the timecode-to-first-frame relationship as
found on the source video stream). Although only having first timecode value
known is limiting, I think this is still quite useful. This function also
mirrors how BlackMagic Media Express and Adobe Premiere handle capturing
video+timecode where only the first value is documented and all subsequent
values are presumed.
Could you give me an example? (e.g. ffmpeg command line?)
./ffmpeg -timecode_format vitc2 -f decklink -draw_bars 0 -audio_input embedded
-video_input sdi -format_code ntsc -channels 8 -raw_format yuv422p10 -i "UltraStudio
3D" -c:v v210 -c:a aac output.mov
This worked for me to embed a QuickTime timecode track based upon the timecode
value of the first frame. If the input contained non-sequential timecode values
then the timecode track would not be accurate from that point onward, but
creating a timecode track based only upon the initial value is what BlackMagic
Media Express and Adobe Premiere are doing anyhow.
Hmm, either the decklink drivers became better in hinding the first few
NoSignal frames, or maybe that issue only affected to old models? (e.g.
DeckLink SDI or DeckLink Duo 1). I did some test with a Mini Recorder, and even
the first frame was useful, in this case the timecode was indeed correct.
I'd rather see a new AVPacketSideData type which will contain the timecode as a
string, so you can set it frame-by-frame.
Using side data for timecode would be preferable, but the possibility that a
patch for that may someday arrive shouldn’t completely block this more limited
patch.
I would like to make sure the code works reliably even for the limited use case
and no race conditions are affectig the way it works.
Feel welcome to suggest any testing. I’ll have access for testing again
tomorrow.
I reworked the patch a bit (see attached), and added per-frame timcode support
into the PKT_STRINGS_METADATA packet side data, this way the drawtext filter
can also be used to blend the timecode into the frames, which seems like a
useful feature.
That sounds helpful.
libavdevice/decklink_dec.cpp:734:21: error: unknown type name 'DECKLINK_STR'
DECKLINK_STR decklink_tc;
The patch I sent only replaces the second patch, the first one:
http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180526/185eb219/attachment.obj
is still needed.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
