Remove the byte limit for adaptive http streaming. Because some fragments might
be very big, we might need a lot of buffering. I also suspect another problem
where data is actually missing and things go out of sync somehow.
When we disable buffering in the more upstream multiqueue elements,
we need to also update the queue limits. In particular, the max_size_time should
be set to 0 or else we might simply deadlock.
When we have a scenario of demuxers linked to demuxers, decodebin2
will create multiqueue at different levels of the pipeline. The problem
is that only the lowest multiqueue's should do the buffering messaging,
as they will handle with the raw streams data.
When all multiqueues are doing buffering, the upper ones can handle
large buffers that easily fill them, moving from 0% to 100% from
buffer to buffer, causing too much buffering messages to be posted.
This hangs the pipeline unnecessarily and might lead to deadlocks.
Decodebin2's chains store a next_groups list that was being handled as
it could only have a single element. This is true for most of the
chaining streams scenarios where streams change not very often.
In more stressfull changing scenarios, like adaptive streams, those
changes can happen very often, and in short time intervals. This could
confuse decodebin2 as this list was always being used as a single
element list.
This patches makes it handle as a real list, using iteration instead
of picking the first element as the correct one always.
Even if the chain hasn't been 'handled' in this switching round,
report it as drained so upper chains/groups know abou it.
This makes switching happen on upper levels of the groups/chain
trees
The _decode_bin_compare_factories_func() should return negative
value if the rank of both PluginFeatures are equal and the name of
first PluginFeature comes before the second one (== ascending order).
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().
After preroll the multiqueue limits are still set to the preroll
limits if use-buffering is set to TRUE. In that case we only want
time limits on the multiqueue if upstream is seekable.
Such streams were detected as seekable, as the query on the typefind
element was testing the m3u8 file listing the actual streams, and
not going through the demuxer(s).
We now check for seekability for each multiqueue following a demuxer,
so the query will flow through the elements which might prevent seeking.
https://bugzilla.gnome.org/show_bug.cgi?id=647769
This allows us to easily get ahold of all pads on a stream-topology message, including
pre-decoder ones, while "pad" only gives us access to the raw pads (as used by discoverer).
This is made possible by filtering errors. This is required to let
harware accelerated element query the video context. The video context
is used to determine if the HW is capable, and thus if the element is
supported or not.
Fixes bug #662330.
With unfixed caps we can't reliably decide if the final caps
are going to be "raw" (e.g. supported by a sink) or not.
We will get here again later when the caps are fixed.
If subdrained isn't initialized to FALSE then a chain might think
that its group is drained when in fact it's not and this can cause
a switch too early or even cause a deadlock.
g_value_get_object() does not give us our own ref.
Fixes "Trying to dispose object "flacparse", but it still has a parent "registry0".
You need to let the parent manage the object instead of unreffing the object directly."
and similar warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=658416
This is done by adding a capsfilter after every parser/converter that contains
all possible caps supported by downstream elements. A capsfilter is necessary
here because the decoder is only selected after the parser selected a format
and the parser can't know what downstream would support otherwise.
