If guessing that a string matches a flagset, be more thorough
at checking that the string following a string of hex:hex:
actually looks like a flag set string. Add some unit tests
to catch more cases.
https://bugzilla.gnome.org/show_bug.cgi?id=779755
But only when serializing outside of GstStructures, because in case of
GstStructure the type is already preprended to the array/list and the
GstStructure API makes sure that they have the same "generic" type so
deserialization works properly.
This keeps serialization of GstStructures the same as before, and the
GstCaps unit tests already test for that. However when serializing
standalone arrays/lists get the types added now.
Allows proper usage of structures in structures in caps. Subtraction
is not implemented due to complications with empty fields representing
all possible values.
The only implementation that doesn't delegate to the already existing
GstStructure functions is the union function.
https://bugzilla.gnome.org/show_bug.cgi?id=775796
Implement GstDynamicTypeFactory as a new registry feature.
GstDynamicTypeFactory provides a way of registering a GType
into the registry, such that it will be registered as a dynamic
type when the registry is loaded, and then automatically loaded
if the type is needed during caps parsing.
This allows using non-core types in pad templates, by loading a
registry feature to create the GType on the fly.
https://bugzilla.gnome.org/show_bug.cgi?id=750079
While calling gst_value_deserialize_sample, if there is a failure
after caps is ref'ed, then caps is getting leaked. Hence checking for
caps in fail: goto condition and unref'ing it
https://bugzilla.gnome.org/show_bug.cgi?id=753338
So from this point, the remaining warning for libgstreamer are about
protected member not showing in the doc. This may need some discussion
with upstream gtk-doc people.
* Remove % in from of none macro
* Fixed GST_TYPE_FAGS -> GST_TYPE_FAG_SET
* Minor wording fix
* Can't link to GstUri.port, so split the .port part
GstFlagSet is a new type designed for negotiating sets
of boolean capabilities flags, consisting of a 32-bit
flags bitfield and 32-bit mask field. The mask field
indicates which of the flags bits an element needs to have
as specific values, and which it doesn't care about.
This allows efficient negotiation of arrays of boolean
capabilities.
The standard serialisation format is FLAGS:MASK, with
flags and mask fields expressed in hexadecimal, however
GstFlagSet has a gst_register_flagset() function, which
associates a new GstFlagSet derived type with an existing
GFlags gtype. When serializing a GstFlagSet with an
associated set of GFlags, it also serializes a human-readable
form of the flags for easier debugging.
It is possible to parse a GFlags style serialisation of a
flagset, without the hex portion on the front. ie,
+flag1/flag2/flag3+flag4, to indicate that
flag1 & flag4 must be set, and flag2/flag3 must be unset,
and any other flags are don't-care.
https://bugzilla.gnome.org/show_bug.cgi?id=746373
Don't unwrap strings that start but don't finish with a double quote. If a
string is delimited by two quotes we unescape them and any special characters
in the middle (like \" or \\). If the first character or the last character
aren't a quote we assume it's part of an unescaped string.
Moved some deserialize_string unit tests because we don't try to unwrap strings
missing that second quote anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=688625
Use some macros to make our value functions setup a bit
tidier, and micro-optimise a few reallocs by setting an
initial size for the global type arrays.
When serializing GstStructures from events in GDP it will add a taglist
as a GstStructure field, having the compare function allows comparison of
GstStructures to check if the serialized/deserialized version matches the
original one, among other cases.
https://bugzilla.gnome.org/show_bug.cgi?id=733131
* GstGlobalDeviceMonitor was renamed to GstDeviceMonitor
* Expand GST_MESSAGE_DEVICE to the full enum value names
* Correct the incorrect references to the GstDeviceProvider interfaces
* Describe caps arguments for gstcheck interface
* Add missing docs for GstNetAddressMeta and its add function
* Add docs for toc helper macros
* Avoid refering to GstValueList type as done elsewhere
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732786
Support for (nullable) was added to G-I at the same time as nullable
return values. Previous versions of G-I will not mark return values as
nullable, even when an (allow-none) annotation is present, so it is
not necessary to add (allow-none) annotations for compatibility with
older versions of G-I.
https://bugzilla.gnome.org/show_bug.cgi?id=730957
Currently we leak the internal representation of them as two GValues that
contain a fraction. Without this we could store fraction ranges as
data[0] = (min_n << 32) | (min_d)
data[1] = (max_n << 32) | (max_d)
and wouldn't require an additional allocation per range.
Otherwise negative values will sets all of the 64 bits due to two's
complement's definition of negative values.
Also add a test for negative int ranges.
Both gst_value_intersect and gst_value_subtract will call
gst_value_compare if one of their arguments isn't a list.
gst_value_compare will then re-do a check to see if one of
the arguments is a list (for the special case of comparing a unitary
value with a list of length 1).
The problem is that the various G_VALUE_HOLDS represent an expensive
amount of calling gst_value_compare (almost half of it) to see if
the provided arguments are list. These checks can be done without
when we know that the arguments aren't lists.
* Create a new "nolist" gst_value_compare which avoids that special
case comparision
Benchmarks:
valgrind/callgrind: average speedup in instruction calls for
gst_value_intersect and gst_value_subtract is around 56% (Makes 63%
of the calls it used to take previously)
tests/benchmarks/capsnego: With default settings (depth 4, children 3
607 elements), time taken for transition from READY to PAUSED:
Before : 00.391519153
After : 00.220397492
56% of the time previously used, +77% speedup
https://bugzilla.gnome.org/show_bug.cgi?id=731756
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
The step can end up being zero if the underlying value isn't a valid
range GValue.
In those cases, return FALSE.
We don't use g_return*_if_fail since it will already have been triggered
by the above-mentionned _get_step() functions.
CID #1037132
