Commit graph

379 commits

Author SHA1 Message Date
Sebastian Dröge
60bad4815d Revert "decodebin2: fix deadlock on chain shutdown"
This reverts commit 77dc09c3a9.

It can cause the FLUSH_START/STOP events to go to the sink elements, which
then causes state changes and various other problems. We shouldn't really
flush downstream here, the idea is to do *draining*.

Apart from that the testcase for the original bug here works without this
commit now.
2015-12-16 17:09:25 +01:00
Tim-Philipp Müller
71505dfa24 decodebin2: fix "Attempt to unlock mutex that was not locked"
Introduced in commit ee44337f, caused the decodebin
test_text_plain_streams unit test to abort.

https://bugzilla.gnome.org/show_bug.cgi?id=752651
2015-12-02 18:16:05 +00:00
Sebastian Dröge
9e4bf58b8e decodebin: Update buffering messages when removing an element that had buffering pending
Otherwise we'll remove that element while keeping its buffering message in our
list, and because of that never ever report buffering 100% as that element
will always be at a lower percentage.

This fixes e.g. seeking over Period boundaries in DASH and various other
issues when buffering happens between group switches.

Also use a new mutex for protecting the buffering messages. The object lock is
already used by gst_object_has_as_ancestor() and we need to use it now for
checking if the buffering message sender has the to-be-removed element as
ancestor.
2015-12-02 16:16:22 +02:00
Thomas Bluemel
2c62aad159 [PATCH] Fix a race condition accessing the decode_chain field.
Make sure that any access to the GstDecodeBin's decode_chain
field is protected using the EXPOSE_LOCK.  Also add a simple
reference counter to the GstDecodeChain structure so that when
the type_found signal fires it can hold onto the decode chain
even while the EXPOSE_LOCK is not held.  This should fix a
race condition if the type_found signal fires right in the
middle of a state change that messes with the same decode
chain.

https://bugzilla.gnome.org/show_bug.cgi?id=755260
2015-12-01 17:36:31 +00:00
Vincent Penquerc'h
870c6df489 decodebin: early out on pad-added when the pad is inactive
The pad may be recently deactivated if the element is switched
back down very quickly.

https://bugzilla.gnome.org/show_bug.cgi?id=752651
2015-12-01 17:36:31 +00:00
Vincent Penquerc'h
ee44337fc3 decodebin: lock the expose lock around decode_chain use
Helps with a crash in decodebin when quickly switching states.

https://bugzilla.gnome.org/show_bug.cgi?id=752651
2015-12-01 17:36:31 +00:00
Edward Hervey
d0eface01c decodebin: Properly deactivate ghostpads
Just setting the ghostpad as flushing wasn't enough. It needs to be
consistent on the internal proxypad also, otherwise you end up in
situations where:
* a pending buffer on the target pad triggers the sticky event
  propagation
* the default implementation sees that the proxypad is not flushing,
  so it tries to push it to the other pad (the actual ghostpad)
* the ghostpad is flushing, so returns FALSE
* the push_event function sees that pushing the event failed...
* ... and pending buffer push returns GST_FLOW_ERROR, instead of
  GST_FLOW_FLUSHING

By using gst_pad_set_active(FALSE), we ensure that both the ghostpad
and the proxypad are flushing/deactivated. The situation above will
no longer occur, and a GST_FLOW_FLUSHING will be returned.
2015-11-06 19:38:13 +01:00
Sebastian Dröge
36b80edb72 decodebin: Send SEEK events directly to adaptive streaming demuxers
This makes sure that they will always get SEEK events, even if we're currently
in the middle of a group switch (i.e. switching to another
representation/bitrate/etc).

https://bugzilla.gnome.org/show_bug.cgi?id=606382
2015-10-27 15:50:45 +02:00
Guillaume Desmottes
7d6b6b0313 decodebin: fix event leak
As stated in GST_PAD_PROBE_HANDLED's documentation, we are
supposed to unref the event before returning.

