FFMPEG dropping frames while encoding JPEG sequence at color change

4

I'm trying to put together a slide show using imagemagick and FFMPEG. I use imagemagick to expand a single photo into 30fps video (imagemagick also handles things like putting some text captions on the frames along the way). When I go to let ffmpeg digest it into a video it clips along nicely on the color parts of the video, but when it gets to a black and white section it reports frame= 2030 fps=102 q=32766.0 Lsize= 5203kB time=00:01:07.60 bitrate= 630.5kbits/s dup=0 drop=703 and drops every frame of video until it hits something with color. As you can imagine this results in entire photos being removed from the slideshow.

Here is my latest dump...

ffmpeg -y -r 30 -i "teststream/%06d.jpg" -c:v libx264 -r 30 newffmpeg.mp4

ffmpeg version git-2012-12-10-c3bb333 Copyright (c) 2000-2012 the FFmpeg developers
built on Dec 10 2012 22:02:04 with gcc 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
configuration: --enable-gpl --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-librtmp --enable-libtheora --enable-libvorbis --enable-libx264 --enable-nonfree --enable-version3
  libavutil      52. 12.100 / 52. 12.100
  libavcodec     54. 79.101 / 54. 79.101
  libavformat    54. 49.100 / 54. 49.100
  libavdevice    54.  3.102 / 54.  3.102
  libavfilter     3. 26.101 /  3. 26.101
  libswscale      2.  1.103 /  2.  1.103
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
Input #0, image2, from 'teststream/%06d.jpg':
Duration: 00:12:02.80, start: 0.000000, bitrate: N/A
  Stream #0:0: Video: mjpeg, yuvj444p, 720x480 [SAR 72:72 DAR 3:2], 25 fps, 25 tbr, 25 tbn, 25 tbc
[libx264 @ 0x3450140] using SAR=1/1
[libx264 @ 0x3450140] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
[libx264 @ 0x3450140] profile High, level 3.0
[libx264 @ 0x3450140] 264 - core 129 r2 1cffe9f - 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=-2 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 'newffmpeg.mp4':
  Metadata:
    encoder         : Lavf54.49.100
    Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuvj420p, 720x480 [SAR 1:1 DAR 3:2], q=-1--1, 15360 tbn, 30 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (mjpeg -> libx264)
Press [q] to stop, [?] for help
Input stream #0:0 frame changed from size:720x480 fmt:yuvj444p to size:720x480 fmt:yuvj422p
Input stream #0:0 frame changed from size:720x480 fmt:yuvj422p to size:720x480 fmt:yuvj444pp=584    
frame= 2030 fps=102 q=32766.0 Lsize=    5203kB time=00:01:07.60 bitrate= 630.5kbits/s dup=0 drop=703    
video:5179kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.472425%
[libx264 @ 0x3450140] frame I:9     Avg QP:20.10  size: 33933
[libx264 @ 0x3450140] frame P:636   Avg QP:24.12  size:  6737
[libx264 @ 0x3450140] frame B:1385  Avg QP:27.04  size:   514
[libx264 @ 0x3450140] consecutive B-frames:  2.5% 15.2% 13.2% 69.2%
[libx264 @ 0x3450140] mb I  I16..4:  8.3% 80.3% 11.5%
[libx264 @ 0x3450140] mb P  I16..4:  1.5%  2.5%  0.2%  P16..4: 41.7% 18.0% 10.3%  0.0%  0.0%    skip:25.9%
[libx264 @ 0x3450140] mb B  I16..4:  0.0%  0.0%  0.0%  B16..8: 26.6%  0.6%  0.1%  direct: 0.2%  skip:72.3%  L0:35.0% L1:60.3% BI: 4.7%
[libx264 @ 0x3450140] 8x8 transform intra:64.1% inter:75.1%
[libx264 @ 0x3450140] coded y,uvDC,uvAC intra: 51.6% 78.0% 43.7% inter: 10.6% 14.9% 2.1%
[libx264 @ 0x3450140] i16 v,h,dc,p: 29% 19%  6% 46%
[libx264 @ 0x3450140] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 15% 17%  5%  9% 10%  7%  8%  6%
[libx264 @ 0x3450140] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 18% 11%  5%  9% 10%  6%  6%  4%
[libx264 @ 0x3450140] i8c dc,h,v,p: 46% 18% 24% 12%
[libx264 @ 0x3450140] Weighted P-Frames: Y:20.1% UV:18.7%
[libx264 @ 0x3450140] ref P L0: 59.2% 23.2% 13.1%  4.3%  0.2%
[libx264 @ 0x3450140] ref B L0: 88.7%  8.3%  3.0%
[libx264 @ 0x3450140] ref B L1: 95.0%  5.0%
[libx264 @ 0x3450140] kb/s:626.88
Received signal 2: terminating.

One last note: If I remove the -r 30 from the input and output it works flawlessly. I have no idea why the -r 30 is causing it to freak out.

Matt

Posted 2012-12-10T23:04:30.670

Reputation: 43

Answers

3

Forcing the frame rate for both input (before -i) and output (before the output file name) only reliably works when you use raw input files, such as h.264 bitstreams, where you explicitly need to tell FFmpeg what frame rate you expect.

In the case of reading images, you can see that the image2 module will still read at 25 frames per second, even though you specified -r 30 before -i:

Stream #0:0: Video: mjpeg, […] 25 fps, 25 tbr, 25 tbn, 25 tbc

The actual option you should use for image2 is -framerate:

ffmpeg -framerate 30 -i "teststream/%06d.jpg" -c:v libx264 -r 30 newffmpeg.mp4

This should set the input rate correctly, but since you mentioned that it works when leaving out both options, I'd just stick to that.

slhck

Posted 2012-12-10T23:04:30.670

Reputation: 182 472

That is a typical "FFmpeg documentation" case. You have to know it to find the problem ;) – TheSHEEEP – 2016-07-26T10:56:59.497

Still I wonder why specifying the superfluous -r option makes ffmpeg skip frames if their format is different from the first frame. To me that behavior is really surprising. – Robert – 2017-01-15T20:07:42.010

Thank you! Also a thanks for Darth Android - I couldn't figure out how to format that to save my life... – Matt – 2012-12-11T13:35:10.420

I was trying to turn a series of PNGs into an MP4. ffmpeg was randomly dropping frames. using -framerate instead of -r for the input fps setting did the trick. – Raffael – 2013-03-17T23:54:12.573