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

D Richard Felker III dalias at aerifal.cx
Fri Apr 23 18:09:45 CEST 2004


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

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

Rich




More information about the MPlayer-dev-eng mailing list