[gst-devel] fractions

[David Schleef]

On Thu, Jul 15, 2004 at 02:23:31AM +0200, Thomas Vander Stichele wrote:
> Nice skid around the previous example for framerate :)  I must admit it
> threw me off as well when I checked what the original fraction was.

Actually, I was just not being petty by pointing out that the
different in rate turns out to be 1 frame per millenia.

> Not sure how you would want to implement that, and not sure it's a good
> thing to do right now.  Maybe it makes sense for a 0.9 project, but it
> seems to invasive for this series, and I don't yet see the gain in it. 

Funny, I'm saying the same thing about fractions.

> But it sounds to me like this means you have agreed on having a
> "fraction" concept in GStreamer ?

One of the drafts of the new caps system had fractions.  I dropped
it because there wasn't a need at the time, and I didn't care to
write the extra code.  I'm merely making sure that adding them now
is the right decision.

> - I've given examples that you got wrong for stuff you said could be
> done correctly

Keep in mind that the given framerate is probably a mangled form
of 30000/1001.  There aren't very many interesting non-integer
framerates.

> - Based on the examples, I don't see how we can feed encoders correct
> frame rate fractions without rounding errors

Apparently, based on the 29.969999 framerate, rounding doesn't matter.

> - Every codec project out there seems to think fractions are the right
> way to handle both aspect ratio and framerate - what makes you think all
> of them conbined are wrong ?

My speculation would be that pairs of integers are easier to handle
on CPUs that don't have floating point units.  Since the oldest video
formats predate FPUs being common and newer video formats generally
just copy old ones, it stuck.  MPEG uses a timebase of 1/90000 s,
and we obviously didn't use that for our timebase.

> I don't think I need to produce any more factual evidence for the
> usefulness of GstFraction than I already have.

I'm calling into question your "factual evidence".  You claim that
floating point numbers are somehow grossly inaccurate and incapable
of expressing fractions.  This is patently not true.  The set of
fractions useful for our purposes (say, denominators less than 1e6)
are many orders of magnitude less dense on the range [0,1] as are
unique double-precision floating point numbers.  For that set of
fractions, there is an exact 1-1 mapping to doubles.

I'm also concerned with what I percieve as roadmapping by feature.
That is, 1) find a problem, 2) add something to the core to fix
the problem.  I don't think of this as being 100% bad, but I
would prefer to have the steps 2) think of similar problems,
3) decide on a long range direction, and 4) pick a solution that
solves the current problem but also makes it easy to transition
later.

Clearly, it would be nice to have something that expresses
fractions exactly in the same way that we express integers exactly.
IMO, in the long term, it's best to get rid of the distinction
between integers, fractions, and doubles.  It would also be useful
to have the concept of infinity, open ranges, etc.  At some point,
somebody (probably me) will have to make sense of the current
jumble, create a transition plan, write some code, and pull us
out of the mess.  Personally, I would prefer that you use doubles,
since it's fewer things to fix later.

I'm a little annoyed that you were so quick to belittle what I
considered to be constructive criticism -- especially the use
cases I proposed that don't fit your model well.  I throw out
random usages ideas, because many times it reminds someone of
an actual use case that doesn't work well.  IMO, this is an
important part of vetting code -- throw eggs at it and see what
sticks.  Your attempts at trying to get around this kind of
discussion (in my impression) makes me more likely to jump on
major changes that you propose in the future.  That's going to
make me look obstructionist, but oh well.  Ideas are easier to
discuss than code is to fix.

And I fully apologize for not making any criticisms known until
recently.



dave...