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

[D Richard Felker III]

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 better choice
> >
> > IMO this is bad. Consider a file with just 1 audio and video stream,
> > but 7 subtitle streams. (This is an ideal file! :)
> >
> > You have 9 streams, so 4 bits are needed for streamid. Thus you can
> > only code audio packets up to 255 bytes without wasting an extra
> > header byte. But subtitle packets are VERY INFREQUENT and thus you
> > don't need efficient coding for their headers. It would make a lot
> > more sense to only use 1 bit for streamid (0=vlc-coded, 1=audio) and
> > have 4 bits left for size!
> yes, if 2^n > stream_count then one of them would mean vlc-coded

OK, so n is selectible in the global header? I thought n was defined
implicitly by the number of streams.

> > 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?

Rich