Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#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)

ffmpeg-20130612-131739.log (76.4 KB ) - added by Zsbán Ambrus 11 years ago.
ratelimit.tar.gz (137.9 KB ) - added by Zsbán Ambrus 11 years ago.
Input and output images

Download all attachments as: .zip

Change History (4)

by Zsbán Ambrus, 11 years ago

Attachment: ffmpeg-20130612-131739.log added

by Zsbán Ambrus, 11 years ago

Attachment: ratelimit.tar.gz added

Input and output images

comment:1 by Carl Eugen Hoyos, 11 years ago

Resolution: duplicate
Status: newclosed

Looks like a duplicate of ticket #1578, please use -vf fps.

Last edited 11 years ago by Carl Eugen Hoyos (previous) (diff)

in reply to:  1 comment:2 by Zsbán Ambrus, 11 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.

Note: See TracTickets for help on using tickets.