API: gst_value_array_append_and_take_value
API: gst_value_list_append_and_take_value
We were already using this internally, this makes it public for code
which frequently appends values which are expensive to copy (like
structures, arrays, caps, ...).
Avoids copies of the values for users. The passed GValue will also
be 0-memset'ed for re-use.
New users can replace this kind of code:
gst_value_*_append_value(mycontainer, &myvalue);
g_value_unset(&myvalue);
by:
gst_value_*_append_and_take_value(mycontainer, &myvalue);
https://bugzilla.gnome.org/show_bug.cgi?id=701632
These are meant to specify features in caps that are required
for a specific structure, for example a specific memory type
or meta.
Semantically they could be though of as an extension of the media
type name of the structures and are handled exactly like that.
Set operations on the bitmasks don't make much sense and result
in invalid caps when used as a channel-mask. They are now handled
exactly like integers.
This functionality was not used anywhere except for tests.
https://bugzilla.gnome.org/show_bug.cgi?id=691370
Avoid unnecessary value copying, and unnecessary init/unset
cycles which all go through the value table. There's a bunch
of places where we copy a value and then unset it in the next
line, instead of just taking over the source value.
Fixes negotiation taking a ridiculous amount of
time (multiple 10s of seconds on a core2) when
there are duplicate entries in lists.
Could have a negative performance impact on other
scenarios because we now have to iterate the
dest list to avoid duplicates, but we don't
have a lot of lists any more these days, and
they tend to be small anyway. The negatives
are hopefully countered by the positive effects
of reducing the list length early on in the
process. And in any case, it's the right thing
to do.
Based on patch by Andre Moreira Magalhaes.
https://bugzilla.gnome.org/show_bug.cgi?id=684981
So we can serialise/deserialise taglists inside structures,
which used to work automagically before because GstTagList
was just a typedef to GstStructure (same for the GType),
but now that it's a separate GType we need to register
explicit functions for this.
Helps with GDP stuff in pipelines/streamheader tests.
This re-uses existing code and makes sure we properly serialise
and deserialise datetimes where not all fields are set (thus
fixing some warnings when serialising such datetimes).
Take into account that not all fields might be valid (though they
are valid in the GDateTime structure). But we should just return
unordered if the set fields don't match. Also, don't check
microseconds when comparing datetimes, since we don't serialise
those by default if they're available. This ensures date times are
still regarded as equal after serialising+deserialising.
Ass serialize and deserialize functions for GstSegment so that gdp and
gst_structure_to_string show the segment values. We convert to a GstSegment
first to make things easier..
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=674100
Group the extra allocation parameters in a GstAllocationParams structure to make
it easier to deal with them and so that we can extend them later if needed.
Make gst_buffer_new_allocate() take the GstAllocationParams for added
functionality.
Add boxed type for GstAllocationParams.
There isn't really any need to provide public API for that. It's not
used anywhere in practice, and we aim to provide an API that works
for GstCaps, not some kind of generic set manipulation API based on
GValue. Making this private also makes it easier to optimise this
later. We can always put it back if someone actually needs it.
int and int64 ranges can now have an optional step (defaulting to 1).
Members of the range are those values within the min and max bounds
which are a multiple of this step.
https://bugzilla.gnome.org/show_bug.cgi?id=665294
Which we had to add because GLib didn't have it
back in the day. Port everything to plain old
G_TYPE_DATE, which is also a boxed type. Ideally
we'd just use GDateTime for everything, but it
doesn't support not setting some of the fields
unfortuntely (which would be very useful for
tag handling in general, if we could express
2012-01 for example).
https://bugzilla.gnome.org/show_bug.cgi?id=666351
This fixes caps operations when different elements advertise some
of their caps' properties differently (eg, for audio channels, either
a range from 1 to 2, or a list of 1 and 2).
https://bugzilla.gnome.org/show_bug.cgi?id=663643
When we do not care about the actual resulting set,
but only whether it is empty of not, we can skip a fair bit
of GValue juggling.
Add a function that does so, since we cannot just pass NULL
to the existing API as it may be part of the API contract.
https://bugzilla.gnome.org/show_bug.cgi?id=662777
