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

[Loren Merritt]

On Wed, 14 Mar 2007, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
>
>> 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.

H.264 only allows that if there are fewer than 16 frames remaining in the 
file, because H.264's max decoded picture buffer size is 16.
Sure, if you implement the general codec-agnostic case where buffer 
size is derived solely from a sampling of timestamps, then you can't be 
absolutely sure without scanning the whole file. But H.264 isn't the 
general case, it's only more general than any other codec so far.

--Loren Merritt