gstdebugutils.c: In function 'gst_debug_bin_to_dot_data':
gstdebugutils.c:683:530: error: 'return' with no value, in function returning non-void [-Werror]
g_return_if_fail (GST_IS_BIN (bin));
TRUE is 1, but every other non-zero value is also considered true. Comparing
for equality with TRUE would only consider 1 but not the others.
Also normalize booleans in a few places.
The documentation states that gst_element_send_event is to "send an event
to an element".
Therefore we *send* upstream events to a source pad and downstream events
to a sink pad
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
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 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.
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
These are actually not true.
gsturi.c: In function '_gst_uri_string_to_table.constprop':
gsturi.c:1316:27: error: 'pct_kv_sep' may be used uninitialized in this function [-Werror=maybe-uninitialized]
for (next_sep = strcasestr (value, pct_kv_sep); next_sep;
^
gsturi.c:1283:24: error: 'pct_part_sep' may be used uninitialized in this function [-Werror=maybe-uninitialized]
next_sep = strcasestr (next_sep + 1, pct_part_sep)) {
^
We're not actually doing anything differently anywhere when
we detect that we're running under valgrind, so let's not
print that confusing message that makes people wonder how
they can switch it off so they can valgrind the normal
code paths. Seeing that we're not doing that nor have done
so in the last 10 years we might just as well remove the
entire check actually.
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
Use user_data to pass the log_file handle to the logger-function.
If one wants to change the log target (e.g. GST_DEBUG_FILE), simply call
gst_debug_remove_log_function() and re-add the handler with the new log-target
using gst_debug_add_log_function ().
Inactive pads should at all times have the flushing flag set. This means
that when we get a flush-stop on an inactive pad we must ignore it.
On sinkpads, make this more explicit. We used to not clear the flush
flag but remove the events and then return an error because the flushing
flag was set. Now just simply refuse the event without doing anything.
On srcpads, check that we are trying to push a flush-stop event and
refuse it. We would allow this and mark the srcpad as non-flushing
anymore.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=735357
