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

[Michael Niedermayer]

Hi

On Friday 23 April 2004 18:09, D Richard Felker III wrote:
> On Fri, Apr 23, 2004 at 05:28:48PM +0200, Michael Niedermayer wrote:
> > > > > 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
>
> Several matching chains that land exactly on the next startcode?? 
yes

> IMO 
> this is very unlikely! Keep in mind: any chain that skips over a
> startcode can immediately be thrown out. Also any chain that exceeds
> max distance between startcodes can be thrown out.
yes, still i think we will find false chains, u must also keep in mind that 
the wrong chain doesnt need to independently hit the startcode, just any 
packet of the correct chain before the startcode

>
> > > > 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
> > }
> >
> :)))))
>
> Does this work well for vorbis? 
it should, but i didnt try

> I'm not aware of the relative 
> frequency of 128/1024 sample frames, but if the 128-sample ones are
> rare it should be good!
in a 64kbit/sec test sample there where
 7913 1024sample frames
 6286  128sample frames
 1771  576sample frames

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