[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