The global seqnum variable wasn't actually increased in
the fallback code path, leading to all buffers getting
a seqnum of 0. Which also made the unit test fail.
This affects platforms/toolchains that don't have
64-bit atomic ops such as when compiling for armv7 rpi.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/645>
The argument must be at least a GObject according to the GstLogFunction
definition, and while the default C log function handles miniobjects
just fine this is crashing bindings and user-supplied log functions that
(rightfully) don't expect anything but GObjects.
For metas where order might be significant if multiple metas are
attached to the same buffer, so store a sequence number with the
meta when adding it to the buffer. This allows users of the meta
to make sure metas are processed in the right order.
We need a 64-bit integer for the sequence number here in the API,
a 32-bit one might overflow too easily with high packet/buffer
rates. We could do it rtp-seqnum style of course, but that's a
bit of a pain.
We could also make it so that gst_buffer_add_meta() just keeps metas in
order or rely on the order we add the metas in, but that seems too
fragile overall, when buffers (incl. metas) get merged or split.
Also add a compare function for easier sorting.
We store the seqnum in the MetaItem struct here and not in the
GstMeta struct since there's no padding in the GstMeta struct.
We could add a private struct to GstMeta before the start of
GstMeta, but that's what MetaItem effectively is implementation-
wise. We can still change this later if we want, since it's all
private.
Fixes#262
Fix corruption of meta list head when removing metas at the beginning
during iteration. Linked list handling in gst_buffer_foreach_meta
failed to track the previous entry and update the correct next pointer
when removing items from beyond the head of the list, resulting in
arbitrary list pointer corruption.
Closes#332
Every container of miniobjects now needs to store itself as parent in
the child object, and remove itself again at a later time.
A miniobject is only writable if there is at most one parent, and that
parent is writable itself, and if the reference count of the miniobject
is 1.
GstBuffer (for memories), GstBufferList (for buffers) and GstSample (for
caps, buffer, bufferlist) was updated accordingly.
Without this it was possible to have e.g. a bufferlist with refcount 2
in two places, modifying the same buffer with refcount 1 at the same
time.
https://bugzilla.gnome.org/show_bug.cgi?id=796692
This is a meta that generically allows to attach additional reference
timestamps to a buffer, that don't have to relate to the pipeline clock
in any way.
Examples of this could be an NTP timestamp when the media was captured,
a frame counter on the capture side or the (local) UNIX timestamp when
the media was captured.
https://bugzilla.gnome.org/show_bug.cgi?id=779213
This previously caused uninitialized memory unless something else was
initializing all the fields explicitly to something.
To be on the safe side, we also allocate metas without init function to all
zeroes now as it was relatively common.
https://bugzilla.gnome.org/show_bug.cgi?id=764902
Don't copy memory metas if we only copied part of the buffer, didn't
copy memories or merged memories. In all these cases the memory
structure has changed and the memory meta becomes meaningless.
https://bugzilla.gnome.org/show_bug.cgi?id=751712
A core meta which helps implement the old concept
of sub-buffering in some situations, by making it
possible for a buffer to keep a ref on a different
parent buffer. The parent buffer is unreffed when
the Meta is freed.
This meta is used to ensure that a buffer whose
memory is being shared to a child buffer isn't freed
and returned to a buffer pool until the memory
is.
https://bugzilla.gnome.org/show_bug.cgi?id=750039
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.
gstbuffer.c:522:58: error: implicit conversion from enumeration type 'GstBufferFlags' to
different enumeration type 'GstBufferCopyFlags' [-Werror,-Wenum-conversion]
if (!gst_buffer_copy_into (copy, (GstBuffer *) buffer, flags, 0, -1))
~~~~~~~~~~~~~~~~~~~~ ^~~~~
gstbuffer.c:534:46: error: implicit conversion from enumeration type 'GstBufferCopyFlags' to
different enumeration type 'GstBufferFlags' [-Werror,-Wenum-conversion]
return gst_buffer_copy_with_flags (buffer, GST_BUFFER_COPY_ALL);
~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~
./gstbuffer.h:433:31: note: expanded from macro 'GST_BUFFER_COPY_ALL'
...((GstBufferCopyFlags)(GST_BUFFER_COPY_METADATA | GST_BUFFER_COPY_MEMORY))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A variant of gst_buffer_copy that forces the underlying memory
to be copied.
This is added to avoid adding an extra reference to a GstMemory
that might belong to a bufferpool that is trying to be drained.
The use case is when the buffer copying is done to release the
old buffer and all its resources.
https://bugzilla.gnome.org/show_bug.cgi?id=745287
I was confused by the existence of `gst_buffer_get_meta` as it suggested
to me that you should only attach one of any type of GstMeta to a buffer.
It's perfectly fine to attach multiple from a single API so I'm
documenting that here.
https://bugzilla.gnome.org/show_bug.cgi?id=737129
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
