[MPlayer-dev-eng] Cleaning your nuts

[D Richard Felker III]

On Thu, Apr 22, 2004 at 07:00:22PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Thursday 22 April 2004 18:22, D Richard Felker III wrote:
> > On Thu, Apr 22, 2004 at 05:32:06PM +0200, Michael Niedermayer wrote:
> [...]
> > > lsb timestamps should be enough for these packets too, so i guess the
> > > type 1 headers would be 50-70% smaller then type 2
> >
> > BTW we should address the msb/lsb/relative timestamp issue. My
> > proposal has been to get rid of msb/lsb thing and just use relative
> > timestamps for type0 (and type1?) frames if possible. But maybe the
> > lsb thing is more robust in the presence of errors. IMO relative is
> > much more compact, especially with the 3 delta predictors.
> yes, its also unfortunate that fulltimestamp, lsb + 3delta = 5 which doesnt 
> fit in 2 bit, maybe be could use AC coding for the header, no iam not joking
> for example 3 cases of size_lsb (size= 3*size_msb + size_lsb) with 5 timestamp 
> cases would fit in 4bit
> encoding: timestamp + 5*size_lsb
> decoding: with %5 and /5

Follow my proposal. PTS code in the flags byte is 2 bits
 00=vlc follows
 01=delta1
 10=delta2
 11=delta3
Then, in the vlc-coded PTS, use the low bit to flag whether it's
absolute or lsb/relative (whichever we decide to use). IMO this better
because we avoid wasting space in the flags byte, and the absolute/lsb
flag is only coded in the case where the frame is already large.

> > > > 2. Get rid of framecode and replace it with something non-obfuscated.
> > > > [...]
> > > > Rationale: Meets the simplicity goal and perhaps improves error
> > > > recovery.
> > >
> > > simlicity, yes,
> > > error recovery IMHO no, its easily possible to require 50% of the
> > > framecodes to be invalid to detect errors
> >
> > Then you only have a 50% chance of catching an error, and you added
> > lots of overhead. Bad tradeoff.
> its a fundamental problem, length >= log(legal_count + illegal_count)
> overhead= 1bit here btw

Losing that bit greatly increases the probability of having to use an
entire extra BYTE for coding other data. Thus major overhead.

Rich