[gst-devel] fractions and aspect ratios

[Benjamin Otte]

On Wed, 14 Jul 2004, Thomas Vander Stichele wrote:

> > I don't think you want an increment in it. Just for one rerason: It's not
> > worth it. A well-behaving type for caps implements the operations
> > intersect and subtract. Since you want a universal range type for every
> > fixed GValue type (this includes strings), you will have to make
> > subtractions and intersections work for stuff like this: (string) [
> > "hello", "world, "!" ]
>
> In my mind there is no point in having string ranges.  What would your
> example represent ? What does the range from "hello" to "world"
> represent even without the increment ?
>
Uh, it wasn't my idea to invent a general range type. ;)
I just wanted to make you people aware of what that would mean.
The general list type was only used, because we had a clear definition of
what it would mean.

FWIW, I thought a general range type would behave like this:
given two GValues min and max, the set of values represented by the range
would be all GValues x for which gst_value_compare (x, min) returns
GST_VALUE_EQUAL or GST_VALUE_GREATER_THAN and gst_value_compare (x, max)
returns GST_VALUE_EQUAL or GST_VALUE_LESS_THAN.
This could be made to work with intersections like this:
The intersection between two ranges [min1, max1] and [min2, max2] would be
defined as [min3 = MAX(min1, min2), max3 = MIN (max1, max2)], special
casing the cases max3 < min3 (empty intersection) and min3 == max3 (just
a simple return value, no range).
Subtractions are a little harder, because we don't have open ranges, but
as I said we're cheating there anyway, so it might be made to work.

All of this is a lot harder for increments, because we have no concept of
a distance between two values in our current GValue code.

If I went with this definition and current GstValue string comparisons,
the range ["hello", "world"] would be defined as all strings that are >=
"hello" and <= "world" according to strcmp.

> There are 63 possible values for the fps index.  What I'm saying is that
> something like [ 15/16, 90/16, 15/16 ] is a hell of a lot more
> understandable than having ( 0.9375, 1.875, ... (numbers snipped because
> I can't be bothered to calculate them right now, which goes to prove my
> point) )
>
I know that it looks nicer to be able to write it like this, but it also
means we need to support more code. Intersections and subtractions are
mandatory.

FWIW, I don't care wether we use fractions or floats, general ranges or
special ranges, ranges with or without increments, I'll leave that up
to the rest of you to decide. But if you invent something new, I'll make
sure to write a lot of tests for it and have whoever invented them fix all
of those. And I'll ask a lot of questions about semantics, too (like the
string question above). The caps system only rocks so much because there
are no ambiguities and I'd like it to stay that way.


Benjamin