Fixes an event leak in the validate.hls.playback.play_15s.hls_bibbop
validate scenario.

https://bugzilla.gnome.org/show_bug.cgi?id=754459
2015-10-25 11:18:29 +00:00
Matthew Waters
44871680f0 decodebin: track the exposable pads through connect_pad
The logic introduced by
[d50b713: decodebin: set the decode pad target before setting elements to PAUSED]
to expose pads would only ever be able to possibly expose one (the last) pad per element.

Make it so that any exposable pads are able to be exposed rather than just the
last pad returned by connect_element.

https://bugzilla.gnome.org/show_bug.cgi?id=742924
2015-10-20 10:48:05 +03:00
Matthew Waters
94d81fc713 decodebin: return the possibly new chain in analyze_new_pad
In the case of analyzing a demuxer chain, analyze_new_pad may create
a new GstDecodeChain.  This was not propagated to the calling function which as
of [d50b713f decodebin: set the decode pad target before setting elements to PAUSED]
is now required to be able to expose the correct pad.

https://bugzilla.gnome.org/show_bug.cgi?id=742924
2015-10-20 10:47:45 +03:00
Sebastian Dröge
4d6aa0f831 decodebin/playbin/playsink/subtitleoverlay: Post async-done on state change failures
https://bugzilla.gnome.org/show_bug.cgi?id=756611
2015-10-19 11:06:25 +03:00
Matthew Waters
d50b713f44 decodebin: set the decode pad target before setting elements to PAUSED
Otherwise caps and context queries will disappear into nothing and therefore
fail.  With autoplug-query now actually working, users (such as playbin) can
proxy these queries to the selected video sink and be able to select an
more appropriate configuration.

https://bugzilla.gnome.org/show_bug.cgi?id=731204
2015-10-19 11:55:04 +11:00
Rajat Verma
267f4c2bad decodebin: free hidden groups at time of switching groups
hidden groups should be freed at time of switching groups to avoid memory use
from balloning up.

https://bugzilla.gnome.org/show_bug.cgi?id=755770
2015-10-02 17:02:21 +03:00
Sebastian Dröge
2727ca01f5 Revert "decodebin: Handle the preroll multi-queue size"
This reverts commit 5c8ef0ea05.
2015-08-18 18:47:22 +03:00
Sebastian Dröge
4fe4357188 Revert "decodebin: Store extra_buffer_required per group, not globally"
This reverts commit 1ea81114ea.
2015-08-18 18:47:21 +03:00
Sebastian Dröge
970bc16bf8 Revert "decodebin: If extra buffers are going to be required, we're still prerolling"
This reverts commit a3b24f0241.
2015-08-18 18:47:18 +03:00
Sebastian Dröge
a3b24f0241 decodebin: If extra buffers are going to be required, we're still prerolling 2015-08-18 15:19:03 +03:00
Sebastian Dröge
1ea81114ea decodebin: Store extra_buffer_required per group, not globally
It's only relevant for each group, and by storing it in the group
we have locking and everything else like for the other buffering-related
variables. Locking looks a bit fishy still, but it was like that for a long
time already so shouldn't be worse than before.
2015-08-18 15:19:03 +03:00
Myoungsun Lee
5c8ef0ea05 decodebin: Handle the preroll multi-queue size
Overview:
There are some of interleaved streams which has long-term location of audio data.
It mean the audio data is located far away more than multiqueue size.
In this case, because of multiqueue overrun, the pipeline is stopped.
To prevent hanging-like state, the decodebin needs to handle the queue size.

Caused:
The multiqueue size is not enough, the pipeline will stay being stalled status
and decodebin cannot complete to build decode chain.
In this issue file, decodebin did not receive no_more_pads signal or audio data yet.

Steps to Reproduce:
play the high-resolution(4K file) files or some streaming media(push mode).

Actual Results:
There is no audio or subtitle.
We can see only video or infinite loading.

Resolution:
Decodebin detect this problem, and add extra buffer size to multiqueue.
The multiqueue is larger than before, the next data can be pushed the downstream element.

