Hi
On Fri, Nov 03, 2006 at 01:37:15PM -0500, Rich Felker wrote:
> On Fri, Nov 03, 2006 at 03:10:59PM +0100, michael
wrote:
> > Author: michael
> > Date: Fri Nov 3 15:10:58 2006
> > New Revision: 20638
> >
> > Modified:
> > trunk/DOCS/tech/nut.txt
> >
> > Log:
> > keyframe definition
> >
> >
> > Modified: trunk/DOCS/tech/nut.txt
> >
============================================================
==================
> > --- trunk/DOCS/tech/nut.txt (original)
> > +++ trunk/DOCS/tech/nut.txt Fri Nov 3 15:10:58
2006
> >  -41,6 +41,13
> > MUST the specific part must be done to conform
to this standard
> > SHOULD it is recommended to be done that way,
but not strictly required
> >
> > +keyframe
> > + a frame which can be decoded correctly on its
own (=without using
> > + information from any other frames)
> > + if no such frames exist in a codec (for
example due to use of overlapped
> > + transforms like the MDCT in an audio codec)
then a keyframe shall be any
> > + frame from which onward all frames can be
decoded correctly
> > + (FIXME maybe move somewhere else?)
>
> This definition is blatently incorrect, e.g. it makes a
B frame with
> only intra blocks a keyframe. In order to be a
keyframe, it must be
> possible to decode all subsequent (in time) frames
without reference
> to any previous (in storage) frames before the
keyframe.
ive fixed it but the new definition is not acceptable,
because strictly
it requires the muxer to know all macroblock types of all
future frames
PPPPPPPI would all be keyframes if they all have only intra
blocks
[...]
--
Michael GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB
In the past you could go to a library and read, borrow or
copy any book
Today you'd get arrested for mere telling someone where the
library is
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|