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

[D Richard Felker III]

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.
- it does not check to see if it jumps over a startcode.
- it does not check to see if the final step lands exactly on a
  startcode, just if it lands on the exact size.
- 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.
- 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.

if you can address these issues (either with good theoretical grounds
why they shouldn't make a difference, or empirical data that takes
them into effect) i'll be happy to consider switching to your method.
but i don't think the current test shows what you claim it does.

rich