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

[Michael Niedermayer]

On Wed, Jul 23, 2008 at 04:30:18PM -0400, Jeff Downs wrote:
> 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.

The limit is the same, sps->ref_frame_count, besides the reference bitstreams
with it decode correctly thus i would assume it is doing the sliding window
operation correctly, and that rather the code is duplicated in 
decode_ref_pic_marking().
If true, this duplicated code should maybe be removed.


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

I do not think the code can assume poc values to be or not to be of specific
values. So independant of the poc values being correct the crashing code
might be buggy.

Please upload the sample, and help fixing it is welcome as well of course.

Besides this i have fixed some misdetected frame num gaps, that of course
doesnt mean that the assert() above shouldnt be looked into even if its not
occuring anymore.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080724/9038d67d/attachment.pgp>