Transcoding mjpeg video results in a very short frame

[mbradshaw]

Summary of the bug:
I have a mjpeg video I've created using libav*. The video plays fine in QuickTime?, VLC, ffplay, etc. However, when I transcode the mjpeg video using FFmpeg, the first frame goes from a duration of 1.315918 seconds to just a fraction of a second. This happens on every mjpeg file I've tested that I create using libav*.

I've tried FFmpeg 1.0 and current git head; results are the same.

I suppose it's possible I'm generating the mjpeg wrong, but it plays fine in everything I've tried (QuickTime?, VLC, ffplay, etc.) with no warnings or errors, FFmpeg gives no errors or warnings when transcoding, and I've inspected the frames with ffprobe and I can't see anything wrong with the mjpeg.

How to reproduce:
Using the following command, the output file (mpg.mpg) has a short first frame and doesn't match the source mjpeg (mjpeg.mov). I have attached both files. I should note that I get the same problem when using mpeg4/aac in an mp4 container as output format.

$ ffmpeg -i mjpeg.mov -vcodec mpeg2video -acodec mp2 -r 24 -bufsize 4000000 -maxrate 5000000 mpg.mpg
ffmpeg version 1.0 Copyright (c) 2000-2012 the FFmpeg developers
  built on Nov 16 2012 15:00:58 with llvm-gcc 4.2.1 (LLVM build 2336.11.00)
  configuration: 
  libavutil      51. 73.101 / 51. 73.101
  libavcodec     54. 59.100 / 54. 59.100
  libavformat    54. 29.104 / 54. 29.104
  libavdevice    54.  2.101 / 54.  2.101
  libavfilter     3. 17.100 /  3. 17.100
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 15.100 /  0. 15.100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb25b00f200] max_analyze_duration 5000000 reached at 5000272
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'mjpeg.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    encoder         : Lavf54.29.104
  Duration: 00:00:05.27, start: 0.000000, bitrate: 631 kb/s
    Stream #0:0(eng): Video: mjpeg (jpeg / 0x6765706A), yuvj420p, 1024x768, 536 kb/s, 1.02 fps, 4.58 tbr, 44100 tbn, 44100 tbc
    Metadata:
      handler_name    : DataHandler
    Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, s16, 227 kb/s
    Metadata:
      handler_name    : DataHandler
Output #0, mpeg, to 'mpg.mpg':
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    encoder         : Lavf54.29.104
    Stream #0:0(eng): Video: mpeg2video, yuv420p, 1024x768, q=2-31, 200 kb/s, 90k tbn, 24 tbc
    Metadata:
      handler_name    : DataHandler
    Stream #0:1(eng): Audio: mp2, 44100 Hz, stereo, s16, 128 kb/s
    Metadata:
      handler_name    : DataHandler
Stream mapping:
  Stream #0:0 -> #0:0 (mjpeg -> mpeg2video)
  Stream #0:1 -> #0:1 (aac -> mp2)
Press [q] to stop, [?] for help
frame=   95 fps=0.0 q=31.0 Lsize=     766kB time=00:00:05.27 bitrate=1189.9kbits/s dup=91 drop=0    
video:678kB audio:82kB subtitle:0 global headers:0kB muxing overhead 0.751412%

In the files, the symbol clash should match with the start of each frame.

[mbradshaw]

Source mjpeg.mov (plays fine)

[mbradshaw]

Output mpg (first frame is way too short)

[cehoyos]

I suspect this is a duplicate of ticket #1587, at least it also works fine with -vf fps.

[cehoyos]

Should have been "a duplicate of ticket #1578", sorry for the typo.

[mbradshaw]

Yes, you are right. Thank you; sorry for the duplicate.

[rogerdpack]

Also reproducible like this:

ffmpeg -f lavfi -i testsrc=duration=3:size=1280x720:rate=1 -r 27 -y out.mp4

(the frame with number 0 is displayed too quickly in the resultant file). -vf fps does seem to work around the problem. I'm not sure if if vfr is "in play" in this case (is #1578 only about vfr?)

Another work around is to duplicate the first frame, mentioned here:  http://superuser.com/a/484459/39364