GitLab

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.

gstelements_private.c: In function 'gst_writev_buffers':
gstelements_private.c:236:51: error: 'EWOULDBLOCK' undeclared

Write out multiple buffers possibly containing multiple
memories with one writev() call, without merging the
buffer memories first, like ::render() does currently.

Otherwise the application might still get the old value if it asks
between the message and the real update.

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

If we get a downstream event we want to send it to a random SINK pad
(and vice-versa).

From f32cfcd to ef1ffdc

So that whenever user work with GstValidate they can run GES tests
within the gst-uninstalled environment

Has some updates for Clang support (might not work with newer Clang
properly, yet), AIX support, and some misc fixes.

When comparing percentage values, compare with 0-100 scale as it
has already been made relative to 0-high_percent, otherwise we mark
the queue as not buffering and report a 50% to the user. This leads to
a buffering stall as the user assumes the queue is still buffering but
it thinks it isn't.

https://bugzilla.gnome.org/show_bug.cgi?id=736969

multiqueue's queues stored percent value is the percentage from 0
to 100 (max-size-*) and should be compared with the requested limit
(high_percentage) set by the user and not with 100% to check if
buffering should stop. Otherwise we are only stopping buffering when the
queue gets completely full.

Instead of checking if our outcaps are equivalent to the previous incaps, and
if that is the case not setting any caps on the pad... compare against our
previous outcaps because that's what we care about.

Fixes some cases where the outcaps became equivalent to the previous incaps,
but the previous outcaps were different and we were then sending buffers
downstream that were corresponding to the caps we forgot to set on the pad.
Resulting in crashes or image corruption.

Fix configure check with bison development version.

https://bugzilla.gnome.org/show_bug.cgi?id=728946

When searching for the string terminator don't read past the ending
0-byte when escaping characters.
Add unit test for various escaping cases.

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

This was pushed by mistake along with an unrelated patch.

This reverts commit c7103ce4.

This can be useful for skipping large unwanted data, such as
large album art, when we know the size of it from a metadata
header.

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

Every value other than 0/FALSE is TRUE, == TRUE will only check for 1.

Adds gst_object_has_parent, which works like gst_object_has_ancestor
but does not ascend further.

API: gst_object_has_parent()

This API is in glib since 2.24 and we currently require 2.32 and already use
this unconditionally elsewhere.

The GQuark was never used.

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

gsturi.c:997: Error: Gst: Skipping invalid GTK-Doc comment block:
/** private GstUri functions **/
^
gsturi.c:1179: Error: Gst: Skipping invalid GTK-Doc comment block:
/** RFC 3986 functions **/
^

Reword the function docs, which haven't made any sense since
gst_data_queue_new_full() was removed a few years ago.

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

And get rid of g_list_prepend/g_list_reverse
anti-pattern while we're at it.

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.