Otherwise decodebin won't get notified about STREAM_COLLECTION comming
from the sources and thus will never get informored about it. Without
being informed about the stream collection decodebin won't be able to
select any streams. It ends up not creating any output for the streams
defined from outside parserbin.
https://bugzilla.gnome.org/show_bug.cgi?id=795364
Buffering messages are only sent for the active group (in case there
is more than one).
If the inactive group posts buffering messages we keep the last one
around and will post it once it becomes the playing one.
In order to flush out multiqueue, we send again a STREAM_START and
then a EOS event.
The problem was that was that we might end up pushing out on the
output of multiqueue (and therefore decodebin3) a series of:
* EOS / STREAM_START / EOS
Apart from the uglyness of such output, If decodebin3 is used with
elements such as concat on their output, they might potentially
block on that second STREAM_START.
In order to make sure we don't end up in that situation we send
a custom STREAM_START event when refreshing multiqueue (which we
drop on the output) and we don't special case EOS events on streams
on which we already got EOS.
At worst we now end up sending at most two EOS on the output of
multiqueue (and decodebin3).
Similar in vein to the playbin2 architecture except that uridecodebin3
are prerolled much earlier and all streams of the same type are
fed through a 'concat' element.
This keeps the philosphy of having all elements connected as soon
as possible.
The 'about-to-finish' signal is emitted whenever one of the uridecodebin
is about to finish, allowing the users to set the next uri/suburi.
The notion of a group being active has changed. It now means that the
uridecodebin3 has been activated, but doesn't mean it is the one
currently being outputted by the sinks (i.e. curr_group and next_group).
This is done via detecting GST_MESSAGE_STREAM_START emission by playsink
and figuring out which group is really playing.
When the current group changes, a new thread is started to deactivate
the previous one and optionnaly fire 'about-to-finish'.
Apologies for the big commit, but it wasn't really possible to split it
in anything smaller.
* Switch to uridecodebin3 instead of managing urisourcebin and decodebin3
ourselves. No major architectural change with this.
* Reconfigure sinks/outputs when needed. This is possible thanks to the
various streams-related API. Instead of blocking new pads and waiting
for a (fake) no-more-pads to decide what to connect, we instead reconfigure
playsink and the combiners to whatever types are currently selected. All of
this is done in reconfigure_output().
New pads are immediately connected to (combiners and) sinks, allowing
immediate negotiation and usage.
* Since elements are always connected, the "cached-duration" feature is gone
and queries can reach the target elements.
* The auto-plugging related code is currently disabled entirely until
we get the new proper API.
* Store collections at the GstSourceGroup level and not globally
* And more comments a bit everywhere
NOTE: gapless is still not functional, but this opens the way to be able
to handle it in a streams-aware fashion (where several uridecodebin3 can
be active at the same time).
With push-based sources, urisourcebin will emit this signal when
the stream has been fully consumed.
This signal can be used to know when the source is done providing
data.
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
If we are shutting down, don't spawn a cleanup thread to cleanup old
groups and instead queue them to be cleaned up in the state change
thread.
This avoids (hopefully for good) having a race between the state change
thread and other threads trying to deactivate elements/pads.
Deactivating pads from two threads isn't 100% MT-safe. There is a
slim chance that the GstPadActivateFunc might be called twice with
the same values (in this case from the cleanup thread *and* from
the GstElement change_state function when going from PAUSED to READY).
In order to avoid that, call any existing cleanup function *before*
calling the parent change_state implementation on downwards state
changes.
When deactivating pads, we need to ensure that the streaming threads
going through the pads we wish to deactivate can cleanly return.
Failure to do that would result in the streaming locks of those
pads never being released. The end result would be a deadlock
when stopping decodebin2.
In order to avoid that situation, release the "dyn" lock around
the deactivation code. And refactor the code to cope with the
list of blocked pads having potentially changed when re-acquiring
the lock.
We have a dedicated one-shot thread to handle cleanup of old groups.
While this is a good idea. It's an even better idea to make sure
that thread is *completed* before the parsebin element to which
it is related isn't freed/gone.
* There can only be one cleanup thread happening at any point in time.
If there is already one, we wait for the previous one to finish.
* When shutting down (NULL=>READY) make sure the thread is finished
https://bugzilla.gnome.org/show_bug.cgi?id=790007
We have a dedicated one-shot thread to handle cleanup of old groups.
While this is a good idea. It's an even better idea to make sure
that thread is *completed* before the decodebin2 element to which
it is related isn't freed/gone.
* There can only be one cleanup thread happening at any point in time.
If there is already one, we wait for the previous one to finish.
* When shutting down (NULL=>READY) make sure the thread is finished
https://bugzilla.gnome.org/show_bug.cgi?id=790007
Instead of emitting 'drained' whenever every single chain is drained
(which would result in plenty of signal emission, and would also
occur when switching groups), only emit it when the top-level chain
is drained.
Furthermore, mark unknown (and therefore unexposed) pads as drained
since we'll never get EOS on them.
https://bugzilla.gnome.org/show_bug.cgi?id=787367
If we can expose the main chain, recheck whether we are shutting
down or not.
decodebin2 might have been set to READY/NULL during the attempt
to expose, which would cause it to fail ... but it is not a fatal
issue.
By select-streams event, current implementation of decodebin3
supports deactivate output stream (i.e., decoder element)
in reassign slot(), but cannot activate any slot without track change.
https://bugzilla.gnome.org/show_bug.cgi?id=778015
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
Use the intended sequence for re-using elements:
* EOS
* STREAM_START if element is to be re-used
This avoids having elements (such as queue/multiqueue/queue2) not
properly resetting themselves.
When delaying EOS propagation (because we want to wait until all
streams of a group are done for example), we re-trigger them by
first sending the cached STREAM_START and then EOS (which will
cause elements to re-set themselves if needed and accept new
buffers/events).
https://bugzilla.gnome.org/show_bug.cgi?id=785951
It is forwarding messages to the playbin bus, thus forwarding messages
that contain a floating reference to the application. This generally
makes bindings unhappy, we must not leak floating references to them.
Do not remove other parsebin's input streams. It will cause unexpected
removal of any input streams in multi-parsebin use case.
Basically, the purpose of blocking buffers is similar to checking
no-more-pads of chain/group. That is, it gives hint to know the timing
to remove old (EOSed) streams of the parsebin and to add/reuse slots
for new input streams. But, that doesn't mean that we need to remove
other parsebin's EOSed stream. Each parsebin has most likely its
own streaming thread and therefore EOSed time can be much different.
(i.e., much early EOS of subtitle only parsebin)
https://bugzilla.gnome.org/show_bug.cgi?id=785120
Fields related to stream handling (input_streams,
output_streams, slots, guint slot_id) where used totally unprotected
until know.
This lead to several races, especially playing back RTSP streams.
To protect those fields, the OBJECT_LOCK can not be used as we sometimes
need to be able to post message on the bus while holding it.
decodebin3 already has a lock to manage stream selection, and in the end
it makes sense to protect all the stream management fields with the same
lock which is why we reuse the SELECTION_LOCK here.
https://bugzilla.gnome.org/show_bug.cgi?id=784012
decodebin3 checks input streams and pushes EOS if all input streams
are EOSed. If not, fake EOS is pushed to the corresponding slot.
When adaptivedemux is used with multi-track configuration,
adaptivedemux never ever push EOS to non-selected track
because streaming thread for the slot stops with not-linked flow return.
So, decodebin3 should generate EOS itself to finish playback.
https://bugzilla.gnome.org/show_bug.cgi?id=777735
linked input of slot can be old input, so urisourcebin should check
eos state to figure out whether it's new one or not.
If not, urisourcebin never ever forwards EOS to downstream at the end
of presentation, because the old input is still there without removal
https://bugzilla.gnome.org/show_bug.cgi?id=777735
group-id in stream-start event might be updated in
parse_chain_output_probe (). This cause duplicated stream-start
twice with identical stream-id and seq-num, but only group-id is
different. Although there is no change, stream-start event will
be followed by the first buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=771088
This makes it possible for GstDiscoverer to work with sources that
have multiple source pads and hence will trigger the creation of multiple
decodebin instances such as rtspsrc.
Based on the work of Vineeth TM <vineeth.tm@samsung.com>
https://bugzilla.gnome.org/show_bug.cgi?id=754178
And only set low-percent/high-percent if not using downloadbuffer, just
like in old uridecodebin. using the watermark based buffering causes
playback to hang never finish buffering with downloadbuffer.
Those multiqueue are the ones dealing with adaptive demuxers. They should
have a time limit set so that they don't end up buffering too much data.
They would previously be set with no limits at all, which would cause them
to grow indefinitely until downstream blocks.
When a clip has video audio and subtitle, if need send gap event
to audio and subtitle, we should make sure all has been sent, so
need every stream keep one send_gap_event.
https://bugzilla.gnome.org/show_bug.cgi?id=780429
When posting 100% buffering due to removing the last
buffering element, we still need to hold the posting
lock as well, to avoid any race with other elements
that might post a buffering message at that exact
moment
Add locking, and handle EOS properly now that urisourcebin
uses custom events in place of real EOS events, so we
need to manually remove buffering messages and potentially
post 100% in that situation
The expanded 4 second buffering was making radio streams that are
being delivered at real-time speeds too slow. We might need
a better plan for matching the queue2 size to incoming bitrate
in the absence of tag information or timestamping.
In uridecodebin, it used tags on the output of decodebin to
adjust the queue2 buffering, but urisourcebin doesn't have that
view - decodebin is downstream from us.
