[MPlayer-dev-eng] Cleaning your nuts
Michael Niedermayer
michaelni at gmx.at
Thu Apr 22 19:44:09 CEST 2004
Hi
On Thursday 22 April 2004 19:36, D Richard Felker III wrote:
> 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.
yes, agree
allthough maybe, we could code the vlc differently:
0..max_lsb -> lsb timestamp
max_lsb.. -> full timestamp + max_lsb
this should be more compact then the single lsb bit switch
[...]
--
Michael
level[i]= get_vlc(); i+=get_vlc(); (violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535)
buf[i]= qp - buf[i-1]; (violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en
More information about the MPlayer-dev-eng
mailing list