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

[Michael Niedermayer]

Hi

On Wednesday 06 October 2004 07:53, D Richard Felker III wrote:
> On Wed, Oct 06, 2004 at 05:04:12AM +0200, Michael Niedermayer wrote:
> > > > 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
>
> if it's true i'll be happy to accept that and adopt a better solution.
> but i'm very skeptical of your tests. the attached program doesn't
> seem to be measuring the relevant thing whatsoever. my complaints:
>
> - it has no framecodes whatsoever, just vlc forward pointers.

the simple variant choosen is pracatically a valid framecode table (we may 
need to exclude 'N' as first byte then it should be completely valid, but 
that wont change the result)
the number of possible framecode tables is very large so we cannot test all


> - it does not check to see if it jumps over a startcode.

it does, the end of the block is the NEXT startcode so there is none before 


> - it does not check to see if the final step lands exactly on a
>   startcode, just if it lands on the exact size.

as already said, the end of the block is the next startcode so checking only 
if it hits the end is equivalent to checking against all startcodes


> - with a real stream we have a lot more things we can check to see if
>   the candidate chain makes sense, like interleaving. a false chain
>   will have the streams appearing in rather random order, so it's at
>   least somewhat unlikely for the pts interleaving to match.

yes, but if we resync after an error, which is the purpose of all this we dont 
have a valid last timestamp or the past pts values to calculate the dts 
values which are monotone, so the interleaving check while possible will need 
a full or lsb timestamp in at least 2 streams before it could detect an 
inconsistency, now such timestamps arent common as they are a waste to space 
normally


> - with real framecodes (especially with low bitrates where startcodes
>   won't be super-frequent) many of the framecodes will have a fixed
>   data_size_lsb and not set data_size_msb_coded. thus it will be very
>   unlikely to actually get a data size that's way too large and jumps
>   all the way too or beyond the next startcode in just one or two
>   steps.

well the simple framecode used, uses 128 of the 256 values with 
data_size_msb_coded set and 128 with it unset, IMHO thats pretty good 
approximation for low bitrate

u could also interpret the used framecode table as 256 streams and 
data_size_msb_coded always set or 128 stream 1 keyframe flag and 
data_size_msb_coded always set, or 64 streams 1 keyframe flag, 1 timestamp 
flag, or ... ; in either case the we will have the absolutely same result


[...]
-- 
Michael

"I do not agree with what you have to say, but I'll defend to the death your
right to say it." -- Voltaire