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

[D Richard Felker III]

On Thu, Apr 22, 2004 at 07:47:39PM +0200, Michael Niedermayer wrote:
> > > > 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 ...

IMO it's not. The coding of size bits should never vary. Otherwise it
makes error recovery difficult. For example if we lost the packet
where a different timestamp delta appeared, we might think we only
have one timestamp delta, but instead we have two. Thus size would be
decoded wrong, and we'd lose sync. One of the major goals in my system
was to make sure that size is always coded independently of other
packets.

Rich