The lock is never used

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

If select-stream event was send to playbin3 as missing any GstStream of ES type
(V or A or TEX) of collection then, playbin will access to invalid address of
GstStream due to invalid index limit. This caused SIGSEGV.

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

Blacklisted mimetypes have been empty in almost 10 years ...

This is now handled by the GstBin baseclass

And instead use the "setup-source" signal. This opens the way to deal
with more than one 'source' for a given playlist entry

Application might choose only specific type among all available types
using select-streams event. In this case, it is desired that reconfigure
of playsink to clear unused stream path.

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

We are not sure that which stream's collection arrives first
when there are multiple parsebins such as adaptive streaming.

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

The "frame" property is no more, it's "sample" these days.

Modernizing the documentation, making it simpler to read an
modify and allowing us to possibly switch to hotdoc in the
future.

This only has effect on network streams in these elements, and by
enabling it by default we get the same behaviour as in playbin2.

Since gst_event_parse_select_streams() returns newly allocated
memory for stream-id(s), it should be freed explicitly.

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

If selected streams and actived streams are matched,
do reconfigure of playsink again with pad-removed signal

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

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

It never reach into this code path, custom_combiner always not null
here.

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

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

The underlying integer type of the enum GstVideoMultiviewFlags is
implementation defined and may not have the same size as guint.

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

Therefor don't use equality

These can all be used via the GstStream API

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

Allows configuration of plugged elements.

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

The collection referenced owned by playbin3 was not released when it was
destroyed.

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

Add some more text to the docs for urisourcebin,
parsebin, decodebin3 and playbin3, including a warning
that they are unstable API for now

Docs still need some fleshing out though.

The stream returned by gst_message_streams_selected_get_stream() is
reffed.

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

gst_message_parse_stream_collection() and
gst_message_parse_streams_selected() actually return a reffed
GstStreamCollection.

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

With contributions from Jan Schmidt <jan@centricular.com>

* decodebin3 and playbin3 have the same purpose as the decodebin and
playbin elements, except make usage of more 1.x features and the new
GstStream API. This allows them to be more memory/cpu efficient.

* parsebin is a new element that demuxers/depayloads/parses an incoming
stream and exposes elementary streams. It is used by decodebin3.
It also automatically creates GstStream and GstStreamCollection for
elements that don't natively create them and sends the corresponding
events and messages

* Any application using playbin can use playbin3 by setting the env
variable USE_PLAYBIN3=1 without reconfiguration/recompilation.

We take a ref before removing which was never freeded.
The element is still alive anyway because the group has its own ref as
well.

Fix a leak with the 'test_suburi_error_wrongproto' test.

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

Allows configuration of plugged elements.

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

Otherwise a decoder supporting GL memory will think that all downstream can
support GL memory because of seeing its own template caps.

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

This reverts commit 023af2d3.

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

Elements usually require that all fields on their caps are present
on the fixed caps they receive. Using intersection won't verify it,
resort to using is_subset() checks.

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

accept-caps is only for one element, caps query is recursive. Fixes playback
with totem and other situations.

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

Unconditionally adding the template caps when proxying the caps query will play
havoc with decoders that attempt to choose an output format based on some caps
features.  Creating a sink that does not include those caps features and a
decoder/parser/etc that preferentially chooses some specific caps feature when
available, will always return the decoder/parser/etc template caps and choose a
feature that downstream will be unable to support.

Fix by limiting the addition of the template caps to when the result is actually
empty.

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

Send event directly to playsink instead of letting GstBin iterate
over all sink elements. The latter might send the event multiple times
in case the SEEK causes a reconfiguration of the pipeline, as can easily
happen with adaptive streaming demuxers.

What would then happen is that the iterator would be reset, we send the
event again, and on the second time it will fail in the majority of cases
because the pipeline is still being reconfigured

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

Not only if the base class told us, but also if one of our own elements did.

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