[FFmpeg-devel] MainConcept mpeg not decoding properly.
Sun Jan 13 16:26:10 CET 2008
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
also the file uses complex frame reordering (b pyramid), while our
h264 parser doesnt support interpolating missing timestamps.
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
Thats sadly something hwich works only well with direct playback, for
generic transcoding where there might be no decoder involved things like that
Btw, What do the official h264-mpeg-ps specs say about dts? maybe ISO
redefined their meaning to being random?
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel