[NUT-devel] rfc drafting

[Michael Niedermayer]

On Tue, Nov 20, 2007 at 09:05:01AM +0100, Clemens Ladisch wrote:
> Michael Niedermayer wrote:
> > On Mon, Nov 19, 2007 at 04:27:43PM +0100, Clemens Ladisch wrote:
> > > Michael Niedermayer wrote:
> > > > ...
> > > > and if you dont set them as keyframes you cant seek or how should the
> > > > demuxer know it should ignore keyframe flags for a specific file?
> > > 
> > > It appears the exact definition of "keyframe" or "successful decoding"
> > > is codec- and application-specific.
> > > 
> > > Since the only thing the nut format does with keyframes is to optimize
> > > seeking to them, and since it does _not_ specify how codecs or
> > > applications should behave when decoding, I think it would be good idea
> > > if the definition doesn't rely on the meaning of "successful decoding".
> > > 
> > > In other words, a muxer uses a keyframe when it wants a demuxer to be
> > > able to seek to it, but the determination of whether a frame can be a
> > > keyframe is left up to the encoder/muxer.
> > 
> > that works as long as the muxer only marks frames as keyframes which can
> > be successfully decoded if it does _anything_ else it will generate
> > files which are broken
> 
> Yes.  My point is that there can be applications with different
> requirements as to what constitutes successful decoding, like in the

and my point is that this is not true


> 10% intra blocks example that I snipped, where a real-time player should
> be able to (re-)start playing everywhere but an editor would not want
> to.

you dont want your editor to be able to edit the file? because that is what
would happen if it cannot start anywhere (= no classic keyframes)

maybe your confussion comes from the assumtation that a decoder would
output incorrectly decoded frames after seeking
at least for h.264 this is not the case, there are packets describing
when the output is correct
we could surely duplicate this information in the frames in nut


> 
> A muxer might want to use differents algorithms for the same data,
> depending on how many frames it wants to appear as keyframes in the
> index and in the syncpoint structure, because those are that actual
> effects that setting a frame's key flag has on a nut file.

nut.txt says
"a muxer MUST mark every frame it knows is a keyframe as such"

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- 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/20071120/8b161bd1/attachment.pgp>