Additional Information:
The max-preroll extra buffer size is set 8MB.
We can use total pre-roll buffer 10MB.
Only first overrun callback can handle multiqueue size.

https://bugzilla.gnome.org/show_bug.cgi?id=733235
2015-08-18 15:19:02 +03:00
Edward Hervey
7fc856ff5c decodebin: Fix list iteration
We were using the wrong variable ...

CID #1316477
2015-08-16 12:53:23 +02:00
Edward Hervey
eaf9ca90c7 decodebin2: Handle flushing with multiple decode groups
When an upstream element wants to flush downstream, we need to take
all chains/groups into consideration.

To that effect, when a FLUSH_START event is seen, after having it
sent downstream we mark all those chains/groups as "drained" (as if
they had seen a EOS event on the endpads).

When a FLUSH_STOP event is received, we check if we need to switch groups.
This is done by checking if there are next groups. If so, we will switch
over to the latest next_group. The actual switch will be done when
that group is blocked.

https://bugzilla.gnome.org/show_bug.cgi?id=606382
2015-08-15 18:50:06 +02:00
Edward Hervey
2d3743e37d decodebin2: Forward event/queries for unlinked groups
When upstream events/queries reach sinkpads of unlinked groups (i.e.
no longer linked to the upstream demuxer), this patch attempts to find
the linked group and forward it upstream of that group.

This is done by adding upstream event/query probes on new group sinkpads
and then:
* Checking if the pad is linked or not (has a peer or not)
* If there is a peer, just let the event/query follow through normally
* If there is no peer, we find a pad to which to proxy it and return
  GST_PROBE_HANDLED if it succeeded (allowing the event/query to be properly
  returned to the initial called)

Note that this is definitely not thread-safe for the time being

https://bugzilla.gnome.org/show_bug.cgi?id=606382
2015-08-15 18:50:06 +02:00
Vineeth TM
0a3fe31f26 decodebin: fix deadend_details string leak
deadend_details need not be returned when the pad is not a deadend.
Hence checking if res value is TRUE and clearing the string instead of
passing it on

https://bugzilla.gnome.org/show_bug.cgi?id=753088
2015-08-05 14:33:35 -03:00
Thiago Santos
9c2e08c54d decodebin: only try to expose complete groups
When switching to a new chain it might be that this new chain
is not yet ready to be exposed so check it before exposing.

Can happen with mpegts that might delay adding pads or pushing data
until it has found the PMT/PAT/PCR and that may take a while depending
on the stream.

It happened frequently with HLS:
http://vevoplaylist-live.hls.adaptive.level3.net/vevo/ch1/appleman.m3u8
2015-07-14 00:11:59 -03:00
Thiago Santos
1d1bebd769 decodebin: fix typo
Hided -> hid
2015-07-14 00:11:59 -03:00
Luis de Bethencourt
df08f5eabe remove unused enum items PROP_LAST
This were probably added to the enums due to cargo cult programming and are
unused. Removing them.
2015-04-24 17:11:01 +01:00
Sebastian Dröge
3570100b66 decodebin: Also log the pointer value of sticky events in debug output
Makes it easier to follow them in the debug logs.
2015-04-08 20:49:39 -07:00
Vincent Penquerc'h
77dc09c3a9 decodebin2: fix deadlock on chain shutdown
When shutting down the chain, we can get a deadlock when removing
a pad, if that chain was being busy streaming but blocked (eg, while
waiting for a queue to have free space).

https://bugzilla.gnome.org/show_bug.cgi?id=746480
2015-04-03 15:42:49 +01:00
Thiago Santos
ceb26dd93d decodebin: improve debug message by printing the object
Print the pad object that EOS'd too early
2015-03-27 09:21:59 -03:00
Duncan Palmer
bf3e35a598 decodebin2: Set multiqueue sizes before use-buffering.
This fixes a race where the use-buffering property on a multiqueue was
set before the queue depth was changed from it's high preroll limits to
lower playback limits. This resulted in buffering messages being emitted
by the multiqueue in the short window between use-buffering being
set and the queue depth being reset.

