#2664 closed defect (duplicate)
First three frames kept when reducing frame rate with -r option
Reported by: | Zsbán Ambrus | Owned by: | |
---|---|---|---|
Priority: | minor | Component: | undetermined |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
When I reduce the frame rate of a video using the -r
option, the first three frames of the input are copied to the output. I believe that only the first frame should be copied, the next frame of the ouput should be a later frame of the input.
This bug is the most obvious when writing image or rawvideo output, but I believe it can occur even when writing a video with a container too. This occurs even if I read a video, I'm using an image sequence as the input below only because that way is easier to give a reproducible sequence.
Using the fps
filter instead of the -r
option seems to be an effective workaround to avoid the bug.
How to reproduce. I have tried the following instructions on Windows 7 amd64, with the Zeranoe FFmpeg builds ffmpeg version N-53307-g5a65fea built on May 20 2013 22:46:15 with gcc 4.7.3 (GCC).
First, I have created a sequence of paletted png input images lbl-0000.png to lbl-0350.png inclusive, each showing the same number as in the filename clearly. For this I used the following ImageMagick command, where im-convert is an alias that invokes the convert command from ImageMagick-6.8.3-Q16 x86_64.
e:\ambrus\f\kozlek\tmp\dump>rem perl -we "use feature q(:5.14); for $n (0..350) { my $p = sprintf q(%04d), $n; $c = qq(im-convert -font \x22Bitstream-Vera-Sans-Mono\x22 -pointsize 18 -background #000000 -fill #ffffff -gravity Center -size 64x64 label:$p lbl-$p.png ); say $c; system $c and die; }"
Then, I ran the following ffmpeg command.
ffmpeg -v 99 -report -r 30 -i lbl-%04d.png -r 1 rate-%04d.png
This has created output files named rate-0001.png to rate-0015.png inclusive, with the images clearly showing the following text: 0000, 0001, 0002, 0015, 0045, 0075, 0105, 0135, 0165, 0195, 0225, 0255, 0285, 0315, 0345. That shows that all of the first three frames of the input have been copied.
I will attach the logfile of the ffmpeg run to this ticket (77 kilobytes of size).
Attachments (2)
Change History (4)
by , 12 years ago
Attachment: | ffmpeg-20130612-131739.log added |
---|
by , 12 years ago
Attachment: | ratelimit.tar.gz added |
---|
follow-up: 2 comment:1 by , 12 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Looks like a duplicate of ticket #1578, please test -vf fps
.
comment:2 by , 12 years ago
Replying to cehoyos:
Looks like a duplicate of ticket #1578, please test
-vf fps
.
I have tested with the following command.
ffmpeg -v 99 -report -r 30 -i lbl-%04d.png -vf fps=1 fps-%04d.png
This does not reproduce the bug, it gives apparently correct output. The output has files named fps-0001.png to fps-00013.png, containing the following text: 0000, 0015, 0045, 0075, 0105, 0135, 0165, 0195, 0225, 0255, 0285, 0315, 0345.
Input and output images