[FFmpeg-devel] MainConcept mpeg not decoding properly.
Sun Jan 13 19:11:44 CET 2008
Michael Niedermayer <michaelni at gmx.at> writes:
> On Fri, Jan 11, 2008 at 10:02:23PM +0000, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> > On Fri, Jan 11, 2008 at 12:03:05PM -0500, Media Streaming Services wrote:
>> >> Hi all.
>> >> I'm trying to encode mpg to 3gp and have problems with the source file.
>> >> Audio track is encoded as 140 seconds and video is 206 seconds...
>> >> http://rapidshare.com/files/82302675/DA_117588fd522.mpg.html
>> >> I've tried uploading to mplayer's ftp, but the file gets deleted soon
>> >> after I finish uploading.
>> >> it's a MainConcept muxed mpeg2-ps. Plays fin in Windows graphedit&WMP using
>> >> Mainconcept demuxer.
>> >> I have tried -vcodec h264, -acodec liba52, -f mpeg, -f svd, -f dvd,
>> >> -async 1, -vsync 1... all produce bad files, asynch had actually
>> >> produced file with equal video and audio length, but audio got
>> >> "chopped up". Is it a bug? Or am I doing something wrong?
>> >> /usr/local/bin/ffmpeg -f dvd -vcodec h264 -i DA_117588fd522.mpg
>> >> -bitexact 1 -vcodec mpeg4 -deinterlace -s 176x144 -r 12 -b 92k -nr 1
>> >> -preme 1 -bt 100k -lowres 1 -trell 1 -maxrate 110k -bufsize 256k -vol
>> >> 400 -acodec libamr_nb -ac 1 -ar 8000 -ab 12.2k -y -pass 2 9.3gp
>> > please provide a minimum command line to reproduce it and full uncut
>> > output of ffmpeg
>> Here's what I used:
>> $ ffmpeg -i DA_117588fd522.mpg -an -f image2 foo/%03d.png
>> FFmpeg version git-55839b7, Copyright (c) 2000-2008 Fabrice Bellard, et al.
>> configuration: --cc=gcc-4.2.2 --cpu=nocona --enable-gpl
>> libavutil version: 49.6.0
>> libavcodec version: 51.49.0
>> libavformat version: 52.3.0
>> libavdevice version: 52.0.0
>> built on Jan 11 2008 21:38:35, gcc: 4.2.2 (Gentoo 4.2.2 p1.0)
>> Input #0, mpeg, from 'DA_117588fd522.mpg':
>> Duration: 00:02:20.8, start: 1.830000, bitrate: 1702 kb/s
>> Stream #0.0[0x1e0]: Video: h264, yuv420p, 320x240 [PAR 1:1 DAR 4:3], 25.00 tb(r)
>> Stream #0.1[0x1c0]: Audio: mp2, 44100 Hz, stereo, 192 kb/s
>> Output #0, image2, to 'foo/%03d.png':
>> Stream #0.0: Video: png, rgb24, 320x240 [PAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25.00 tb(c)
>> Stream mapping:
>> Stream #0.0 -> #0.0
>> Press [q] to stop encoding
>> frame= 994 fps= 74 q=0.0 Lsize= -0kB time=39.8 bitrate= -0.0kbits/s
>> video:18797kB audio:0kB global headers:0kB muxing overhead -100.000114%
> the dts implicitly stored in the stream seem invalid, thus the file is not
> [mpeg @ X]0: pts=2.390 dts=2.390 size=2020
> [mpeg @ X]0: pts=2.350 dts=2.350 size=2020
Yes, there are indeed some oddities with the timestamps in that file.
> also the file uses complex frame reordering (b pyramid), while our
> h264 parser doesnt support interpolating missing timestamps.
That's not a fault in itself, so if FFmpeg can't handle it, that's a
> The generic code in lavf tries to interpolate but it just doesnt have
> enough knowlegde and with half of the timstamps being even wrong it
> cant really work ...
> Fixing playback of that file would require, first to detect and remove
> the invalid timestamps, and then extending the h264 parser to interpolate
> what is missing using the POCs from the h264 headers.
> patches for both of these are welcome i guess, after all this is the
> second mpeg-ps with such odd dts.
>> FWIW, the file plays fine with tcvp using its demuxer and lavc
> How does tcvp handle h264 with missing and half wrong timestamps?
> I assume it just sends it to the decoder and lets the decoder reorder
> the pts?
Yes, it simply outputs (whether to a display or to an encoder) the
frames in the order they are delivered by the decoder.
mans at mansr.com
More information about the ffmpeg-devel