[MPlayer-dev-eng] enhancement for yuv4mpeg output driver

[D Richard Felker III]

On Thu, Jan 20, 2005 at 07:03:51AM -0800, Trent Piepho wrote:
> On Thu, 20 Jan 2005, D Richard Felker III wrote:
> > > Into the email message, yes.  Mplayer only prints the fps value to three
> > > places when you play a file, so I only copied it down to three places.  I
> > > didn't think anyone would feel 10 decimal places were necessary for an example
> > > in an email message.....
> > 
> > But the whole precision is there in MPlayer's fps variable, and will
> > get passed to av_reduce if you use it right.
> 
> What do you mean by "whole precision"?  If you mean enough precision to turn

i mean the maximum precision available in the floating point type
used. (which is a whole damn lot more than 3 decimal places...)

> any fraction that was converted to a floating point number back into a
> fraction, that is theoretically impossible.

of course. but if you know a bound on the denominator, and the bound
is small enough, it IS possible to losslessly reverse the conversion
to float.

> > > Secondly, even if I specify -fps 30000/1001, av_reduce() reduces it to
> > > 10999/367!  My float->fraction code gets it right.
> > 
> > But only for special cases... BTW if this is true and av_reduce is
> > that broken, it needs to be fixed.
> 
> It is not possible take a fraction, turn it into a 32-bit floating point
> number, and then turn it back into a fraction equal to the original in all
> cases.  For any floating point value you pick, there are an infinite number of
> fractions from which it could have come.  There is no way to figure out which

false. there are no infinities in a finite state machine. there are
actually at most 2^64 possible fractions, and actually fewer than 2^32
within sane ranges. (approx 16-20 bits for numerator and 12 bits for
denominator, with the sort of numbers we're looking at...)

> of these it came from.  Therefor, any routine you may come up with will only
> work for special cases.
> 
> I came up with a simple routine for converting floats to fractions that works
> correctly for any frame rate you are ever likely to see.  The routine in lavc

your code is idiotic. it will produce wrong results for avi files with
broken near-ntsc framerates in their headers.

> does not even work for all 18 of the ATSC standard formats, much less typical
> avi files, while being more complex.  Why do you want me to cut and paste the
> code from lavc into vo_yuv4mpeg?
> 
> If you want to replace what's in lavc with my code, that's really a different
> issue than getting the yuv4mpeg output driver to create a working header.

rotfl!! no thanks. lavc's code already works perfectly.

rich