The default padding I introduced in d4f81fb4e6 is
actually only 4 pointers and on 32bit platforms already smaller than the union.
Replace it with a fixed 64byte padding. Don't add the normal padding for now.
Fixes#755822
While this technically is an abi break, we decided to do this:
1) the struct is documented to be internal
2) the struct is alloced and freed inside the library
3) there are no public methods that receive or return instances
4) the only code known to use this struct are classes containd here
There was few Since: mark missing their column. Also unify the way
we set the Since mark on enum value and structure members. These
sadly don't show up in the index.
We were segfaulting because g_sequence_search was returning the iter_end,
and that iterator does not contain anything and thus should not be used
directly
In order for user to be able to track changes in the value set in
GstTimedValueControlSource the following signals have been added:
* value-added
* value-removed
* value-changed
To be able to use a GstControlPoint to be marshalled into the signals,
the GstControlPoint structure is now registerd as a GBoxed type.
New API:
~~~~~~~
* GstTimedValueControlSource::value-added
* GstTimedValueControlSource::value-removed
* GstTimedValueControlSource::value-added
https://bugzilla.gnome.org/show_bug.cgi?id=737616
* fix typo GstBufferFlag -> GstBufferFlags
* fix typo GstFeatures -> GstCapsFeatures
* fix typo GstAllocatorParams -> GstAllocationParams
* fix typo GstContrlSources -> GstControlSource
* do not refer to gstcheck as an object
* make references gtk_init() and tcase_set_timeout() not be references
* gst_element_get_pad() renamed gst_element_get_static_pad()
* gst_clock_id_wait_async_full() renamed gst_clock_id_wait_async()
* _drop_element() is really gst_queue_array_drop_element()
* gst_pad_accept_caps() was removed, do not refer to it
* separate GST_META_TAG_MEMORY_STR declaration from description
* do not describe removed gst_collect_pads_collect()
* correctly link to GstElementClass' virtual set_context()
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=719614
The change should have been from PARAM_CONSTRUCT_ONLY to
PARAM_CONSTRUCT, otherwise bindings are affected, since
they look for the CONSTRUCT flag.
See ec55363d
When the range for a property is defined as -INT_MAX-1 .. INT_MAX, like
the xpos in a videomixer the following expression in the macro
definitions of convert_g_value_to_##type (and the equivalent in
convert_value_to_##type)
v = pspec->minimum + (g##type) ROUNDING_OP ((pspec->maximum - pspec->minimum) * s);
are converted to:
v = -2147483648 + (g##type) ROUNDING_OP ((2147483647 - -2147483648) * s);
(2147483647 - -2147483648) overflows to -1 and the net result is:
v = -2147483648 + (g##type) ROUNDING_OP (-1 * s);
so v only takes the values -2147483648 for s == 0 and 2147483647
for s == 1.
Rewriting the expression as minimum*(1-s) + maximum*s gives the correct
result in this case.
https://bugzilla.gnome.org//show_bug.cgi?id=705630
The _1_0 suffixed environment variables override the
non-suffixed ones, so if we're in an environment that
sets the _1_0 suffixed ones, such as jhbuild, we need
to set those to make sure ours actually always get
used.
Using multiple libraries causes problems for the C# bindings and
will for similiar languages such as Java when there are bindings
for them.
Also change --library=libgstfoo-X.la to --library=gstfoo-X as
the man page suggests it should be done.
https://bugzilla.gnome.org/show_bug.cgi?id=679315
Rename the _get_value_array() functions to _get_g_value_array() and reintroduce
the former to operate on plain unboxed c datatypes (like in 0.10). The _g_value
variants are for bindings while the _value ones are more suited to processing
in elements.