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

[Michael Niedermayer]

Hi

On Friday 23 April 2004 16:53, D Richard Felker III wrote:
> 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.
iam slightly in favor of add/sub 'N' but its a very minor thing IMHO

>
> > > 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.
i havnt thought about this possibility, so i agree to drop size predictors
btw, i would expect that there will be several matching packet chains, so the 
demuxer would have to select one, maybe the longest would be a simple choice

>
> 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...
200 codes with{
    keyframe=1
    stream_id=0
    pts= 00 (least recent used delta pts)
    size_mul=200
    data_size_coded 0
    data_size_lsb= code (0..199)
}
16 codes with{
   keyframe 0-1
   stream_id=0
   pts 00-11
   size_mul=1
   data_size coded=1
   data_size_lsb= 0
}

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