#8063: `-vsync cfr` tends to duplicate the wrong frames
------------------------------------+------------------------------------
Reporter: gdgsdg123 | Owner: (none)
Type: defect | Status: reopened
Priority: normal | Component: ffmpeg
Version: git-master | Resolution:
Keywords: fps | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
------------------------------------+------------------------------------
Comment (by James Johnston):
I also encountered this issue. I've attached a small 6 frame test case
named **Null-Frame-Example.avi**. I've also attached screenshots of how
the null frame is supposed to look, and how it looks after FFmpeg has
incorrectly handled it.
This test case is video that was initially recorded from a capture device
using !VirtualDub 1.9, and then trimmed using VirtualDub2 using Direct
Stream Copy mode (i.e. no recompression).
During capture, !VirtualDub inserted what are apparently known as "null
frames" or "drop frames" in the AVI file.
Here is a table of frames in the attached test case.
||**Frame number**||**Frame type**||
||0||Key frame||
||1||Key frame||
||2||Key frame||
||3||Null/drop frame||
||4||Key frame||
||5||Key frame||
If I visually inspect the input file in VirtualDub2, 6 total frames are
shown. Viewing frame index 3 will show the frame data from frame 2, and
is the output I would also expect from FFmpeg. It is denoted with the
special **[D]** tag in the status bar, indicating it is a null/drop frame.
That is, a null frame is effectively a way of repeating the previous
frame. And, that is how !VirtualDub inserts placeholder frames during
capture when the frames from the capture device are not keeping up with
the clock.
In other words, this is the expected visual output of FFmpeg, and the
observed frame table in VirtualDub2 when viewing the input:
||**Frame number**||**Frame data**||
||0||Unique||
||1||Unique||
||2||Unique||
||3||Duplicate of frame 2||
||4||Unique||
||5||Unique||
Now, suppose I run the following command:
{{{
# NOTE: using "-vsync cfr" will yield the same result
ffmpeg -i Null-Frame-Example.avi -fps_mode cfr -c:a flac -c:v ffv1 Null-
Frame-Example.mkv
}}}
I then open this output MKV file, and observe the following actual /
erroneous output:
||**Frame number**||**Frame data**||
||0||Unique||
||1||Unique||
||2||Unique||
||3||Duplicate of frame 4||
||4||Unique||
||5||Unique||
This is not correct; the frame index 3 should be from frame 2, as seen in
the earlier table.
(Side note: I did not know that AVI files could even have these kinds of
frames (most end users probably don't). My first attempt without any
"vsync" or "fps_mode" parameter at all led to totally broken frames in the
output file: the MKV file still has 6 frames according to VirtualDub2, but
it gives a "frame missing" error when trying to view frame 3. It might be
worth a consideration to make the default settings do the right thing
somehow / always duplicate the (correct) frame when encountering null/drop
frames.)
(How I got here: !AviSynth's FFmpeg-based sources would silently drop
these null frames, leading to audio/video sync issues in the output file!)
--
Ticket URL: <https://trac.ffmpeg.org/ticket/8063#comment:11>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".
