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

[Michael Niedermayer]

Hi

On Wednesday 06 October 2004 01:14, D Richard Felker III wrote:
> 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.

ok, heres a simply proof by implementation that u are completely wrong

its a simple program which counts the number of matching frame-code chains in 
random data

size:     2 false chains:  2  0  0  0  0  0  0  0  0  0  0 
size:     4 false chains:  2  0  0  0  0  0  0  0  0  0  0 
size:     8 false chains:  4  0  0  0  0  0  0  0  0  0  0 
size:    16 false chains: 10  0  0  0  0  0  0  0  0  0  0 
size:    32 false chains: 11  1  0  0  0  0  0  0  0  0  0 
size:    64 false chains: 21  5  0  0  0  0  0  0  0  0  0 
size:   128 false chains: 46 10  1  0  0  0  0  0  0  0  0 
size:   256 false chains: 54 25  9  1  0  0  0  0  0  0  0 
size:   512 false chains: 60 23  9  6  4  0  0  0  0  0  0 
size:  1024 false chains: 50 24  9  0  0  0  0  0  0  0  0 
size:  2048 false chains: 50 23 12  6  2  0  0  0  0  0  0 
size:  4096 false chains: 57 37 22 15 11  4  1  1  1  0  0 
size:  8192 false chains: 73 48 22 19 11  3  3  3  2  3  6 
size: 16384 false chains: 64 50 46 30 20 12  8  6  8  8 35 
size: 32768 false chains: 98 67 50 32 27 19  9  5  3  1  0

the size is the amount of random bytes in which chains are searched, the 
numbers afterwards are the counts of false chains of various lengths in 100 
iterations

so if we have 1 syncpoint every 32k then we end up with:
size: 32768 false chains: 98 67 50 32 27 19  9  5  3  1  0
which means we will have 98 wrong length 1 chains in 100 random 32k blocks, 67 
length 2 chains, ...

if we now add short startcodes every 8k we end up with
size:  8192 false chains: 73 48 22 19 11  3  3  3  2  3  6 
which is no doubt better but only slightly


now lets try to add a single check bit to every framecode, we end up with the 
following:
size:     2 false chains:  2  0  0  0  0  0  0  0  0  0  0 
size:     4 false chains:  2  0  0  0  0  0  0  0  0  0  0 
size:     8 false chains:  5  0  0  0  0  0  0  0  0  0  0 
size:    16 false chains: 15  0  0  0  0  0  0  0  0  0  0 
size:    32 false chains: 16  0  0  0  0  0  0  0  0  0  0 
size:    64 false chains: 28  2  0  0  0  0  0  0  0  0  0 
size:   128 false chains: 25  7  0  0  0  0  0  0  0  0  0 
size:   256 false chains: 27  5  1  0  0  0  0  0  0  0  0 
size:   512 false chains: 32  5  3  1  1  0  0  0  0  0  0 
size:  1024 false chains: 29  8  1  0  0  0  0  0  0  0  0 
size:  2048 false chains: 24  7  0  0  0  0  0  0  0  0  0 
size:  4096 false chains: 42 12  3  2  0  0  0  0  0  0  0 
size:  8192 false chains: 35 11  6  3  1  1  1  0  0  0  0 
size: 16384 false chains: 33  8  4  2  0  0  0  0  0  0  0 
size: 32768 false chains: 31  9  3  1  0  0  0  0  0  0  0 

which is much nicer IMHO, as we have practically no long matching chains 
anymore, so if we resync by simply selecting the chain with the largest 
number of frames in it we will almost certainly have the right one except 
that maybe the first 1 or 2 frames in it will rarely be wrong

summary:
32k syncpoints: size: 32768 false chains: 98 67 50 32 27 19  9  5  3  1  0
 8k startcodes: size:  8192 false chains: 73 48 22 19 11  3  3  3  2  3  6 
32k sync / 1bit:size: 32768 false chains: 31  9  3  1  0  0  0  0  0  0  0 

btw, source attached

[...]
-- 
Michael

"I do not agree with what you have to say, but I'll defend to the death your
right to say it." -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resync-framecode.c
Type: text/x-csrc
Size: 1569 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20041006/edeb0d98/attachment.c>