[MPlayer-dev-eng] Nut & framecode...

[D Richard Felker III]

On Fri, Apr 23, 2004 at 04:21:59PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Friday 23 April 2004 08:09, D Richard Felker III wrote:
> > I think Michael's convinced me that framecode is a good thing, for
> > extensibility reasons. For now it can be used like my bitfields, and
> > more specialized muxers could choose an optimal framecode table if
> > they like. But I'd like to propose some minor changes and suggest a
> > sane default framecode table that muxers could use. First, the
> > changes:
> >
> > 1. XOR framecode byte with 'N' or 'N'^0xff.
> >
> > Right now 'N' is the forbidden framecode, and that makes things
> > particularly annoying for muxers that want to use the framecode as a
> > sort of bitfield. You might say the muxer could just do the XOR
> > itself, but then it has to write the framecode table in the global
> > header this way, and Michael's compression tricks for it no longer
> > work because it's shuffled out of order.
> >
> > If XOR is made part of the spec, then 0x00 or 0xff becomes the
> > forbidden framecode, and nothing special is needed to exclude it.
> > (Just have a table of 255 framecodes instead of 256).
> ok

Do you think this is good? I wasn't sure. Later I had the idea of just
adding/subtracting 'N' which would keep things in order, so it doesn't
matter.

> > 2. Remove predictive coding for data_size.
> >
> > It's bad for error recovery and unlikely to help except for CBR which
> > wastes 30% or more space anyway.
> can u explain why its bad for error recovery? when we loose one header we 
> cannot recover before the next type >0 frame and that resets the predictors 
> so it just uses the values in the stream header not the size of past packets

No. If we lose sync, we walk all bytes up to max distance between type
2 frames, and try each one as a packet starting point. We then walk
along using the packet lengths. If we hit the next startcode without
missing any startcodes, then we recovered. Then we can go back and
play from the successful recovery point.

With predictors, this becomes much more difficult. Anyway like I said,
the predictor is not useful for VBR. And for CBR, if a muxer wants to
be really efficient it can just put the two possible packet sizes in
the framecode table...

> > 4. Perhaps replace all timestamp_lsb stuff with timestamp_delta.
> i would rather combine the lsb and full timestamp
> btw, lsb timestamp coding is used in allmost all video standards 
> (mpeg1,mpeg2,mpeg4,h263,h264)

I suppose that's ok. But the special pts codes (delta1, delta2,
delta3) are delta based, so I just thought it was more confusing to
mix that with lsb/msb stuff.

> for a single audio stream with packets <200byte single byte headers _are_ 
> possible even if the stream is VBR

Could you explain how? I don't see how you fit pts and packet size
both in one byte...

Rich