[gst-devel] fractions and aspect ratios
steve at stevebaker.org
Tue Jul 13 16:02:11 CEST 2004
> On Tue, 2004-07-13 at 23:42, Steve Baker wrote:
>> Thomas spoketh:
>> > - 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 ?
>> For GST_TYPE_RANGE to be universally useful there would need to be a
>> which indicates the range as being logarithmic. We would then have to
>> define what the increment means for a logarithmic range.
>> Examples of logarithmic ranges would be frequency and decibels.
> Hm, hadn't thought about that, could be an issue. Can you give me
> simple examples of when it would make sense, for both of these, to have
> increments, and not just a range ?
> Anyway, the increment would then probably be treated as a multiplier,
> instead of an accumulator value, no ?
One approach which I ended up doing in dparams is if the range is flagged
as being logarithmic value then the lower and upper are stored in
GST_TYPE_RANGE as log(lower), log(upper). The increment then becomes a
value which linearly increments from log(lower), log(upper).
You can then do linear arithmetic for increments as you would for a linear
GST_TYPE_RANGE. When you want a real value back out again, you have to do
exp(value) to get the desired value back.
see demo_dparams.c lines 103 and 25 for this in action.
I don't know if this is the most mathmatically correct and
self-documenting way of doing it - perhaps some maths inclined developers
> Not sure yet where the information of what the increment does should be
> stored; maybe a fourth GValue holding an enum ?
Hopefully all that is needed is a fourth boolean GValue flagging it as
More information about the gstreamer-devel