[FFmpeg-cvslog] r14339 - trunk/libavcodec/h264.c
Sun Jul 27 16:16:28 CEST 2008
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-cvslog