[NUT-devel] rfc drafting

[Rich Felker]

On Sat, Nov 17, 2007 at 04:55:00PM +0100, Michael Niedermayer wrote:
> > what about normal b frames?
> > IPBBIBBBBBPPP
> > 
> > here if we start decoding from the 2nd I frame none of the B frames
> > can be decoded as they need the pevious frames but they are after the
> > I frame position wise

Yes, sorry, I left out the PTS part... :( I can fix it.

> heres a different definition for keyframes, note this is not identical to
> what is in nut.txt
> 
> A frame in a stream is a keyframe if and only if all of the following are true
> * Decoding can successfully begin using any standard compliant decoder without
>   requireing access to prior frames.
> * Begining decoding instead at a subsequent frame would cause fewer frames
>   to be decoded successfully.

I'm confused what this second condition is supposed to mean. Of course
if you start at a subsequent frame (e.g. the n+1 frame instead of the
nth frame) you'll decode fewer frames, provided that you were able to
successfully decode the nth frame to begin with. But maybe this
characterization is what you're trying to get at:

"A frame N is a keyframe if the set of frames which can be
successfully decoded by starting with frame N is a strict superset of
the set of frames which can be successfully decoded by starting with
frame N+1."

with "successful" having the meaning you described (perhaps adjusted
to be more formal). I have replaced your idea of "more/fewer" with
"strict superset/subset" to conform to the fact that the number of
frames in stream need not be practically finite.

Note however that your definition here (and my version of it) have the
(perhaps unfortunate) effect that all frames would be keyframes in a
hypothetical codec where the (N%total_blocks)th block is intra-coded
in the Nth frame and all other blocks in the Nth frame are
residue-coded. This may be better than having no keyframes at all, but
it seems sort of perverse nonetheless.

Rich