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

[Michael Niedermayer]

On Sat, Jul 26, 2008 at 05:22:54PM -0400, Jeff Downs wrote:
> On Thu, 24 Jul 2008, Michael Niedermayer wrote:
> 
> > 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.
> 
> Indeed. Take a look at attached.  Removes MMCO synthesis for sliding 
> window and lets it be handled at the end of mmco execution. 
> The error message for too many reference frames is lost, though;  there's 
> no way to tell if it is sliding window or bad MMCO that put us over the 
> limit without some additional book-keeping. 

> If you think the error is valuable enough, I can add a var to the context 
> to track that.

I think it is valuable.
What about a MMCO_SLIDING_WINDOW that is placed in the array, that would
be rather clean and easy to check for i think (unless i miss something)

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/20080727/b8d9ffcf/attachment.pgp>