There were two issues with the previous decodebin2 group switching algorithm:
Issue 1: It operated with no memory of what has been drained or not, leading to
multiple checks for chains/groups that were already drained.
Issue 2: When receiving an EOS, it only detected that a higher-level chain
was drained if it contained the pad receiving the EOS.
The following modifications have been applied:
- a new drained property has been added to GstDecodeChain
- both drained properties of chain/group are set as soon as they are detected
- the algorithm now tests agains these values
See https://bugzilla.gnome.org/show_bug.cgi?id=685938
Should fix "cannot register existing type `GstPlaybinSelectorPad'" warnings
and subsequent errors when creating multiple players at the same time.
Conflicts:
gst/playback/gststreamselector.c
This allows the following use-cases to expose the group and pads
before an ALLOCATION query comes through:
* Single stream use-cases
* Multi stream use-cases where all streams sent the CAPS event before
the first ALLOCATION query
Some cases will still make the initial ALLOCATION query fail though,
which isn't optimal, but not fatal (it will recover when pads are
exposed, a RECONFIGURE event is sent upstream and elements can
re-send an ALLOCATION query which will reach downstream elements).
https://bugzilla.gnome.org/show_bug.cgi?id=680262
A caps event is also used to establish that a stream has prerolled.
Without this, we end up allowing negotiation queries to fail, ending
in decoders (and other elements) to not be configured right from the
start with the most optimal settings.
...and in playbin2 additionally prefer sinks over parsers.
This makes sure that we a) always directly plug a sink if it supports
the (compressed) format and b) always plug parsers in front of decoders.
In order to allow for proper functionality when a decoder only supports
one instance at a time (dsp), we must block the demuxer pads when they
get created if they are not part of the active group, preventing buffers
from being sent to the decoder (and initializing it through setcaps),
then after we switch to a new group, we unblock the demuxer pads for
the active groups. In the callback for the unblock, we prune the old
groups, making sure the previous decoder instance is destroyed before
we push a buffer to the new instance.
Since caps are no longer 'shared' between two pads (but forwarded from
source pad to sink pad) we end up with the first chain pad not having
specified caps (i.e. typefind:src).
This solves the issues by getting the pad's peer caps.
It is not optimal since it will (for most demuxers) return the pad
template caps, which might contain non-fixed caps (ex : with
qtdemux "video/quicktime; video/mj2; audio/x-m4a; application/x-3gp")
https://bugzilla.gnome.org/show_bug.cgi?id=667337
... to also properly indicate chain's endpad if no elements are in the
chain (due to the endpad being a raw demuxer pad, or one setup without
decoders since uridecodebin or higher up decided not to need those).
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We'll change these
over to the new API once we depend on glib >= 2.32.
Replace g_thread_create() with g_thread_try_new().
