If the caps query returned us fixed caps this doesn't mean yet
that these caps are actually complete (fields might be missing).
It allows to do us some decisions, but the selection of the next
element should be delayed as only complete caps allow proper selection
of the next element.
Otherwise we might try to continue autoplugging e.g. for a specific
stream-format although the parser could convert to something else, thus giving
us potentially less options for decoders.
We can't convert to ANY capsfeatures, they are only there so that we
can passthrough whatever downstream can support... but we definitely
don't want to return them to upstream.
When playing RTSP streams there will be one decodebin per stream. If some of
them fail because of a missing plugin we should not fail completely but play
the supported streams at least.
https://bugzilla.gnome.org/show_bug.cgi?id=730868
Aggregate buffering messages to only post the lower value
to avoid setting pipeline to playing while any multiqueue
is still buffering.
There are 3 scenarios where the entries should be removed from
the list:
1) When decodebin is set to READY
2) When an element posts a 100% buffering (already implemented)
3) When a multiqueue is removed from decodebin.
For item 3 we don't need to handle it because this should only
happen when either 1 is hapenning or when it is playing a
chained file, for which number 2 should have happened for the
previous stream to finish
https://bugzilla.gnome.org/show_bug.cgi?id=726423
Otherwise we might end up inside the callback without having stored
the probe id... then try to remove that probe (not!) from the callback
and wait forever for the pad to unblock.
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
This provides an audio-filter and video-filter property to allow
applications to set filter elements/bins. The idea is that these will
e
applied if possible -- for non-raw sinks, the filters will be skipped.
If the application wishes to force the application of the filters, this
can be done by setting the new flag introduced on playsink -
GST_PLAY_FLAG_FORCE_FILTERS.
https://bugzilla.gnome.org/show_bug.cgi?id=679031
This provides an audio-filter and video-filter property to allow
applications to set filter elements/bins. The idea is that these will be
applied if possible -- for non-raw sinks, the filters will be skipped.
If the application wishes to force the application of the filters, this
can be done by setting the new flag introduced on playsink -
GST_PLAY_FLAG_FORCE_FILTERS.
https://bugzilla.gnome.org/show_bug.cgi?id=679031
2 seconds might be too small for some container formats, e.g.
MPEGTS with some video codec and AAC/ADTS audio with 700ms
long buffers. The video branch of multiqueue can run full while
the audio branch is completely empty, especially because there
are usually more queues downstream on the audio branch.
Usually these buffers are multiple seconds large, and having a maximum
of 5 buffers in the multiqueue there can use a lot of memory. Lower
this to 2 for adaptive streaming demuxers.
If we have the peer caps and a caps filter, return peer_caps +
intersect_first (filter, converter_caps) instead of
intersect_first (filter, peer_caps + converter_caps) and preservers
downstream caps preference order.
https://bugzilla.gnome.org/show_bug.cgi?id=724893
If we are using an adaptive stream demuxer, which outputs a non-container
stream, we are putting another multiqueue after the *parser* following
the adaptive stream demuxer. We do not want to add another instance of
the same parser right after this multiqueue.
Otherwise we will emit buffering messages not just from the last
multiqueue but also from previous multiqueues... confusing the
application with different percentages during pre-rolling.
For adaptive streaming demuxer we insert a multiqueue after
this demuxer. This multiqueue will get one fragment per buffer.
Now for the case where we have a container stream inside these
buffers, another demuxer will be plugged and after this second
demuxer there will be a second multiqueue. This second multiqueue
will get smaller buffers and will be the one emitting buffering
messages.
If we don't have a container stream inside the fragment buffers,
we'll insert a multiqueue below right after the next element after
the adaptive streaming demuxer. This is going to be a parser or
decoder, and will output smaller buffers.
Adaptive streams should download its data inside the demuxer, so
we want to use multiqueue's buffering messages to control the
pipeline flow and avoid losing sync if download rates are low;
https://bugzilla.gnome.org/show_bug.cgi?id=707636
Otherwise there's an interesting race condition when we destroy
the inputselector (actually it will be destroyed later when its state
change message gets destroyed) and afterwards release its sinkpad.
This is the code path when the last channel is removed from the
input selector.
Gave this warning sometimes, for chained oggs or whenever else
we change decode groups:
GStreamer-CRITICAL **: Padname '':sink_0 does not belong to element inputselector0 when removing
If the text pads does not go away we just set the overlay to silent, which
allows us to immediately re-enable subs later again. However before this
change we also released the streamsynchronizer text pads, which deadlocked
because there was still dataflow going on. Just do this only if we remove
the complete chain.
https://bugzilla.gnome.org/show_bug.cgi?id=683504
Change the way autoplug-select is accumulated so that it's possible to have
multiple handlers. The handlers keep getting called as long as they keep
returning GST_AUTOPLUG_SELECT_TRY.
One practical example of when this is needed is when hooking into playbin's
uridecodebin, which is perhaps not very elegant but the only way to influence
which streams playbin autoplugs/exposes.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=723096
Discussion on IRC indicated that the main reason for this list was to
prevent demuxers that can trigger a lot of seeking from using
progressive buffering using queue2 (which due to being seekable triggers
that behaviour).
However given that upstream can indicate seeks are possible but should
be avoided via a scheduling query, this extra whitelisting shouldn't be
necessary for well-behaved demuxers.
https://bugzilla.gnome.org/show_bug.cgi?id=704933
If a pipeline fails to preroll, it might happen that the sinks are
put into READY state from playbin's sink activation, but they are never
set to playsink, so they aren't being managed by a GstBin and will keep
their READY state until they are unreffed, leading to a warning.
Prevent this by always forcing them to NULL when deactivating a group
https://bugzilla.gnome.org/show_bug.cgi?id=708789
Otherwise we will remove the bus that would proxy messages to playsink
and never set it again. If the sink is already in playsink, all failures
are fatal anyway as it's either a sink that worked before or one that
was set by the user.
https://bugzilla.gnome.org/show_bug.cgi?id=701997
playbin will now only activate the sinks in a single place and
will never change the states of any sinks that are owned by
playsink.
Also handle text-sinks the same way as audio/video sinks inside
playbin.
This makes sure the application gets any context related messages and
can do whatever is required to a) get the sink a context or b) share
the context with other elements in the pipeline.
The proxying is necessary because the sink is not a child element of
playbin, but instead will at a later point be a child of some bin
inside playsink.
https://bugzilla.gnome.org/show_bug.cgi?id=700967
Otherwise we're going to deadlock forever because no autoplugging
happens without having caps, but caps can never be send because
we're blocking.
Serialized queries before caps should never be sent unless really
necessary.
We found a case where untranslated values were being passed from the
proxy to the underlying channel, causing bad color balance values
in some setups.
Thanks to Sebastian Dröge for clarifying how the code works, and
suggesting the fix.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=701202
This allows to chose something else than input-selector
for multiple audio/video/text streams, e.g. an adder could
be used for audio.
It is needed for example to implement some of the more
advanced HTML5 video features.
https://bugzilla.gnome.org/show_bug.cgi?id=698851
Add the actual decoder/parser/etc caps at the very end to
make sure we don't cause empty caps to be returned, e.g.
if a parser asks us but a decoder is required after it
because no sink can handle the format directly.
Otherwise we will only block after the serialized, non-sticky event
after the CAPS event or the first buffer. If we're waiting for another
pad to finish autoplugging after we got final caps on this pad, it
will mean that we will let the ALLOCATION query pass although the
pad is not exposed yet.
Otherwise we accumulate more and more queue2 elements, and let each
of them start a thread doing nothing but waiting each time uridecodebin
goes to PAUSED.
https://bugzilla.gnome.org/show_bug.cgi?id=699794
This makes it possible to take advantage of the O(log n) lookups
of GSequence on the ~1000 element lists and only do iterations
on <10 element lists. Previously the code iterated over ~1000 element
lists multiple times.
Autoplug the decoder elements and sink elements based on
the number of common capsfeatures if the ranks are the same.
This will also helps to autoplug the h/w_decoder and h/w_renderer.
https://bugzilla.gnome.org/show_bug.cgi?id=698712
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
If a source element could be created for a URI, but all elements rejected
the URI for some reason, propagate the error from the URI handler instead
of reporting a 'no uri handler found for protocol xyz' error, which is
confusing. Fixes error reporting with dvb:// URIs when the channel config
file could not be found or not be parsed or the channel isn't listed.
https://bugzilla.gnome.org/show_bug.cgi?id=678892
Use a scheduling query to check if the source element has some
bandwidth limitations. If this is the case on-disk buffering might be
used. If the source element doesn't handle the scheduling query then
fallback to checking the URI protocol against the hardcoded list of
protocols known to handle buffering already.
Fixes bug 693484.
The 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).
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).
