First image skipped when forcing output rate

[slhck]

When converting single images to a video, setting the output frame rate causes the resulting video to skip the first image (shown only for one frame?), and proceed to the second one.

Assuming three PNG images as input:

./ffmpeg -y -r 1/15 -i img%02d.png -r 25 out.mp4
ffmpeg version N-58429-gccdfa3e Copyright (c) 2000-2013 the FFmpeg developers
  built on Nov 24 2013 12:12:30 with Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
  configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-libaacplus --enable-libass --enable-libcelt --enable-libfaac --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-openssl --enable-libopus --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvo-aacenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid
  libavutil      52. 54.100 / 52. 54.100
  libavcodec     55. 44.100 / 55. 44.100
  libavformat    55. 21.101 / 55. 21.101
  libavdevice    55.  5.100 / 55.  5.100
  libavfilter     3. 91.100 /  3. 91.100
  libswscale      2.  5.101 /  2.  5.101
  libswresample   0. 17.104 /  0. 17.104
  libpostproc    52.  3.100 / 52.  3.100
Input #0, image2, from 'img%02d.png':
  Duration: 00:00:00.12, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: png, rgba, 640x480, 25 fps, 25 tbr, 25 tbn, 25 tbc
No pixel format specified, yuv444p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264 @ 0x7fc989816800] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
[libx264 @ 0x7fc989816800] profile High 4:4:4 Predictive, level 3.0, 4:4:4 8-bit
[libx264 @ 0x7fc989816800] 264 - core 125 - H.264/MPEG-4 AVC codec - Copyleft 2003-2012 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=4 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'out.mp4':
  Metadata:
    encoder         : Lavf55.21.101
    Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv444p, 640x480, q=-1--1, 12800 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (png -> libx264)
Press [q] to stop, [?] for help
frame=  751 fps=0.0 q=-1.0 Lsize=      47kB time=00:00:29.96 bitrate=  13.0kbits/s dup=748 drop=0
video:38kB audio:0kB subtitle:0 global headers:0kB muxing overhead 25.246747%
[libx264 @ 0x7fc989816800] frame I:4     Avg QP:20.10  size:  2471
[libx264 @ 0x7fc989816800] frame P:189   Avg QP:27.91  size:    49
[libx264 @ 0x7fc989816800] frame B:558   Avg QP:28.00  size:    34
[libx264 @ 0x7fc989816800] consecutive B-frames:  0.9%  0.0%  0.0% 99.1%
[libx264 @ 0x7fc989816800] mb I  I16..4:  0.8% 93.0%  6.2%
[libx264 @ 0x7fc989816800] mb P  I16..4:  0.1%  0.0%  0.0%  P16..4:  0.1%  0.0%  0.0%  0.0%  0.0%    skip:99.8%
[libx264 @ 0x7fc989816800] mb B  I16..4:  0.1%  0.2%  0.0%  B16..8:  0.4%  0.0%  0.0%  direct: 0.0%  skip:99.3%  L0:50.8% L1:49.2% BI: 0.0%
[libx264 @ 0x7fc989816800] 8x8 transform intra:79.5% inter:1.1%
[libx264 @ 0x7fc989816800] coded y,u,v intra: 2.4% 0.0% 0.0% inter: 0.0% 0.0% 0.0%
[libx264 @ 0x7fc989816800] i16 v,h,dc,p: 23% 68%  9%  0%
[libx264 @ 0x7fc989816800] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28%  9% 64%  0%  0%  0%  0%  0%  0%
[libx264 @ 0x7fc989816800] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 32% 26%  4%  1%  1%  4%  2%  4%
[libx264 @ 0x7fc989816800] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x7fc989816800] ref P L0: 89.5%  3.7%  3.7%  3.2%
[libx264 @ 0x7fc989816800] ref B L0: 69.7% 29.3%  1.0%
[libx264 @ 0x7fc989816800] ref B L1: 95.8%  4.2%
[libx264 @ 0x7fc989816800] kb/s:10.14

Here's what I observed:

• When I use libx264, QuickTime will show the first frame correctly, but ffplay and VLC will skip it.
• When I use libxvid, QuickTime, ffplay and VLC skip the first frame.

I will upload samples.

[Carl Eugen Hoyos]

Is the problem also reproducible when using the fps filter?

$ ffmpeg -y -r 1/15 -i img%02d.png -vf fps=25 out.mp4

[slhck]

Replying to 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.)

[Carl Eugen Hoyos]

Then I don't think there is anything to fix, please use -vf fps and consider watching ticket #1578

[slhck]

Interesting, thanks. Well, I would assume there is something to fix — at least the documentation — because the command you'd expect to work does not behave correctly. The documentation clearly mentions:

ffmpeg -f image2 -i foo-%03d.jpeg -r 12 -s WxH foo.avi
ffmpeg -f image2 -pattern_type glob -i 'foo-*.jpeg' -r 12 -s WxH foo.avi

So if the fps filter should be used in these cases, the documentation and the wiki need to be updated.

[Carl Eugen Hoyos]

Replying to slhck:

Interesting, thanks. Well, I would assume there is something to fix

I don't disagree, my wording was bad, sorry.
What I meant was: There is not more to fix about this ticket than about several existing tickets that contain complaints that -r works different from -vf fps.
Note that the pullup filter does not work correctly with the fps filter, it currently needs -r.

[Ananta Palani]

Showing last frame cut off from -vf fps

[Ananta Palani]

Showing first frame cut off from -r on output

[Ananta Palani]

Replying to slhck:

Replying to 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=   7.1kbits/s

and in the -r case:

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

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 codec:

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

generates output

frame=    3 fps=0.0 q=0.0 Lsize=    1361kB time=00:00:20.10 bitrate= 554.5kbits/s

We can clearly see that 2 of the frames take the full ten seconds, while the third frame takes only 0.1 seconds.

[Carl Eugen Hoyos]

Replying to notedible:

Using latest git code you can see from the files I just attached that this problem is present both with -vf and -r

(Assuming you mean: Neither -r nor -vf fps are perfect:)
Sure, if it were different, -r would simply call the video filter.

the difference being that -vf cuts off the last frame

Making it a duplicate of ticket #2674 or do I miss something?

while -r cuts off the first frame.

This is one aspect of ticket #1578.

Please consider watching both tickets and open a new ticket if it turns out I am wrong once one of them is fixed (this ticket is about a problem that was shown to be solved with -vf fps iiuc).

[Ananta Palani]

Replying to cehoyos:

Replying to notedible:

the difference being that -vf cuts off the last frame

Making it a duplicate of ticket #2674 or do I miss something?

Ah, thanks, I hadn't found #2674. I was mostly observing that -vf fps is not really a solution since it causes an equally bad problem, just at the other end, but you're right, it does solve the problem as originally stated. Hopefully one of them will be fixed soon.