[FFmpeg-trac] #3164(ffmpeg:reopened): First image skipped when forcing output rate

FFmpeg trac at avcodec.org
Sat Apr 5 13:58:40 CEST 2014

#3164: First image skipped when forcing output rate
             Reporter:  slhck       |                    Owner:
                 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           |
Changes (by notedible):

 * status:  closed => reopened
 * resolution:  duplicate =>


 Replying to [comment:2 slhck]:
 > Replying to [comment:1 cehoyos]:
 > > Is the problem also reproducible when using the fps filter?
 > > {{{
 > > $ ffmpeg -y -r 1/15 -i img%02d.png -vf fps=25 out.mp4
 > > }}}
 > In that case it works perfectly in all tested players.
 > (I remember asking about what the difference between the filter and the
 `-r` option is, implementation-wise, but I think I forgot.)

 Using latest git code you can see from the files I just attached that this
 problem is present both with -vf and -r, the difference being that -vf
 cuts off the last frame, while -r cuts off the first frame. The same
 number of frames are generated, however, as shown by the output using the
 images in first-frame-missing.zip.

 Running ffmpeg using in the -vf case:
 ffmpeg -r 1/10 -i "first-frame-missing-img%02d.png" -vf fps=10 out_fps.mp4

 with output:

 frame=  201 fps=0.0 q=-1.0 Lsize=      17kB time=00:00:19.90 bitrate=

 and in the -r case:

 ffmpeg -r 1/10 -i "first-frame-missing-img%02d.png" -r 10 -pix_fmt yuv420p

 with output:

 frame=  201 fps=0.0 q=-1.0 Lsize=      19kB time=00:00:19.90 bitrate=
 7.7kbits/s dup=198 drop=0

 You can see in both cases that the number of frames is only 201, while
 there should be 300 frames, there were 198 duplicated frames where there
 should be 297, and the duration is only 00:00:19.90 when it should be
 00:00:30.00. The problem may be more apparent when using the huffyuv

 ffmpeg -r 1/10 -i "first-frame-missing-img%02d.png" -r 10 -c:v huffyuv

 generates output
 frame=    3 fps=0.0 q=0.0 Lsize=    1361kB time=00:00:20.10 bitrate=

 We can clearly see that 2 of the frames take the full ten seconds, while
 the third frame takes only one frame (0.1 seconds in this case).

Ticket URL: <https://trac.ffmpeg.org/ticket/3164#comment:6>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list