Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#3164 closed defect (duplicate)

First image skipped when forcing output rate

Reported by: slhck Owned by:
Priority: normal Component: ffmpeg
Version: git-master Keywords: fps
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Attachments (3)

first-frame-missing.zip (207.9 KB) - added by slhck 4 years ago.
out_fps.mp4 (16.4 KB) - added by notedible 3 years ago.
Showing last frame cut off from -vf fps
out_r.mp4 (18.3 KB) - added by notedible 3 years ago.
Showing first frame cut off from -r on output

Download all attachments as: .zip

Change History (11)

Changed 4 years ago by slhck

comment:1 follow-up: Changed 4 years ago by 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

comment:2 in reply to: ↑ 1 ; follow-up: Changed 4 years ago by 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.)

comment:3 Changed 4 years ago by cehoyos

  • Component changed from undetermined to FFmpeg
  • Keywords fps added
  • Resolution set to duplicate
  • Status changed from new to closed

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

comment:4 follow-up: Changed 4 years ago by 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.

comment:5 in reply to: ↑ 4 Changed 4 years ago by cehoyos

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.

Changed 3 years ago by notedible

Showing last frame cut off from -vf fps

Changed 3 years ago by notedible

Showing first frame cut off from -r on output

comment:6 in reply to: ↑ 2 ; follow-up: Changed 3 years ago by notedible

  • Resolution duplicate deleted
  • Status changed from closed to reopened

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.

Last edited 3 years ago by notedible (previous) (diff)

comment:7 in reply to: ↑ 6 ; follow-up: Changed 3 years ago by cehoyos

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

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

Last edited 3 years ago by cehoyos (previous) (diff)

comment:8 in reply to: ↑ 7 Changed 3 years ago by notedible

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.

Note: See TracTickets for help on using tickets.