On 15-11-2019 03:02 am, Marton Balint wrote:
On Wed, 13 Nov 2019, Ilinca Tudose wrote:
My previous email was incorrect about "-wait_for_tc 1". The 2
commands used
were:
(1)
ffmpeg -loglevel trace -timecode_format rp188any -wait_for_tc 1 -f
decklink -probesize 15M -analyzeduration 5M -i "DeckLink Quad (1)" -t 30
-preset veryfast output.mov
(2)
ffmpeg -loglevel trace -timecode_format rp188any -wait_for_tc 1 -f
decklink -i "DeckLink Quad (1)" -t 30 -preset veryfast output.mov
The second command is the one that produced 1 frame offset in 3 of the
captures. The first command had 0 frames offset for all files tried.
These two command lines are only different in probesize and
analyzeduration. I don't understand how these two options can make any
difference regarding the TC offset. Can you figure out which one
actually causes the issue?
It's not related. Initially,before my patch, they were trying to capture
TC with format_code set. Because of the lag, the probe limits would
usually be exhausted before the TC arrived.
With my initial patch in July, which compensated for the lag, extended
probe was still required. With the current one, it's not.
Ilinca can supply details but the offset occurs infrequently and on
repeating the capture, would not show an offset. BM Decklink support has
been unable to reproduce the issue with their capture utility.
Gyan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
