[FFmpeg-cvslog] r14339 - trunk/libavcodec/h264.c

[Jeff Downs]

On Wed, 23 Jul 2008, Uoti Urpala wrote:

> On Wed, 2008-07-23 at 04:12 +0200, michael wrote:
> > Author: michael
> > Date: Wed Jul 23 04:12:54 2008
> > New Revision: 14339
> > 
> > Log:
> > Support gaps in the frame num.
> > Fixes at least:
> > MR3_TANDBERG_B.264
> > MR4_TANDBERG_C.264
> > MR5_TANDBERG_C.264
> 
> After this commit I'm getting lots of "number of reference frames
> exceeds max (probably corrupt input), discarding one" messages. Happens
> with every file I tried. Not affected by the latest "typo fix" commit.

I get that too on some files, because they start out with 
frame nums != 0 and max frame num being very large.

The new gaps in frame num code is missing the delete part of the sliding 
window operation for reference picture marking; it calls 
execute_ref_pic_marking directly (sliding window implementation is in 
decode_ref_pic_marking) so no ref frames get unreferenced until the hard 
limit (code w/ error message you cite) is hit.

I have at least one sample that crashes, too, with this new code (with 
NDEBUG it trips:

assert(best_i != INT_MIN);

on or about line 2892.  This is because all synthesized frames have poc == 
0.  I have not had time to see where the error is, though; in the poc 
computation for the missing frames or the use of poc in the ref list 
building.

	-Jeff