[FFmpeg-devel] MainConcept mpeg not decoding properly.

[Måns Rullgård]

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
> valid
>
> [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
bug.

> 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
>> decoder.
>
> 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.

-- 
M?ns Rullg?rd
mans at mansr.com