[MPlayer-DOCS] CVS: main/DOCS/tech mpcf.txt,1.49,1.50

[D Richard Felker III]

On Thu, Apr 22, 2004 at 01:04:29AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Wednesday 21 April 2004 20:43, Richard Felker CVS wrote:
> > CVS change done by Richard Felker CVS
> >
> > Update of /cvsroot/mplayer/main/DOCS/tech
> > In directory mail:/var2/tmp/cvs-serv32395/DOCS/tech
> >
> > Modified Files:
> > 	mpcf.txt
> > Log Message:
> > remove bad requirement
> >
> > Index: mpcf.txt
> > ===================================================================
> > RCS file: /cvsroot/mplayer/main/DOCS/tech/mpcf.txt,v
> > retrieving revision 1.49
> > retrieving revision 1.50
> > diff -u -r1.49 -r1.50
> > --- mpcf.txt	20 Apr 2004 23:00:28 -0000	1.49
> > +++ mpcf.txt	21 Apr 2004 18:43:01 -0000	1.50
> > @@ -281,7 +281,6 @@
> >  	if the fixed_fps is 1
> >  	time_base_denom MUST not be 0
> >  	time_base_nom and time_base_denom MUST be relative prime
> > -	time_base_nom MUST be < 2^16
> i agree, but there should be some limit, or otherwise we will have to deal 
> with 64bit time_base_nom which is _very_ difficult to work with as it 
> requires 128bit intermediates for every operation unless we just convert it 
> to float ...

Well you could say < 2^32 I guess... :) Even 2^24 would be ok. 2^16
just isn't an acceptable limit because 120000/1001 is needed for NTSC
mixed content.

> how could 64bit time_base_nom be created? easy:
> den= UINT32_MAX;
> nom= (uint64_t)(float_fps/den + 0.5);
> 
> while this is inaccurate and ugly, its probably quite similar to how many 
> developers would implement it IMHO
> 
> so IMHO we need a limit for all fractions or we can add some recommandition 
> about which arbitrary precision lib should be used to demux nut ;)

IMO the standard should strongly recommend against using 'fixed point'
hacks like this and recommend using the correct rational timebase of
the source. Perhaps mentioning the overhead waste for doing idiotic
things like this would be a good reminder to people...

Rich