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.
Probe for MultiQueue source pad might receive EOS twice,
the first is fake-eos and the other is actual EOS.
And the slot can be freed with fake-eos/EOS if the slot has no input.
Since slot freeing is async, double free can be possible.
So, decodebin3 needs to remove the probe also with slot freeing.
https://bugzilla.gnome.org/show_bug.cgi?id=777530
"requested_selection" list might be generated by select-streams event.
And memory of stream-id(s) in select-streams is independent from that of stream-collection.
https://bugzilla.gnome.org/show_bug.cgi?id=775553
When the decodebin state change fails because of an error
message, we might not go through PAUSED->READY. Don't leak
a ref to decodebin pads due to pad blocking in that case.
This is because we return ASYNC going to PAUSED, and if
we fail before reaching PAUSED the only transition we'll
see is READY->NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=775893
The state of urisourcebin (and all elements contained within) can
change at any point in time, including when setting up the typefind
element.
In order to avoid ending up with typefind starting without being fully
connected, lock the state and connect to the 'have-type' signal.
Due to the special nature of adaptivedemux, reconfigure happens
frequently with seek/track-change.
In very exceptional cases, the following sequence is possible:
* EOS event is pushed to queue element and still buffers are queued
* During draining remaining buffers, reconfiguration downstream
happens due to track switch.
* The queue gets a not-linked flow return from downstream
* Because the sinkpad is EOS, the queue registers an
error on the bus, causing the pipeline to fail.
Avoid the sinkpad getting marked EOS in the first place, by using a
custom event in place of EOS.
https://bugzilla.gnome.org/show_bug.cgi?id=777009
When shutting down decodebin2 and parsebin, they set their
output pads to flushing, and there is a very small window
where elements might send a sticky event such as a tag event
(which silently fails due to flushing) and then sends a buffer,
and the buffer will return GST_FLOW_ERROR because it can't
forward sticky events. The element will then send an error
message on the bus. This can also happen when elements send EOS
just as shutdown is happening. Since we're about to destroy all
the elements inside parsebin and decodebin anyway, just discard
error messages from them.
A nicer but more difficult fix for GStreamer 2.0 is to make
all event pushing / handling in core return a GstFlowReturn
like buffers do, so we can report a FLUSHING state cleanly.
When plugging and then exposing a parser, don't fail
if it fails to send sticky events. The most likely
reason is that things were flushed due to the app
immediately doing a seek, but we can't detect flushing
separately to other error conditions without a
gst_pad_send_event_full() core function that returns
a GstFlowReturn.
There are cases when there is no demuxer involved that could do the
buffering, e.g. HLS with raw MP3 or AAC. In this case we want to place
the buffering multiqueue after the parser.
Before this change, we've considered the first element after the
adaptive streaming demuxer as a parser. This is not always true, e.g.
id3demux. Instead we now wait until we actually have a parser (or
decoder).
Fixes playback on such HLS streams.
Playbin3 takes lock when querying duration and handling
stream-collection message. So,to post stream-collection message,
duration query should be dropped when input pad is being unlinked.
https://bugzilla.gnome.org/show_bug.cgi?id=773341
We have to calculate from the segment.stop, not the segment.start, as
playback goes from stop to start. This fix works around another race
condition in streamsynchronizer in my testcase.
See https://bugzilla.gnome.org/show_bug.cgi?id=771479
When connecting a demuxer through a multiqueue ensure to copy sticky
events in order to allow the following factory being properly
checked that it is functional.
https://bugzilla.gnome.org/show_bug.cgi?id=769580
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
When processing EOS for a pad, send a stream-group-done
for the pad in case downstream is waiting for more
data on this stream before it can process related
streams from the group.
https://bugzilla.gnome.org/show_bug.cgi?id=768995
My collection leak fix 83f30627cd
introduced a crash in this scenario: audiotestsrc ! decodebin3 ! fakesink
The reference handling of collection in decodebin3 wasn't very clear and
my attempt to fix the leak introduced a regression where we went one
reference short in some other scenarios.
Fixing this by:
- Giving a strong reference to DecodebinInput making things clearer
- Fixing get_merged_collection() which was sometimes returning an
existing reference and sometimes a new one.
https://bugzilla.gnome.org/show_bug.cgi?id=769080
The collection owned by GstDecodebin3 has to be unreffed when disposing.
gst_event_new_stream_collection() doesn't consume the collection passed
to it so no need to give it an extra ref.
https://bugzilla.gnome.org/show_bug.cgi?id=768811
MultiQueueSlot owns a ref on the active stream so it should release it
when being freed.
DecodebinInputStream owns ref on the active and pending stream so they
should be dropped when being freed.
https://bugzilla.gnome.org/show_bug.cgi?id=768811
gst_stream_get_caps() returns a reffed caps.
The caps passed to gst_query_set_caps_result() are not transfered.
The caps in gst_parse_pad_stream_start_event() was either acquired
using gst_pad_get_current_caps() which returns a new ref or
explicitly reffed.
https://bugzilla.gnome.org/show_bug.cgi?id=768811
With contributions from Jan Schmidt <jan@centricular.com>
* decodebin3 and playbin3 have the same purpose as the decodebin and
playbin elements, except make usage of more 1.x features and the new
GstStream API. This allows them to be more memory/cpu efficient.
* parsebin is a new element that demuxers/depayloads/parses an incoming
stream and exposes elementary streams. It is used by decodebin3.
It also automatically creates GstStream and GstStreamCollection for
elements that don't natively create them and sends the corresponding
events and messages
* Any application using playbin can use playbin3 by setting the env
variable USE_PLAYBIN3=1 without reconfiguration/recompilation.
We take a ref before removing which was never freeded.
The element is still alive anyway because the group has its own ref as
well.
Fix a leak with the 'test_suburi_error_wrongproto' test.
https://bugzilla.gnome.org/show_bug.cgi?id=766515
When we initialize an element in decodebin, we 1) set it to PAUSED and
push sticky events on its sinkpad to trigger negotiation 2) block its
src pad(s) to detect CAPS events. We can't block before 1) as that
would lead to a deadlock.
It's possible (and common) tho that an element configures its srcpad
during 1) and before 2). Therefore before this change we would
typically block and expose an element's pad only once the element
output its first buffer, triggering sticky events to be resent. One
consequence of this behaviour is that it sometimes broke
renegotiation.
With this change now we consider a pad ready to be exposed when it's
->blocked or has fixed caps (which were set before we could block it).
https://bugzilla.gnome.org/show_bug.cgi?id=765456
If we are configured to use buffering and there is no demuxer in the chain, we
still want a multiqueue, otherwise we will ignore the use-buffering property.
In that case, we will insert a multiqueue after the parser or decoder - not
elsewhere, otherwise we won't have timestamps.
https://bugzilla.gnome.org/show_bug.cgi?id=764948
When blocking the subtitle pad, it's expected that stream-start
is the first event, and that it can precede caps arriving on the
peer pad - in fact the caps can only have arrived on the peer
pad when it was pre-primed with sticky events previously.
Instead, just pass the stream-start and don't block, because
stream-start is sticky anyway.
There's a small window between decodebin choosing a buffering level
to post and another thread choosing a different buffering level
where things can race. Close that window by holding a new lock
that's only for posting buffering messages - like what was done
in multiqueue.
https://bugzilla.gnome.org/show_bug.cgi?id=764020
In check_upstream_seekable function, it returns FALSE value even though
we already declare about the seekable variable. So, This patch return
result of seekable in check_upstream_seekable function.
https://bugzilla.gnome.org/show_bug.cgi?id=763975
Due to transient locked state during autoplugging, some elements might be
ignored by the GstBin::change_state() and might still be running. Which could
then cause pad-added and similar accessing decodebin state that does not exist
anymore, and crash.
https://bugzilla.gnome.org/show_bug.cgi?id=763625
In other places we lock it the other way around, leading to possible
deadlocks. Also this will deadlock if analyze_pad() causes a new element to be
autoplugged that adds new pads on itself when its state is changed.
https://bugzilla.gnome.org/show_bug.cgi?id=763491
This reverts commit 0615794300.
deinterlace was ported at some point in the last 4 years and has better video
format support, and especially better negotiation than avdeinterlace. Having
avdeinterlace but not deinterlace causes various problems in zerocopy
scenarios.
https://bugzilla.gnome.org/show_bug.cgi?id=760553
When getting caps of the decode chain, in get_topology, the caps are being
checked if fixed or not. But get_topology will be called when the decode is
chain is being exposed and hence it will always be fixed. Hence removing the
check for fixed caps. Removing gst_pad_get_current_caps for the chain->pad, as
get_pad_caps will again call the same api.
And get_topology can return NULL value if currently shutting down the
pipeline, which on being passed to create message will result in assertion
error. Check if topology is valid before using it
https://bugzilla.gnome.org/show_bug.cgi?id=755918
analyze_new_pad() can return a new decode chain, which might have a new
GstDecodePad in the end. We should use those two for expose_pad() and not the
original ones that were passed to analyze_new_pad().
This fails when having a demuxer element that has raw pads immediately or
if a decoder with raw caps is after an adaptive demuxer.
https://bugzilla.gnome.org/show_bug.cgi?id=760949
[..] when resetting group start time. In GES, we are usually connected
to the streamsynchronizer on one audio and one video pad.
When seeking the timeline, both nlecompositions often output their flush_start
before any of them has output its flush_stop.
The current code, when receiving the first flush stop was using the
running time of the start of the second composition, which could
be pretty much anything, and means nothing at that point.
This patch is thread-safe, as STREAM_SYNCHRONIZER_LOCK is taken
both when setting flushing and when checking it.
https://bugzilla.gnome.org/show_bug.cgi?id=750013
When blocking input pads, we also need to properly set the appropriate
pending flag.
Without this, when switching stream types after initial configuration
(like going from Audio+Video to Audio+Video+Sub) playsink would never
wait for *all* input streams to be blocked (it would just wait for the
new input pad (text in this case) to be blocked).
Since the reconfiguration might introduce unlinking/relinking of elements,
we need to ensure that *ALL* input streams are blocked.
Failure to do so would result in having some input streams pushing data
to inactive elements (returning GST_FLOW_FLUSHING) or unlinked pads
(returning GST_FLOW_NOT_LINKED).
A later optimization could involve only blocking the input pads that
might be involved in reconfiguration. But better be safe than sorry for
now :)
