[Mplayer-cvslog] CVS: main/DOCS/tech mpcf.txt,1.56,1.57

Michael Niedermayer michaelni at gmx.at
Sat May 1 22:49:18 CEST 2004


Hi

On Saturday 01 May 2004 21:42, D Richard Felker III wrote:
> On Sat, May 01, 2004 at 08:48:44PM +0200, Michael Niedermayer CVS wrote:
> > CVS change done by Michael Niedermayer CVS
> >
> > Update of /cvsroot/mplayer/main/DOCS/tech
> > In directory mail:/var2/tmp/cvs-serv7659
> >
> > Modified Files:
> > 	mpcf.txt
> > Log Message:
> > limits too small, my CBR mp3 samples have 2x overhead after removial of
> > size prediction
> >
> >
> > Index: mpcf.txt
> > ===================================================================
> > RCS file: /cvsroot/mplayer/main/DOCS/tech/mpcf.txt,v
> > retrieving revision 1.56
> > retrieving revision 1.57
> > diff -u -r1.56 -r1.57
> > --- mpcf.txt	1 May 2004 11:28:34 -0000	1.56
> > +++ mpcf.txt	1 May 2004 18:48:42 -0000	1.57
> > @@ -367,10 +367,10 @@
> >  	if its 0 then the stream_id is coded in the frame
> >
> >  data_size_mul[frame_code]
> > -	must be <250
> > +	must be <16384
> >
> >  data_size_lsb[frame_code]
> > -	must be <250
> > +	must be <16384
>
> Is there any reason for a limit at all?
frame_code table size, should a demuxer use uint8_t, 16 or 32? 
and main header size, without this the main header could be arbitrary big, its 
nice to know that the header will never be larger then x

but iam not sure, maybe the limits arent a good idea ...

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




More information about the MPlayer-cvslog mailing list