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

[D Richard Felker III]

On Wed, Oct 06, 2004 at 01:58:25PM +0200, Michael Niedermayer wrote:
> > > 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

yes, i thought of this after sending. it's not quite as bad as you
say: for example, if we have the following sequence (same timebase on
both streams to make it simple but it works with different timebases
too):

packet 0: stream 0, any pts
packet 1: stream 1, any pts
packet 2: stream 1, pts += 2
packet 3: stream 0, pts += 1

regardless of the initial timestamps, this is wrong. (let's assume for
now decode_delay==0.. :) there are many other combinations in which it
can occur too.

> > - 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

ok unless anyone else has a major complaint or sees something i
overlooked, i'm pretty much satisfied with your results. you've made
good arguments why the limited case you cover with the test code is
actually the general case.

btw like i said before, i agree with basically all your changes except
the keyframe startcode stuff. is there a good reason we can't discuss
all these changes and reach a common ground instead of forking?

rich