[MPlayer-dev-eng] a few nut suggestions [short startcodes]

[D Richard Felker III]

On Wed, Oct 06, 2004 at 12:01:58AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Tuesday 05 October 2004 04:43, D Richard Felker III wrote:
> > On Tue, Oct 05, 2004 at 03:30:51AM +0200, Michael Niedermayer wrote:
> > > Hi
> > >
> > > On Tuesday 05 October 2004 02:58, D Richard Felker III wrote:
> > > > On Tue, Oct 05, 2004 at 01:55:19AM +0200, Michael Niedermayer wrote:
> > >
> > > [...]
> > >
> > > > > the short startcodes while cute serve no purpose at all
> > > >
> > > > i disagree. they allow you to have a reasonable degree of error
> > > > resilience without putting tons of syncpoints (which cause massive
> > > > overhead).
> > >
> > > u can have the same by adding a few fixed bits into the framecode or
> > > adding some fixed bytes afterwards, it doesnt require any change to the
> > > spec or (de)muxers
> >
> > adding fixed bits to framecode will double the overhead for
> > low-bitrate files, and won't provide much error resilience at all.
> > you're basically guaranteed to find many many bytes that have those
> > few fixed bits set....
> 
> could u elaborate why fixed bits in the framecode / after it suck while bits 
> in the startcode before it dont? its obviously identical
> 
> actually the method without short startcodes is more flexible, for example the 
> current 3 byte short startcode needs to have a 'N' as first byte to avoid 
> frame-code emulation, so there are 2^16 possible choices
> if instead we add a fixed 3 byte type v value afterwards we have 2^21 choices
> 
> the optional value afterwards could also be the size of the last frame instead 
> of a fixed value

your change adds huge overhead. the whole point of the short startcode
is that you don't put it on each frame, you just put it every 8k or
so. when you said "a few bits" my idea was that you would put one or
two fixed bits into each framecode so that the level of overhead would
be comparable to these startcodes. this would help slightly in
detecting errors, but obviously one or two bits in the framecode are
impossible to resync to after we've lost sync from an error. 3 bytes
are rather easy to sync to, so even if you can't resync on the very
next frame you can resync soon and then use the brute force resync to
find valid packets you missed in between.


rich