[NUT-devel] rfc drafting

[Michael Niedermayer]

Hi

On Sun, Nov 18, 2007 at 01:32:18AM -0500, Rich Felker wrote:
> 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.

that was the reason why i wrote it like that :)
such streams exist and it even makes sense for them to exist ...
just think of realtime communication over a low bandwidth channel
(portable phones or something like that would be an example)
i frames are many times bigger than p frames at the same quality
so having p frames with lets say 10% intra coded blocks leads to
lower delay than i frame would. and i frames at lower quality would lead
to unacceptable flickering every time a low quality blocky I frame would
be received
so yes, i think all frames should be key frames in that case ...
also the encoder can optimize the decission of which blocks to code as
intra ...

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/nut-devel/attachments/20071118/bea50f53/attachment.pgp>