[NUT-devel] rfc drafting

[Clemens Ladisch]

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
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.

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.


Regards,
Clemens