https://bugzilla.gnome.org/show_bug.cgi?id=744308
2015-03-24 08:17:47 -03:00
Edward Hervey
7813315a4c playback: Fix broken GList modification
When we modify a GList (via g_list_delete_link), always reassign the
new head to the original GList. Otherwise we end up with
filtered_errors being corrupt (the head might have been the element
removed)
2015-02-26 12:08:49 +01:00
Vincent Penquerc'h
561ddabd97 decodebin: fix deadlock when resetting buffering
This function is static, and only ever called with the expose lock
taken. It thus has no reason to take this lock itself.

This was introduced by one of my locking fixes from 741355.

https://bugzilla.gnome.org/show_bug.cgi?id=741355
2015-02-24 16:07:26 +00:00
Luis de Bethencourt
8703d93bbf decodebin: move null check
Check if dbin->decode_chain is NULL before running drain_and_switch_chains()
because if it is, we shouldn't run that function or it will segfault.

CID #1271074
2015-02-23 17:24:56 +00:00
Sebastian Dröge
1dcd1a7479 decodebin: Only consider non-parser factories for generating the post-parser capsfilter caps
Otherwise if there are multiple parsers we would most likely break negotiation
of the stream-format/alignment wanted by the decoders as parsers generally
support all possible stream-formats and alignments.
2015-02-20 12:35:19 +02:00
Vincent Penquerc'h
a2ee84fa80 decodebin: fix deadlock between downward state change and pad addition
If caps on a newly added pad are NULL, analyze_new_pad will try to
acquire the chain lock to add a probe to the pad so the chain can
be built later. This comes from the streaming thread, in response
to headers or other buffers causing this pad to be added, so the
stream lock is taken.

Meanwhile, another thread might be destroying the chain from a
downward state change. This will cause the chain to be freed with
the chain lock taken, and some elements are set to NULL here, which
can include the parser. This causes pad deactivation, which tries
to take the element's pad's stream lock, deadlocking.

Fix this by keeping track of which elements need setting to NULL,
and only do this after the chain lock is released. Only the chain
manipulation needs to be locked, not the elements' state changes.

https://bugzilla.gnome.org/show_bug.cgi?id=741355
2015-02-19 13:38:35 +00:00
Vincent Penquerc'h
a848ac7abe decodebin: guard against the decode chain going while a pad is added
https://bugzilla.gnome.org/show_bug.cgi?id=741355
2015-02-19 13:38:35 +00:00
Vincent Penquerc'h
9036dc8594 decodebin: possible fix for deadlock when spamming "next song"
There was a deadlock between a thread changing decodebin/demuxer
state from PAUSED to READY, and another thread pushing data
when starting.

From the stack trace at
https://bug741355.bugzilla-attachments.gnome.org/attachment.cgi?id=292471,
I deduce the following is happening, though I did not reproduce the
problem so I'm not sure this patch fixes it.

The streaming thread (thread 2 in that stack trace) takes the demuxer's
sink pad's stream lock in gst_ogg_demux_perform_seek_pull and will
activate a new chain. This ends up causing the expose lock being taken
in _pad_added_cb in decodebin.

Meanwhile, a state changed is triggered on thread 1, which takes the
expose lock in decodebin in gst_decode_bin_change_state, then frees
the previous chain, which ends up calling gst_pad_stop_task on the
demuxer's task, which in turn takes the demuxer's sink pad's stream
lock, deadlocking as both threads are now waiting for each other.

https://bugzilla.gnome.org/show_bug.cgi?id=741355
2015-02-19 13:38:29 +00:00
Vincent Penquerc'h
661588b150 dcodebin2: fix lock/unlock mismatch on multiqueue overrun 2015-01-20 15:09:13 +00:00
Sebastian Dröge
2228d9f22b decodebin: Fix compilation 2015-01-17 14:51:48 +01:00
Branislav Katreniak
d16df7f70d decodebin: do call set_queue_size in no_more_pads_cb
Consider pipeline: gst-launch-1.0 playbin uri=http://example.com/a.ogg
Consider 128kbit audio stream.

