[MPlayer-dev-eng] Nut startcodes

[D Richard Felker III]

On Tue, Apr 27, 2004 at 12:12:28AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Monday 26 April 2004 12:20, D Richard Felker III wrote:
> > Michael proposed (in "Cleaning your nuts" thread :) adding "type 1"
> > frames back into nut with 3-byte startcodes to improve error recovery.
> > What's everyone's opinion on this?
> >
> > BTW, the spec right now is rather confusing regarding type 2 frames. I
> > have a proposed simplification. Get rid of frame "types" entirely and
> > just have frames and startcodes be two separate things. An 8-byte
> > startcode just serves as a sync point, and frames after the startcode
> > are forbidden from using any predictive coding that depends on frames
> > before the startcode. As a consequence, the first frame of each stream
> > after the startcode must fully encode its pts. In effect it's the same
> > thing as type 2 frames, but conceptually, it's nicer to separate the
> > startcode from the frame so that it doesn't belong to any particular
> > stream, but rather the file.
> agree

:)

> > In this light, there's only one type of frame, and two types of
> > startcodes (not counting global/stream header, info, etc. startcodes):
> >
> > 1. Small (3-byte?) startcode. This one imposes no rules on the
> >    surrounding frames, and serves ONLY as an aid to error recovery. It
> >    can be used as frequently or infrequently as desired for the
> >    error-recovery needs of the user.
> agree, but there are 2 things which may need disscussion

Agree.

> 1. length? this depends upon what demuxer complexity we assume, for example, 
> if we assume that the demuxer follows all possible pointer chains as u 
> suggested then 2 or even 1 bytes could be interresting, but if a demuxer just 
> seraches for the next startcode and blindly starts decoding from there 3 is 
> probably the minimum

IMO 1 byte isn't very useful, even with the pointer chain walking. At
each step you have a 1/256 chance of hitting the value, and after
several steps that becomes a pretty good chance. I suppose 2 bytes
might be ok. Would the first byte still be 'N'? IMO it needs to be.

As for assuming demuxer complexity, I think we should design nut
around the _maximum_ recovery that an advanced demuxer could do
(without codec-specific hacks, etc.). It's ok for some demuxers to be
less advanced, but then they won't be able to play super-corrupt
files. In my mind, a corrupt file is _invalid_ (in violation of the
spec) and playing it is an added feature, not a necessary requirement.

With that said, as long as there are fairly many type1 startcodes, I
think a demuxer could do quite well without the brute-force pointer
chain walking algorithm, even with just 2-byte startcodes. If the
player can signal the demuxer when a codec returns an error, the muxer
can look for the next startcode, assuming the one it found was
invalid. (Keep in mind: by error I mean totally non-parsable frame,
not just some corruption in it.)

> 2. what value should the startcode get? first byte has to be 'N', should the 
> following be stored in the main header? an advantage may be that a smart 
> muxer could choose a code which occures less often in the streams, i suspect 
> that some bit sequences may be quite rare, especally in formats which try to 
> avoid some sequences

If we're going to make it customizable (and IMO we should), then why
not allow custom length too? Either 2 or 3. Or longer...?

Rich