[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