Don't re-start the queue push task on the source pad when a
flush-stop event comes in and we're in the process of shutting
down, otherwise that task will never be stopped again.
When the element is set to READY state, the pads get de-activated.
The source pad gets deactivated before the queue's own activate_mode
function on the source pads gets called (which will stop the thread),
so checking whether the pad is active before re-starting the task on
receiving flush-stop should be fine. The problem would happen when the
flush-stop handler was called just after the queue's activate mode
function had stopped the task.
Spotted and debugged by Linus Svensson <linux.svensson@axis.com>
https://bugzilla.gnome.org/show_bug.cgi?id=734688
Otherwise it would only be proxied for the active pad which can lead
upstream to use an incompatible caps for the downstream element.
Even if a reconfigure event is sent upstream when the pad is activated, this
will save the caps reconfiguration if it is already using an acceptable caps.
Just remove one skip annotation that causes this:
** (g-ir-compiler:12458): ERROR **: Caught NULL node, parent=empty
with older g-i versions such as 1.32.1.
This function is not really pad or slow for the common case of requesting a
pad with the name of the template. It is only slower if you to name your pads
directly instead of letting the element handle it.
Also there's no reason to deprecate it in favor of a more complicated function
for the common case.
After EOS there will be no further buffer which could propagate the
error upstream, so nothing is going to post an error message and
the pipeline just idles around.
SetEvent() seems to not call SetLastError(0) internally, so checking last
error after calling SetEvent() may return the error from an earlier W32 API
call. Fix this by calling SetlastError(0) explicitly.
Currently WAKE_EVENT() code is cramped into a macro and doesn't look to be
entirely correct. Particularly, it does not check the return value of
SetEvent(), only the thread-local W32 error value. It is likely that SetEvent()
actually just returns non-zero value, but the code mistakenly thinks that the
call has failed, because GetLastError() seems to indicate so.
https://bugzilla.gnome.org/show_bug.cgi?id=733805
default_alloc_buffer() calls gst_buffer_new_allocate() but does not check for
failed allocation.
This patch makes default_alloc_buffer() return an error (GST_FLOW_ERROR) if
buffer allocation fails.
https://bugzilla.gnome.org/show_bug.cgi?id=733974
If the current max-buffers limit it infinite and a finite value is
requested, switch to the MAX (requested, current-value) to set some
limit but not below what we know that we've needed so far.
https://bugzilla.gnome.org/show_bug.cgi?id=733837
When eos events are forwarded simultaneouly from two sinkpads on
funnel, it doesnot forward the eos to sourcepad. The reason is
sticky events are stored after the event callbacks are returned.
Therefore while one is about to store the sticky events on the its
sinkpad, other sinkpad starts checking for the eos events on all other
sinkpads and assumes eos is not present yet.
https://bugzilla.gnome.org/show_bug.cgi?id=732851
When going to READY, it is possible that we are still pusing a frame but that
our srcpad has already been set to flushing. In that case we should not
post any error on the bus but instead cleanly return FLOW_FLUSHING.
https://bugzilla.gnome.org/show_bug.cgi?id=733320
The initial buffers (that were used for timestamping) might have PTS
and DTS set. In order to forward those properly, get the initial
PTS/DTS from the adapter and set them on the reconstructed output
buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=733291
* 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
GLib in git will spew a g_warning() when a property marked as
deprecated via param spec flags is accessed. Suppress this by
setting the appropriate environment variable.
GST_MESSAGE_ANY was considered a long by pygobject and gjs, and thus
couldn't be used in gst_bus_poll() and similar APIs as they expect an
int-typed enum.
Just use 0xffffffff instead for now.
https://bugzilla.gnome.org/show_bug.cgi?id=732633
We always work in passthrough mode so there's no point in doing
something more clever in basetransform. Also the basetransform
code leads to problems with incomplete caps and downstream
elements that use GST_PAD_FLAG_ACCEPT_INTERSECT.
https://bugzilla.gnome.org/show_bug.cgi?id=732559
