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

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
>
> On Wed, Mar 14, 2007 at 07:17:41PM +0000, M?ns Rullg?rd wrote:
>> Rich Felker <dalias at aerifal.cx> writes:
>> 
>> > On Wed, Mar 14, 2007 at 12:24:22PM +0100, Baptiste Coudurier wrote:
>> >> >> seems under H264 dts computation special case, going further would
>> >> >> require h264 parser to compute pict type, and deduce dts accordingly.
>> >> > 
>> >> > picture type is insufficient to find DTS for h.264 ...
>> >> 
>> >> ok.... sadly.
>> >
>> > why can't you just use the max pyramid depth and the nut algorithm to
>> > get dts??
>> 
>> How do you find the pyramid depth?  Besides, H.264 allows much more
>> complex frame dependencies than a simple pyramid.
>
> all reordering variants which cannot drop frames during reorder will get 
> correct DTS with the nut algorithm 
>
> the proof is trivial
> our foobar codec has a picture buffer, each picture in it has a PTS
> when we input a new frame we simply put it into the buffer with its pts
> when we output a frame it has to be the one with the lowest PTS, why?
> if we would output another one we couldnt output the one with the lowest 
> PTS anymore as it would lay in the past
> now for this to work we need to know when a frame is input and when one
> is output, input is trivial, output happens for each frame input as soon
> as the buffer is full and for that we need to know the buffer size

Yes, that all makes perfect sense.  I don't know why you call it "the
nut algorithm" though.  It's how any decoder works.

> so what we need in practice is quite trivial but it will not work 100%,
> nothing will short of a O(n) scan through the file ...

That's what I was getting at.

> first av_find_stream_info() has to run the h.264 decoder over the first
> few (10-20) frames to get the buffer size (AVCodecContext.has_b_frames)
> this is easy it probably just requires us to prevent the loop in 
> av_find_stream_info() from exiting too early for the h.264 case ...

The problem is that you can't be sure that the next frame in display
order after the last one you examined isn't the last coded frame in
the file.  H.264 allows this.  It may be unlikely, but it is possible.

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