It was never used and makes no sense in the new streams-based world

The signals were never emitted from decodebin3. This needs
switching to a new signalling system

That signal is never emitted by decodebin3 and is handled differently

This is now handled directly via sinks and queries through pads

There's no reason to do async changing

Even if the input is monoscopic, the app might want to display
it in a different layout, to do side-by-side for VR for example,
so if the app changes the output-multiview-mode always use that.

Pass data with no caps and no streamheaders without
throwing a bunch of criticals

We can either receive an element that is floating or not and need to
accomodate that in the signal return values.  Do so by removing the
floating flag.

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

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

WARNING: Trying to compare values of different types (str, int).
The result of this is undefined and will become a hard error
in a future Meson release.

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

When the GstRTSPConnection class sends a RTSP over HTTP tunnelling
request, the HTTP Content-Type header is missing from the HTTP POST
request.

This isn't a problem with most servers, but there are servers that
rejects the request without there also being a Content-Type header.

RFC 1945:
Any HTTP/1.0 message containing an entity body should include a
Content-Type header field defining the media type of that body.

Apple Dispatch 28:
QuickTime Streaming uses the "application/x-rtsp-tunnelled" MIME
type in both the Content-Type and Accept headers. This reflects
the data type that is expected and delivered by the client and server.

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

Additions on top of

https://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=32a17f313494cbadaf8ec4e337d742e8d7e1b67b
https://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=c8b99139b1ef3f8891548b0f2607a135917c338e

We don't really want type=NONE as input and it was already impossible
for that to occur with the other condtions.

CID #1427144

gobject-introspection causes inconsistent type information for the
former and we use gpointer everywhere else.

It does not timeout anymore, even though it's a very slow test. For the
context, this test runs routines for a fixes amount of time and prints
the throughput. Which means the test takes more time everytime a pixel
format is added. If that becomes a problem again, we should disable the
benchmarks by default.

The source offset (soff) was not incremented for each component and then
each group of 3 components were inverted. This was causing a staircase
effect combined with some noise.

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

Now for real without un-needed comments...

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

Relicense with approval from Jose and Miguel. Code snippet
was supposed to be LGPL from the beginning.

https://bugzilla.gnome.org/show_bug.cgi?id=697808#c14
https://bugzilla.gnome.org/show_bug.cgi?id=697808#c15

An additional change for the texsubimage use case on top of
https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=c2b2c68beaddbea0ec4fe7b099507cc492f6dd7c
https://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=ea6bed111bab9b394d787f7760c6a3b953630d3a

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

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

On invalid packets there is the possibility we might end up wanting
to trim/offset more than what is available.

oss-fuzz issue #5866

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

instead of passing -fPIC manually.

As documented, passing -1 to x and/or y should reset the render
rectangle to the window/display size.

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

This allow controlling the render rectangle from gst-launch-1.0.

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

This also enables setting the render rectangle before the window
is provided or created.

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

This is a set of helper that makes it easy to enable the render
rectangle to be controllable through a property.

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

This adds a 10 bit variant for NV16 packed into 32 bits little endian
words. The MSB 2 bits are padding. This format is used on Xilinx SoC and
identified with the FOURCC XV20.

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

This add a 10bit variant of gray scale packed into 32bits little endian
words. The MSB 2 bits are padding and should be ignored. This format is
used on Xilinx SoC and is identified with the FOURCC XV10.

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

This adds a 10bit variant for NV12 which packs 3 10bit components
into little endian 32bit words. The MSB 2 bits are padding and should be
ignored. This format is used on Xilinx SoC and is identified with there
with the FOURCC XV15

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

With playbin the last subtitle chunk would not get displayed
if the last chunk was missing a newline at the end. This is
because streamsynchronizer will hold back the EOS event until
the audio and video streams are finished too, so subparse
would never forcefully push out the last chunk until the very
end when it is too late.

We get a STREAM_GROUP_DONE event from streamsynchronizer however,
so handle that like EOS and force out any remaining text then.

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

Add to valgrind suppressions file.

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

Alsasrc introduced delay_lock in commit 519f85a4
because alsa-lib is not thread safe for the same handle.
Alsasrc uses the same threading pattern, it should be locked too.

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

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