As soon as uridecodebin detects the bitrate, it configures its input
queue2 max-size to 32000 bytes.
The 2MB buffer in multiqueue is nearly 2 orders of magnitude bigger.
This non-deterministically drives queue2 buffer anywhere from
100% to 0% until multiqueue is filled.

This patch sets multiqueue size to 5 buffers early in no_more_pads_cb.

Partly reverts commit db771185ed.

https://bugzilla.gnome.org/show_bug.cgi?id=740689
2015-01-16 20:58:40 +01:00
Vincent Penquerc'h
6ab711f3f1 decodebin: free old groups when switching groups
Old groups are freed with one switch's delay when switching groups.
They're freed in a scratch thread to avoid delaying the switch.
2015-01-16 15:55:10 +00:00
Thiago Santos
a5ed7afb4c decodebin: disable pad link checks as it has already been done
Decodebin has already added the element to the bin and should only
select caps compatible pads. It should disable the pad link checks
to avoid doing those again.

https://bugzilla.gnome.org/show_bug.cgi?id=742885
2015-01-14 10:33:52 -03:00
Sebastian Dröge
6521870077 Revert "decodebin: Only emit the drain signal for the main decode chain, not any subchains"
This reverts commit a391dfe17f.

It breaks gapless playback: https://bugzilla.gnome.org/show_bug.cgi?id=740045
2014-12-15 09:46:13 +01:00
Sebastian Dröge
90eb93c2ef Don't compare booleans for equality to TRUE and FALSE
TRUE is 1, but every other non-zero value is also considered true. Comparing
for equality with TRUE would only consider 1 but not the others.
2014-12-01 09:51:12 +01:00
Thibault Saunier
35f6259b24 decodebin: Analyze source pad before setting to PAUSED for 'simple demuxers'
Before we were setting them to PAUSED and (much) later connecting to
their source pad caps notify signal.

There was a race where that demuxer was pushing a caps and later a buffer
on its source pad when we were not even connected to its source pad caps notify
signal leading to decodebin missing the information and not keeping on
building the pipeline on CAPS event thus the demuxer was posting an ERROR
(not linked) message on the bus. This need to be done for 'simple
demuxers' because those have one ALWAYS source pad, not like usual demuxers
that have several dynamic source pads.

A "simple demuxer" is a demuxer that has one and only one ALWAYS source
pad.

https://bugzilla.gnome.org/show_bug.cgi?id=740693
2014-11-26 19:38:48 +01:00
Mathieu Duponchelle
68edf0ebd6 decodebin2: Take STREAM_LOCK before sending sticky events.
There was a race where:

1) we would put the element to PAUSED
2) It would get data sent to it from upstream
3) It would thus send caps
3) caps_notify_cb would continue autoplugging
4) caps would flow downstream, the last pad would get exposed
5) we were still not done sending the sticky events

Taking the stream lock on the new element's sinkpad and only
releasing it when sticky events have all been sent prevents
the caps from reaching the source pad of the element before
we're all set.

https://bugzilla.gnome.org/show_bug.cgi?id=740694
2014-11-26 19:38:48 +01:00
Sebastian Dröge
8b8b8ae2e8 Revert "decodebin: fix the autoplugging of parser elements"
This reverts commit 2b0d392741.

This breaks cases where an actual second parser is required after the parser,
e.g. to do timestamp corrections.

See https://bugzilla.gnome.org/show_bug.cgi?id=738416
2014-10-26 11:04:47 +01:00
Sebastian Dröge
2da56de19f Revert "decodebin: Fix locking"
This reverts commit aa94d5dc9a.
2014-10-26 11:04:38 +01:00
Sebastian Dröge
aa94d5dc9a decodebin: Fix locking
The chain mutex needs to be locked when looking at chain->elements. Move code
around a bit to require only one lock() and unlock().
2014-10-21 13:32:19 +02:00