Also handle the case gracefully where the subclass decides to drop
the first buffers and has no caps set yet. It's still required to
have valid caps set when the first buffer should be passed downstream.
Sending the flush-start event forward before taking the stream lock actually
works, in contrast to deadlocking in downstream preroll_wait (hunk 1).
After that we get the chain function being stuck in a busy loop. This is fixed
by updating the minimum frame size inside the synchronization loop because the
subclass asks for more data in this way (hunk 2).
Finally, this leads to a very probable crash because the subclass can find a
valid frame with a size greater than the currently available data in the
adapter. This makes the subsequent gst_adapter_take_buffer call return NULL,
which is not expected (hunk 3).
Baseparse internaly breaks the semantics of a _chain function by calling it with
buffer==NULL. The reson I belived it was okay to remove it was that there is
also an unchecked access to buffer later in _chain. Actually that code is wrong,
as it most probably wants to set discont on the outgoing buffer.
This allows to only create the socketpair when it is really required instead
of always creating it and immediately destroying it again for child buses.
https://bugzilla.gnome.org/show_bug.cgi?id=647005
This is used by GstBin to create a child bus without
a socketpair because child buses will always work
synchronous. Otherwise too many sockets could be
created and the limit of file descriptors for the
process could be reached.
Fixes bug #646624.
if set->control_pending is set to 0 but we didn't not succed reading
the control socket, future calls to gst_poll_wait() will be awaiken
by the control socket which will not be released properly because
set->control_pending is already 0, causing an infinite loop.
This caused "re-declaration" problems.
./clutter-gst-video-sink.c: In function ‘clutter_gst_video_sink_init_interfaces’:
./clutter-gst-video-sink.c:231:1: warning: declaration of ‘ClutterGstVideoSink’ shadows a global declaration [-Wshadow]
./clutter-gst-video-sink.h:64:44: warning: shadowed declaration is here [-Wshadow]
https://bugzilla.gnome.org/show_bug.cgi?id=646531
Some applications are requesting the same pad name multiple times
and the behaviour is undefined and different from element to element
but we don't want to break applications that work just fine.
In 0.11 this check should be an assertion again, although elements
have to do manual checking if the pad already exists again because
it can't be done in a threadsafe way here.
basesrc's default event handler returns TRUE regardless of whether the
event is handled or not. This fixes the handler to conform with the
expected behaviour (which is to only return TRUE when the event has
actually benn handled). gst_bin_do_latency_func() depended on this
(incorrect) behaviour, and is now modified as well.
(Remaining 1-liner change in gstbasesrc.c is to keep gst-indent happy)
Just like gst_caps_intersect, but adds a new parameter 'mode'
that allows selecting the intersection algorithm to use.
Currently we have GST_CAPS_INTERSECT_MODE_ZIG_ZAG (default) and
GST_CAPS_INTERSECT_MODE_FIRST.
API: gst_caps_intersect_full
API: GstCapsIntersectMode
API: GST_CAPS_INTERSECT_MODE_ZIG_ZAG
API: GST_CAPS_INTERSECT_MODE_FIRST
https://bugzilla.gnome.org/show_bug.cgi?id=617045
Adding a buffer to the end of a GstBufferList is supposed to be a fast
operation, but it was not since the iterator does not advance its
nextpointer when adding buffers and GList does not have a tail pointer.
Using a GQueue to store the buffers makes it easier to add buffers to
the end of the list and this operation will now be much more efficient.
Adding an entire GList of buffers using
gst_buffer_list_iterator_add_list() will however have to iterate over
the list being added to be able to update the tail pointer in the
GQueue.
GST_DISABLE_DEPRECATED should only affect visibility of declarations in headers,
not actually remove symbols. See GitDeveloperGuidelines and DeprecatingAPI
pages in wiki.
https://bugzilla.gnome.org/show_bug.cgi?id=402141
Add new functions to clarify how the caps are compared to the template caps of
the element factory. Improve the docs to point out the difference.
Deprecate: gst_element_factory_can_{src|sink}_caps
API: add gst_element_factory_can_{src|sink}_{any|all}_capps
https://bugzilla.gnome.org/show_bug.cgi?id=402141
