[MPlayer-dev-eng] Nut startcodes

[D Richard Felker III]

On Tue, Apr 27, 2004 at 03:45:47PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Tuesday 27 April 2004 02:27, D Richard Felker III wrote:
> > On Tue, Apr 27, 2004 at 12:12:28AM +0200, Michael Niedermayer wrote:
> [...]
> > > 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...?
> hmm isnt this against the idea of simplicity? what do we gain with variable 
> length? we would have files with 2 byte startcodes and some with 3 bytes ...

Hmm, maybe. My idea was that the user should get to make the tradeoffs
between efficiency and error recovery, since it _is_ a tradeoff. So
people doing streaming could use small (or none!) type1 startcodes
while people storing high-quality archival material might want large
ones before every frame. In most places, variable length doesn't hurt
simplicity; however, you're right here. It does require the demuxer to
implement two (or more?) different searches, one for each length. So
I'm not sure if it's a good idea or not.

Maybe if we don't want to allow custom size, the question should be:
does it help more to have a 3byte startcode every 9 frames, or a 2byte
startcode every 6 frames? (i.e. if you hold overhead fixed, which
gives better error recovery)

Rich