Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#2664 closed defect (duplicate)

First three frames kept when reducing frame rate with -r option

Reported by: b_jonas 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 b_jonas 4 years ago.
ratelimit.tar.gz (137.9 KB) - added by b_jonas 4 years ago.
Input and output images

Download all attachments as: .zip

Change History (4)

Changed 4 years ago by b_jonas

Changed 4 years ago by b_jonas

Input and output images

comment:1 follow-up: Changed 4 years ago by cehoyos

  • Resolution set to duplicate
  • Status changed from new to closed

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

Version 0, edited 4 years ago by cehoyos (next)

comment:2 in reply to: ↑ 1 Changed 4 years ago by b_jonas

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.