[MPlayer-dev-eng] Nut proposal [Re: Cleaning your nuts]

[Michael Niedermayer]

Hi

On Thursday 22 April 2004 19:39, D Richard Felker III wrote:
> On Thu, Apr 22, 2004 at 07:12:32PM +0200, Michael Niedermayer wrote:
> > Hi
> >
> > On Thursday 22 April 2004 18:39, D Richard Felker III wrote:
> > [...]
> >
> > > > IMHO instead of this +1/-1/0 mess a simple n bits for stream id and
> > > > 5-n for size_lsb with n stored in the main header seems to be a
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
> OK, so n is selectible in the global header? I thought n was defined
> implicitly by the number of streams.
see above :)

>
> > > The problem is audio. PTS can increment by different values depending
> > > on the size (in samples) of the frame. Think vorbis. That's why we
> > > need 3 predictors. But it matters for video too. With mixed 24/30 fps
> > > [inverse telecined] video, you'll have +4 and +5 timestamps (in
> > > 120000/1001 timebase).
> >
> > i think u missunderstood me, the idea was to make the number of bits
> > variable depending upon the past
> > first packet of a stream after type 2 frame: 0 bits, must be full
> > timestamp second packet: 1 bit, full vs last delta
> > following packets: 1 or 2 bits depending upon the number of different
> > delta pts in the past
>
> Hmm, interesting idea. So until they're needed for pts, do the extra
> bits get used for size_lsb?
yes, that was the idea, but i dont know if its worth it ...

[...]
-- 
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