Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#1925 closed defect (duplicate)

Transcoding mjpeg video results in a very short frame

Reported by: mbradshaw Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: bounty
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description (last modified by 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 ( 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 -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)
  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 '':
    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
      handler_name    : DataHandler
    Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, s16, 227 kb/s
      handler_name    : DataHandler
Output #0, mpeg, to 'mpg.mpg':
    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
      handler_name    : DataHandler
    Stream #0:1(eng): Audio: mp2, 44100 Hz, stereo, s16, 128 kb/s
      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.

Attachments (2) (406.9 KB ) - added by mbradshaw 9 years ago.
Source (plays fine)
mpg.mpg (766.0 KB ) - added by mbradshaw 9 years ago.
Output mpg (first frame is way too short)

Download all attachments as: .zip

Change History (11)

by mbradshaw, 9 years ago

Attachment: added

Source (plays fine)

by mbradshaw, 9 years ago

Attachment: mpg.mpg added

Output mpg (first frame is way too short)

comment:1 by mbradshaw, 9 years ago

Description: modified (diff)

comment:2 by Carl Eugen Hoyos, 9 years ago

Resolution: duplicate
Status: newclosed

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

Version 0, edited 9 years ago by Carl Eugen Hoyos (next)

comment:3 by Carl Eugen Hoyos, 9 years ago

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

comment:4 by mbradshaw, 9 years ago

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

comment:5 by Roger Pack, 9 years ago

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:

Last edited 9 years ago by Roger Pack (previous) (diff)

comment:6 by Roger Pack, 8 years ago

It's unclear if it's an exact dupe or not (may be related).
Anyway, regardless, I am offering a bounty of $100 USD if anybody can fix this particular one. Thank you.

comment:7 by llogan, 8 years ago

Keywords: bounty added

comment:8 by Carl Eugen Hoyos, 8 years ago

Could you explain how the problem is reproducible with -vf fps ?

comment:9 by Roger Pack, 7 years ago

It works ok for me with "-vf fps" I guess moving further conversation to #1578 for now...

Note: See TracTickets for help on using tickets.