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).
subtitleoverlay handles any caps, not just the ones
for which a subtitle parser/renderer exist. It will
just ignore any unsupported streams instead of causing
an error.
https://bugzilla.gnome.org/show_bug.cgi?id=688476
Add all the caps that we can convert to to the filter caps,
otherwise downstream might just return EMPTY caps because
it doesn't handle the filter caps but we could still convert
to these caps, causing us to return EMPTY caps although
conversion would be possible.
https://bugzilla.gnome.org/show_bug.cgi?id=688803
When the input buffers for a stream don't have a duration set,
timestamp_end might still be GST_CLOCK_TIME_NONE. When advancing
EOSed streams via GAP events (with other streams not yet EOS), we
would then use the invalid timestamp_end to calculate the duration
of the gap. This in turn would make baseaudiosink abort, because it
would try to allocate memory for a trizillion samples.
So if buffers don't have a duration set, assume a duration of
one second for stream catch-up purposes, just so we can still
continue to catch up in those cases. And make sure that
timestamp_end is valid before doing calculations with it.
http://bugzilla.gnome.org/show_bug.cgi?id=678530
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
streams with non-TIME segments will not have timestamps ...
... and therefore will never unblock the other streams.
Fixes blocking issue when using playbin suburi feature
* Update outgoing segment.base with accumulated time, ensuring all
streams are synchronized.
* Only consider streams as "new" is they have a STREAM_START event
with a different seqnum.
* Use GstStream segment.base instead of separate variable to store
the past running time.
* Disable passthrough
* Switch to glib 2.32 GMutex/GCond
* Avoid getting pad parent the expensive way
* Minor other fixes
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.
Might just be paranoia, but better safe than sorry. Make sure
the compiler really always passes a 64-bit integer to the
g_object_set() vararg function.
They are not added again by every code path, e.g. when switching
only the deinterlace flag and are missing then.
Fixes bug #678763.
Conflicts:
gst/playback/gstplaysink.c
...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.
This avoids that bin being leftover and being found when reusing playbin2,
and fixes restarting on a new URI after failing to activate with a previous
URI.
https://bugzilla.gnome.org/show_bug.cgi?id=673888
For audio/video we should flush too for fastest stream switches but this
currently isn't possible because the flushes would need to go to the sink,
which then causes state changes and causes all timing information to be
changed.
Should work out of the box in 0.11 with the flush-stop that doesn't reset
the times.
Conflicts:
gst/playback/gstplaybin2.c
gst/playback/gstplaysink.c
gst/playback/gstsubtitleoverlay.c
Sending a non-flushing seek might not be enough for switching
to an external sub that has already been used because the flushes
are needed to reset the state of its decodebin's queue.
For example, if the subtitle is short enough, the queue might get
and EOS and keep its 'unexpected' return state. If the user switches
to another subtitle and back to the external one, the buffers
won't get past the queue.
This patch fixes this by adding the flush flag to the seek and
preventing that this flush leaves the suburidecodebin.
https://bugzilla.gnome.org/show_bug.cgi?id=638168
Conflicts:
gst/playback/gstplaybin2.c
Make the uri property getter return the next uri, like it was configured in the
setter.
Make a new current-uri and current-suburi property that reflects the currently
playing uri and suburi.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=676665
This makes sure that we always prefer sinks that support a format without
decoding, independant of its rank. Previously we only sorted by rank.
Conflicts:
gst/playback/gstplaybin2.c
If a property is not found (for example last-sample when
gst_debug_bin_to_dot_file is used while the pipeline is
slightly broken (thus no last-sample) the unref of the item
gvalue which is not refed fails. Only unref if it was found.
The sinkpads are unblocked when going from PAUSED->READY, we need to block them
again when going READY->PAUSED. The blocking of the pad previously only happened
when it was freshly obtained with _request_pad or when the caps changed. If we
don't release the pad when going to READY it was previously never blocked again
causing not-linked errors.
For streaming sources a queue is added before the demuxer, which can not be
properly filled by live sources. As http source can be live sources, this
caused issues for example with http live sources.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=674057
Adds a property for playsink to define how it should handle
events sent in send_event function. The default is the same as
GstBin's, sending events to all internal sinks. There is also
mode-first, that will send to sinks until the one handles the
event successfully.
https://bugzilla.gnome.org/show_bug.cgi?id=673211
When the video sink is a fakesink, which does not implement the
navigation interface, playsink will drop the navigation command.
In this case, send to the video sink as a fallback. It breaks
the interface abstraction, but is better than just dropping the
navigation event.
We need to call the default query handler of the proxy pad because only that one
will forward the query to the target pad in case of the allocation query.
After a PAUSED->READY change the sink pads are currently not set to
blocking state. When the element is set back to PAUSED, the change will
be done asynchronously, but as the _pad_blocked_cb() callback is now not
called, the state change never completes.
Fix that by setting the sink pads to blocking state on a PAUSED->READY
change, which ensures that the _pad_blocked_cb() is called when needed
on any future READY->PAUSED change. The sink pads are already put to
blocking state on NULL->READY change, so this behavior is consistent.
Fixes bug #668097.
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.
