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
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.
Currently we set TAG_MEMORY as soon a resize changes the size of one
of the memory. This has the side effect that buffer pool cannot know if
the memory have simply been resized, or if the memorys has been replaced.
This make it hard to actually implement _reset(). Instead, only set the
TAG_MEMORY if one or more memory has been replaced, and do a light
sanity check of the size.
https://bugzilla.gnome.org/show_bug.cgi?id=727109
This should allow for more meaningful errors. Dereferencing NULL
is more useful information than dereferencing a random address
happened to be on the stack.
We want to iterate over items idx to idx + length
We use the len variable as the corrected number of memory to iterate
and then properly go over all items.
Fixes the issue where specifying any idx different from 0 had no effect
Spotted by clang static analyzer
* 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
GObject Introspection does not support macros.
This is needed for bindings. We can still add back
macros or inline functions again later if we think
it's worth it.
https://bugzilla.gnome.org/show_bug.cgi?id=678301
Move the locking methods from GstMemory to GstMiniObject.
Add a miniobject flag to enable LOCKABLE objects. LOCKABLE objects can
use the lock/unlock API to control the access to the object.
Add a minobject flag that allows you to lock an object in readonly mode.
Modify the _is_writable() method to check the shared counter for LOCKABLE
objects. This allows us to control writability separately from the refcount for
LOCKABLE objects.
