Previously, dropping a query from a pad probe would deem the
query succeeded, and the caller might then assume the query's
results are valid, and thus dereference an invalid object
such as a GstCaps.
We now assume dropped queries did not succeed. Dropped events
and buffers are still deemed a success.
Added back after previous revert, as it's been double checked.
https://bugzilla.gnome.org/show_bug.cgi?id=740003
Previously, dropping a query from a pad probe would deem the
query succeeded, and the caller might then assume the query's
results are valid, and thus dereference an invalid object
such as a GstCaps.
We now assume dropped queries did not succeed. Dropped events
and buffers are still deemed a success.
If a task thread is calling pause on it self and the
controlling/"main" thread stops the task, it could end in a race
where gst_task_func loops and then checks for paused after the
controlling thread just changed the task state to stopped.
Hence the task would actually call func again even though it was
both paused and stopped.
https://bugzilla.gnome.org/show_bug.cgi?id=740001
It's architecture dependent and should not be placed into the include
directory as the assumption is that all those headers are architecture
independent.
https://bugzilla.gnome.org/show_bug.cgi?id=739767
Currently we are just returning FALSE, but we do have the information
we should just answer the query the same way as when answering through
the GstElement.query vmethod default implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=739580
In this mode we accept previously set filter caps until
upstream renegotiates to something that is compatible
to the current filter caps.
This allows dynamic caps changes in the pipeline even
if there is a queue between any conversion element
and the capsfilter. Without this we would get not-negotiated
errors if timing is bad.
https://bugzilla.gnome.org/show_bug.cgi?id=739002
The GST_INFO ("initialized GStreamer succesfully") is currently at the end of
gst_init_check which isn't guaranteed to be run since GStreamer can be
initialized by using init_pre and init_post directly from GOptionContext like
gst-launch does. Ensure this message is displayed by moving it to init_post.
Use an array of constant strings so if arguments get
removed from it they are not considered leaked, and
valgrind is happy. Still some stuff leaking in GLib
though.
Make pipe socket non-blocking, so we don't
end up being blocked in a write on the pipe
while the src is eos and not reading data
any more, and thus we never unblock and never
notice that we're done. This would happen
quite reliably on the rpi.
Fixes 'Attempt to unlock mutex that was not locked'
warning with newer GLibs when sink is shut down in
certain situations. Triggered by the decodebin
test_reuse_without_decoders unit test in -base
sometimes, esp. on slower machines.
In order for user to be able to track changes in the value set in
GstTimedValueControlSource the following signals have been added:
* value-added
* value-removed
* value-changed
To be able to use a GstControlPoint to be marshalled into the signals,
the GstControlPoint structure is now registerd as a GBoxed type.
New API:
~~~~~~~
* GstTimedValueControlSource::value-added
* GstTimedValueControlSource::value-removed
* GstTimedValueControlSource::value-added
https://bugzilla.gnome.org/show_bug.cgi?id=737616
Use some macros to make our value functions setup a bit
tidier, and micro-optimise a few reallocs by setting an
initial size for the global type arrays.
Remove a useless assert (we just instantiated this type). Drop the free'ing of
the extension array. As we just created the instance this is always NULL.
The point of this example is to show how to set caps
on the source pad once it has been set on the sink pad.
So, in passthrough mode, the caps is just copied to the
source pad.
https://bugzilla.gnome.org/show_bug.cgi?id=738153
If we are pushing a serialized query into a queue and the queue is
filled, we will end in a deadlock. We need to release the lock before
pushing and acquire it again afterward.
https://bugzilla.gnome.org/show_bug.cgi?id=737794
Running two threads, one executing the timer and one unscheduling it, the
unscheduled status set by the second thread is sometimes overwritten by the
first one.
https://bugzilla.gnome.org/show_bug.cgi?id=737999
