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

[Uoti Urpala]

On Wed, 2007-03-14 at 22:25 +0100, Michael Niedermayer wrote:
> 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

This is basically what MPlayer does with -correct-pts.

> 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

Though MPlayer uses actual decoder behavior to detect when a frame is
output, and only uses direct delay information (from decoder) to detect
cases where a frame is dropped (input packet with no corresponding
output).

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

If it's going to do something potentially expensive then making it
optional might be worthwhile. If you're going to decode the stream later
then it can be done more reliably at that time, when the decoder used
can tell how many frames it actually does buffer at the moment.