#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 )
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.
Attachments (2)
Change History (11)
by , 12 years ago
comment:1 by , 12 years ago
Description: | modified (diff) |
---|
comment:2 by , 12 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
I suspect this is a duplicate of ticket #1578, at least it also works fine with -vf fps.
comment:5 by , 12 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?)
comment:6 by , 11 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 , 11 years ago
Keywords: | bounty added |
---|
comment:9 by , 10 years ago
It works ok for me with "-vf fps" I guess moving further conversation to #1578 for now...
Source mjpeg.mov (plays fine)