GitLab

These flags will be used for Forward Error Correction purposes

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

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

For allow-none parameters

test_negotiation would occasionally time out, for unknown reasons.
Simplify the test setup and get rid of the main loop, busses, and
notify signals. With this I can no longer easily reproduce the
timeout. Fingers crossed.

Performance optimisation: Keep track whenever the streaming
thread or the application thread are waiting on the GCond for
more space or new data, and only signal on the GCond if someone
is actually waiting. Avoids unnecessary syscalls and thus
context switches.

Performance optimisation.

Avoids alloc/free churn for the queue's list nodes.

Depends on new API in GstQueueArray in core.

Performance optimisation: Keep track whenever the streaming
thread or the application thread are waiting on the GCond
for more space or new data, and only signal on the GCond if
someone is actually waiting. Avoids unnecessary syscalls and
thus context switches.

Performance optimisation.

Avoids alloc/free churn for the queue's list nodes.

These are very much artificial of course, but got to
measure something. appsink one contains lots of buffer
creation/free overhead, while appsrc one does not.

While it is pulled in via the GLib check, GLIB_LIBS is not pulled into
any of the places using the API.

When trying to create a wayland display, it may fail because there
is not actually display to connect. It this case NULL is returned
but the created instance is not freed.

This patch unrefs the failed display.

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

This is useful from python bindings

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

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

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

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

Fixes:

gst-launch-1.0 audiotestsrc ! audio/x-raw, format=U32BE ! \
audioconvert ! autoaudiosink

Previous code would pass 0 as source element.

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

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

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

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

If new headers arrive after we are initialized, we need to make
sure that they are indeed valid.

A vorbis bitstream always begins with three header packets and must
be in order.

Also some streams have unframed (invalid?) headers that might
confuse and disrupt the decoding process.

Therefore if ever we see new headers, we accumulate them and once
we get a non-header packet we check them to make sure that:
* We have at least 3 headers
* They are the expected ones (identification, comments and setup)
* They are in order
* Any other "header" is ignored

If those conditions are met, we reset and reconfigure the decoder

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