[Ffmpeg-cvslog] r8334 - trunk/libavformat/matroska.c
Wed Mar 14 11:27:16 CET 2007
Aurelien Jacobs wrote:
> On Tue, 13 Mar 2007 21:06:47 +0100
> Michael Niedermayer <michaelni at gmx.at> wrote:
>> On Tue, Mar 13, 2007 at 03:35:27PM +0200, Uoti Urpala wrote:
>>> On Tue, 2007-03-13 at 13:53 +0100, Michael Niedermayer wrote:
>>>> the pts->dts code fails if EVERY of the following assumtations is true
>>>> codec is h.264
>>>> complex frame reordering is used (like b pyramid)
>>>> pts are available
>>>> dts are not available
>>>> dts are equal to sorted pts
>>> The code also seems to use pkt->duration, which cannot be known
>>> correctly based on pts without demuxing further. Does it always work
>>> right with simpler frame reordering but VFR? Also with the Matroska
>> ive already said that the code works, if you have found a case where
>> it fails (except h.264 stuff), then please submit a bugreport
>>> sample I tested even the incorrect dts calculation logic was not
>>> triggered at all, but dts was always set equal to pts.
>> well id guess the matroska demuxer or parser forgot to set some things
>> correctly, maybe has_b_frames or the frame type, or maybe theres no
>> parser at all initalized ...
> Now that I read this, this seems so simple !
> I wonder why I didn't thought about setting st->need_parsing myself...
> See quick and dirty attached patch. It disable my custom pts reordering
> code and set st->need_parsing. And this indeed gives a smooth playback
> for soraya.mkv.
Yes since parsing will find picture type for mpeg2, set has_b_frame,
presentation delayed, etc...
> Wait... That's not so simple. With the attached patch, planet.earth.mkv
> don't play at all ! It gives only sound, no video. Probably another
> small stupid mistake, but I'm too tired right now. I will look at
> this tomorrow, and hopefully, we can get ride of my ugly pts reordering
It seems h264 decoder fails somewhere:
Input #0, matroska, from 'planet.earth.mkv':
Duration: 00:01:02.3, bitrate: N/A
Stream #0.0, 1/1000: Audio: ac3, 48000 Hz, 5:1
Stream #0.1, 1/1000: Video: h264, 1280x720, 1/25, 25.00 fps(r)
There is no pix_fmt info (yuv420p), I suspect decoder to fail because of
parsing does something wrong.
Attached a quick patch to h264 to support need_parsing 2, but still it
seems under H264 dts computation special case, going further would
require h264 parser to compute pict type, and deduce dts accordingly.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 661 bytes
Desc: not available
More information about the ffmpeg-cvslog