And use it for the fraction comparisons in gstvalue.c instead
of using comparisons by first converting the fractions to double.
Should fix bug #628174.
API: gst_util_fraction_compare()
gst_element_link_many does some magic and creates ghostpads
if needed, but it didn't set the newly created ghostpad to
active if needed. This patch fixes it.
https://bugzilla.gnome.org/show_bug.cgi?id=626784
In gst_element_get_compatible_pad(), when trying to find a compatible pad on an
element for a given pad, there's no point in checking the element's sink pads
if the pad to link is a sink pad as well, or the element's source pads if the
given pad is a source pad already, since those would never be able to link
anyway. Should speed up linking using the convenience functions a little bit,
or at least reduce debug log output.
gst_pad_proxy_getcaps() would return the pad template caps if the other side
returned empty caps or if the intersection of all the caps on the other side
was empty.
https://bugzilla.gnome.org/show_bug.cgi?id=624203
No need to call gst_element_link_pads_filtered with filter=NULL, which would
call gst_element_link_pads() in that way. Call it directly to save a call and
expensive gobject type checks.
gst_util_greatest_common_divisor()
gst_util_double_to_fraction()
gst_util_fraction_to_double()
Using these instead of going over GValue has much lower overhead.
Also add float<->fraction transform functions for GValue.
In most places in core and baseclasses we just need the caps to do caps-
intersections. In that case ref'ed caps are enough (no need to copy).
This patch also switches the code to use the new functions.
API: gst_pad_get_caps_refed(), gst_pad_peer_get_caps_refed()
This is available in newer gcc releases and it should only exist
on platforms that provide some native 128bit integer arithmetic
instructions.
The x86-64 assembly for this is still kept for non-gcc compilers
that don't provide __uint128_t magic.
We can use a shift for scaling the denominator instead of a divide since the
denom is always positive. This avoids having the compiler generate code for the
different rounding rules when scaling negative values.
64bit x86 has native 64x64->128 bit multiply that we can use with some inline
assembler to speed up large multiplications.
Use bsr to find the number of leading zeros more efficiently.
The new functions are
gst_util_uint64_scale_int_round()
gst_util_uint64_scale_int_ceil()
gst_util_uint64_scale_round()
gst_util_uint64_scale_ceil()
Fixes bug #590919.
