Possible dead loop while making snapshot from a MP4

[tewilove]

Summary of the bug:
CPU 100%.
How to reproduce:

[akira@localhost Temp]$ ffmpeg -i sm18304895.mp4 -y -f image2 -ss 479.342 -vframes 1 208bbd48b6dd6d31a5a0636dfd88ead0.jpg
ffmpeg version 0.10.4 Copyright (c) 2000-2012 the FFmpeg developers
  built on Jun 13 2012 09:51:06 with gcc 4.7.0 20120507 (Red Hat 4.7.0-5)
  configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --extra-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --enable-bzlib --disable-crystalhd --enable-gnutls --enable-libass --enable-libcdio --enable-libcelt --enable-libdc1394 --disable-indev=jack --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-openal --enable-libopenjpeg --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab --enable-avfilter --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect
  libavutil      51. 35.100 / 51. 35.100
  libavcodec     53. 61.100 / 53. 61.100
  libavformat    53. 32.100 / 53. 32.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 61.100 /  2. 61.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0.  6.100 /  0.  6.100
  libpostproc    52.  0.100 / 52.  0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'sm18304895.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 1
    compatible_brands: isom
    creation_time   : 2012-07-08 02:22:48
    copyright       : 
    copyright-eng   : 
  Duration: 00:09:43.42, start: 0.000000, bitrate: 1389 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720, 1319 kb/s, 60 fps, 239.76 tbr, 240k tbn, 120 tbc
    Metadata:
      creation_time   : 2012-07-08 05:21:08
      handler_name    : Imported with GPAC 0.4.6-DEV-git-62b7369
    Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, s16, 62 kb/s
    Metadata:
      creation_time   : 2012-07-08 02:22:48
      handler_name    : GPAC ISO Audio Handler
Incompatible pixel format 'yuv420p' for codec 'mjpeg', auto-selecting format 'yuvj420p'
[buffer @ 0xf7f8a0] w:1280 h:720 pixfmt:yuv420p tb:1/1000000 sar:0/1 sws_param:
[buffersink @ 0xf7fca0] auto-inserting filter 'auto-inserted scale 0' between the filter 'src' and the filter 'out'
[scale @ 0xf5cec0] w:1280 h:720 fmt:yuv420p -> w:1280 h:720 fmt:yuvj420p flags:0x4
Output #0, image2, to '208bbd48b6dd6d31a5a0636dfd88ead0.jpg':
  Metadata:
    major_brand     : isom
    minor_version   : 1
    compatible_brands: isom
    creation_time   : 2012-07-08 02:22:48
    copyright       : 
    copyright-eng   : 
    encoder         : Lavf53.32.100
    Stream #0:0(und): Video: mjpeg, yuvj420p, 1280x720, q=2-31, 200 kb/s, 90k tbn, 239.76 tbc
    Metadata:
      creation_time   : 2012-07-08 05:21:08
      handler_name    : Imported with GPAC 0.4.6-DEV-git-62b7369
Stream mapping:
  Stream #0:0 -> #0:0 (h264 -> mjpeg)
Press [q] to stop, [?] for help

[tewilove]

File will be uploaded to a 3rd-party site soon.

​http://115.com/file/c2v4ys4s#sm18304895.mp4

[Cigaes]

Try the same command line replacing 479.342 first with 2, then again with 20: does the first one finish almost immediately while the second one seems to freeze for a noticeable amount of time before finishing?

[tewilove]

Replying to Cigaes:

Try the same command line replacing 479.342 first with 2, then again with 20: does the first one finish almost immediately while the second one seems to freeze for a noticeable amount of time before finishing?

Yes. I mean both 2 and 20 finishes immediately while the parameter specified in the command line above freezes with exhausting CPU time.

[Cigaes]

Them measure the time it took for 20, multiply it by 24, and wait that amount of time for your original 479.342, because that is the time necessary to decode and skip 479 seconds of HD video.

You can add a kind of progress indication if you add this to the end of your command line: -f framecrc -r 1 -an -sn -t 480 -

You could also speed-up things by putting -ss as an input option, but the time would be much less accurate as it would only jump to keyframes.

[Carl Eugen Hoyos]

Replying to tewilove:

File will be uploaded to a 3rd-party site soon.

​http://115.com/file/beaw4vz9#sm18304895.mp4.tar.xz

If you want support, please upload the sample to ​http://www.datafilehost.com/

[tewilove]

Replying to cehoyos:

Replying to tewilove:

File will be uploaded to a 3rd-party site soon.

​http://115.com/file/beaw4vz9#sm18304895.mp4.tar.xz

If you want support, please upload the sample to ​http://www.datafilehost.com/

​http://www.datafilehost.com/download-54d887cc.html

[Carl Eugen Hoyos]

Works fine here.

Please note that it does make a difference where you put -ss 479.342:
If you put it behind the input file, every frame is decoded until the time is reached, this may take a long time (depending on hardware and input), the result is very exact. If you put the seek command before the input file, ffmpeg seeks (fast) approximately to the requested position, this is less exact.