[gst-devel] fractions and aspect ratios

[Benjamin Otte]

On Tue, 13 Jul 2004, Thomas Vander Stichele wrote:

> - David is convinced that GstFraction is overkill, and floats are
> enough.  My argument is that going to a float loses the information of
> which two integers you came from, making it impossible to figure out
> what the intended target video size was supposed to be since you cannot
> figure out anymore what possible WxH combinations are correct scaled
> values of input WxH (ie, you cannot determine anymore which W-H values
> are integer results of scaling)
>
Why is the information necessary from where you came?
Also, what are other systems/libraries (theora, X, ...) using for pixel
aspect ratios?

> - I also looked at creating a GST_TYPE_RANGE that would be implemented
> with a GArray with three members (lower, upper, increment).  A lot of
> code would be the same as for the LIST type, and we could convert over
> the GST_TYPE_INT_RANGE and GST_TYPE_DOUBLE_RANGE to it.  What do you
> think ?
>
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, "!" ]
Even without increments it's hard enough to make that work generally,
because we still cheat for subtractions of (double) ranges. Subtractions
in the general case would require open ranges, and we don't support those.

> - Having an increment value in RANGE types would also be nice for
> framerate for webcams or width/height for encoders.  For webcams,
> allowed framerates are a multiple of 15/16, and for encoders, typically
> multiples of 8 or 16 only are allowed.  In the case of webcams, being
> able to specify 75/16 instead of 4.6875 seems like a plus to me.
>
A huge list is probably not an option in that case? (I have no clue up to
what framerate is supported, but webcams should have an upper limit of the
framerate they support, and with even 100 values in that list, you'd get
up to 1500/16 = 93.75 fps, which is quite a lot)
Also, does v4l(2) or whatever we use in these cases even allow such exact
querying of capabilities? Because if they don't it's a bit of a moot point
to add that now.


Benjamin