[Ffmpeg-cvslog] r8334 - trunk/libavformat/matroska.c

[Baptiste Coudurier]

Aurelien Jacobs wrote:
> On Tue, 13 Mar 2007 21:06:47 +0100
> Michael Niedermayer <michaelni at gmx.at> wrote:
> 
>> Hi
>>
>> 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
> code.
> 

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...
Name: h264_parse_complete_frames.patch
Type: text/x-diff
Size: 661 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20070314/6883f5ec/attachment.patch>