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

[Trent Piepho]

On Fri, 21 Jan 2005, Michael Niedermayer wrote:
> On Friday 21 January 2005 00:27, Trent Piepho wrote:
> > On Fri, 21 Jan 2005, Michael Niedermayer wrote:
> > > i seriously doubt that gcc passes floating point numbers via registers,
> > > instead its passed as a double over the stack
> >
> > Yes, as a double, which isn't a float, which is what mplayer uses.
> >
> > > but it works if u limit it to 30000 ...
> >
> > It doesn't work in all cases, here's one at random:
> > 431/13695 -> 902/28661
> >
> > Why is av_d2q better if it only works in special cases?
> 
> it isnt according to your definition of "works", but that definition means 
> that a output driver should guess the most likely fps value, but that is 
> exactly what is flawed, a output driver should not guess, it should select 
> the closest valid value

Say someone wrote a driver for a hardware MPEG codec.  The only fps values the
codec can use are the 8 standard ones.  The right thing for this driver to do,
is to guess which of the 8 values is most likely the correct one, is it not? 
And say produce an error if none are anywhere close to correct?  Especially
since "the crap design of mplayer" forces the driver to guess in the first
place?

Well this is the yuv4mpeg driver, "4mpeg" as in "for mpeg".  Everyone who uses
it is forced to choose a standard value in the end.  Why is it wrong for
mplayer to do it for them, rather than forcing users to override mplayer's
output manually?  They can always override it if the guess is incorrect, but I
really doubt if anyone will ever need to do this.


> the real bug is the crap design of mplayer which "damages" the fps value, its 
> very possible that the input video really has a non-trivial fps value which 
> is close to a standard one, just think about someone slightly changing the 

Ok, my design will mess up if someone has a value that is within .0005 fps of
a standard value, and they really did want this slightly off value.  In which
case they can override it with the exact, un-damaged by mplayer, value they
want later, as NTSC users always do now.

The av_d2q method does not work for all of the 8 standard MPEG rate codes.  It
also does not work for rates which have a fractional part greater than 30000
or 60000 or whatever arbitrary cutoff you pick.

Now, in practice, which method will do the correct thing more of the time
for more people?