[MPlayer-dev-eng] a few nut suggestions [short startcodes]
Michael Niedermayer
michaelni at gmx.at
Wed Oct 6 00:01:58 CEST 2004
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
[...]
--
Michael
"I do not agree with what you have to say, but I'll defend to the death your
right to say it." -- Voltaire
More information about the MPlayer-dev-eng
mailing list