Use g_object_new() instead which nowadays has a shortcut for the
no-properties check. It still does an extra GType check in the
function guard, but there's a pending patch to remove that
and it's hardly going to be a performance issue in practice,
even less so on a system that's compiled without run-time checks.
Alternative would be to move to the new g_object_new_properties()
with a fallback define for older glib versions, but it makes the
code look more unwieldy and doesn't seem worth it.
Fixes deprecation warnings when building against newer GLib versions.
https://bugzilla.gnome.org/show_bug.cgi?id=780903
Allows proxying the control interface from one property on one GstObject
to another property (of the same type) in another GstObject.
E.g. in a parent-child relationship, one may need to
gst_object_sync_values() on the child and have a binding (set elsewhere)
on the parent update the value.
Note: that this doesn't solve GObject property forwarding and must be
taken care of by the implementation manually or using GBinding.
https://bugzilla.gnome.org/show_bug.cgi?id=774657
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Mathieu Duponchelle <mathieu.duponchelle@opencreed.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
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.
