[gst-devel] fractions and aspect ratios
Thomas Vander Stichele
thomas at apestaart.org
Wed Jul 14 04:17:01 CEST 2004
> > 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.
Agreed :) But I would make it impossible for string ranges to exist at
this point, since I don't yet see a real use case where they would be
useful. All I'm promoting is that if we would want to have more than
two types of ranges, it would make a lot more sense to have a general
range type, which then gets restricted on what types the members could
> 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.
Agreed, with the exception that if there is an increment, it would be
"the set of values, limited to the ones that satisfy the increment".
> 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).
Agreed when no increment; when there is an increment, basically it's
intersection of a finite set.
> 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.
I don't think we need to - a range with increment implicitly defines a
list. So the same mathematical concepts apply. The only problem is
having two ranges with different increments resulting possibly in a set
with no one increment, because it takes values from both. In that case,
we could chose to either refuse the intersection/subtraction, or convert
to a list. Not sure (since I don't understand all of gstvalue.c yet) if
that would be a viable approach.
> 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.
That's one possible solution. But like I said, I can't reason about it
without a real use case.
> > 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
Yes, and I'm proposing to maintain that code because I think it is
> 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.
Agreed 100%. I've added a few already and feel free to suggest more
places to do this. I was also thinking of making a general gstvalue set
of testsuite cases too, outside of the caps. That testsuite dir is
currently cluttered and ambiguous.
> And I'll ask a lot of questions about semantics, too (like the
> string question above).
Scares me slightly more, but I'll try and tackle, because it should be
> The caps system only rocks so much because there
> are no ambiguities and I'd like it to stay that way.
Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
- There it is. Ten thousand dollars. You're not gonna count it?
- You trust me?
- No. But I do kill people.
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/
More information about the gstreamer-devel