Commit graph

414 commits

Author SHA1 Message Date
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
Sreerenj Balachandran
2b0d392741 decodebin: fix the autoplugging of parser elements
If there are two parser elements available for the same media format,
then decodebin is autoplugging an extra capsfilter and parser irrespective
of caps and rank. So restrict the decodebin from autoplugging multiple parser
elements back to back in adjacent positions with in a single DecodeChain
for the same media format.

https://bugzilla.gnome.org/show_bug.cgi?id=738416
2014-10-21 13:32:19 +02:00
Sreerenj Balachandran
a24db77217 decodebin: optimize the code a bit by avoiding unnecessary string comparisons
https://bugzilla.gnome.org/show_bug.cgi?id=738416
2014-10-21 11:05:53 +02:00
Sreerenj Balachandran
f60da86ae2 decodebin: Fix typo in comment
https://bugzilla.gnome.org/show_bug.cgi?id=738416
2014-10-21 11:05:53 +02:00
Andrei Sarakeev
a391dfe17f decodebin: Only emit the drain signal for the main decode chain, not any subchains
https://bugzilla.gnome.org/show_bug.cgi?id=738064
2014-10-07 14:48:54 +03:00
Sebastian Dröge
72eb84a900 decodebin: Free factories array when delaying autoplugging due to non-final caps 2014-10-06 10:15:13 +03:00
Aurélien Zanelli
796fd16550 decodebin: unref decode pad after usage
https://bugzilla.gnome.org/show_bug.cgi?id=737757
2014-10-06 09:53:39 +03:00
Thiago Santos
3657929e1f decodebin: protect buffering message handling
Use the object lock to avoid concurrent processing which leads
to small disasters (assertions or crashes)
2014-09-11 17:16:18 -03:00
Sebastian Dröge
5cbefaa9a2 decodebin: Also include the raw caps in the error message, not just the human readable description 2014-09-02 15:37:38 +03:00
Sebastian Dröge
56899b596e decodebin: Include codec description for missing plugins in the error message
If we had plugins and an error occurred we only include the error message
caused by this, otherwise we will include the codec description as generated
from the caps.

This allows to detect which exact codec was missing instead of getting a
generic "no suitable decoders found" error message.
2014-09-02 13:00:48 +03:00
Sebastian Dröge
a5cf0a4572 decodebin: Include information from the error messages of tried but failed elements in the missing plugin errors 2014-08-25 21:01:16 +03:00
Sebastian Dröge
22a138b716 decodebin: Initialize local variables for every retry 2014-08-25 21:01:16 +03:00
Sebastian Dröge
21e9f84486 decodebin: Remove error case that resulted in two error messages
We already send one in gst_decode_bin_expose() for this case. Only
if we're unable to typefind the caps another error message is needed.
2014-08-25 21:01:16 +03:00
Thiago Santos
14d79a3a47 decodebin: handle group switching for deadend group
Gracefully handle switching groups that all pads are deadend.

This can happen when quickly switching programs on mpegts as the
output is unaligned it can happen that not enough data was accumulated at
parsers to generate any buffers, causing the stream to receive EOS before
any data can be decoded.

To handle this scenario, the _expose function now also gets if there is
any next group to be exposed along with the list of endpads. If there are
no endpads and there is another group to expose it will switch to this next
group and then retry exposing the streams.

Also, the requirement to only switch from the chain that has the endpad had
to be modified to care for when the drainpad is NULL

https://bugzilla.gnome.org/show_bug.cgi?id=733169
2014-08-13 18:51:37 +03:00
Thiago Santos
9c09c8ae17 decodebin: consider all deadend pads as drained
Otherwise when switching out a group with a deadend pad it will block
as it would be waiting for EOS on a deadend that already got one

https://bugzilla.gnome.org/show_bug.cgi?id=733169
2014-08-13 18:51:37 +03:00
Sebastian Dröge
59fb749ef6 decodebin: Remove buffering special casing for adaptive streaming demuxers
They output smaller buffers now and we should be able to handle the buffering
limits like in every other situation now.
2014-08-11 10:57:43 +02:00
Thiago Santos
cf50b45ff6 decodebin: add missing 'time' word to debug message
It prints the buffers, bytes and time limits, but 'time' was missing
from the string.
2014-07-29 15:55:27 -03:00
Sebastian Dröge
f173fa15b1 decodebin: Don't unref caps for which we don't own a reference... get one first
https://bugzilla.gnome.org/show_bug.cgi?id=733615
2014-07-23 19:51:36 +02:00
Sebastian Dröge
b15a47aa19 decodebin: Link Parser/Converter directly and already connect to pad-added and other signals before setting elements to PAUSED
otherwise we're going to
a) start Parser/Converter before they are linked to their capsfilter,
   breaking their negotiation of a proper stream format
b) start demuxers without having connected to their pad-added signals. We
   miss pads and in the worst case don't link any pads at all
2014-07-21 09:35:36 +02:00
Sebastian Dröge
57999c28fd decodebin: Send sticky events to the new element after setting it to PAUSED
... and if this fails for whatever reason we skip the element and instead
try with the next element. This allows us to handle elements that fail
when setting caps on them by just skipping to the next alternative element.
2014-07-21 09:35:36 +02:00
Sebastian Dröge
994680b04e decodebin: Only link elements further after setting them to PAUSED
They might fail to go to PAUSED, and when connecting them further
we might already expose their srcpads on decodebin if we're unlucky.
This prevents us to handle failures going to PAUSED gracefully.
2014-07-21 09:35:36 +02:00
Sebastian Dröge
83d508a552 decodebin: Remove ERROR message filter after we set the element to PAUSED
This allows us to catch more errors gracefully and switch to an alternative
element instead.
2014-07-21 09:35:05 +02:00
Sebastian Dröge
f66555668a decodebin: Only continue autoplugging once the pad has final caps
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.
2014-07-21 09:35:05 +02:00
Sebastian Dröge
424ff91394 decodebin: Consider the caps after the capsfilter after parsers for autoplugging
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.
2014-07-21 09:35:05 +02:00
Sebastian Dröge
393f090197 decodebin: Do async-done on expose errors too 2014-06-04 17:00:43 +02:00
Thiago Santos
783195ccef decodebin: aggregate buffering messages
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
2014-05-29 18:59:30 -03:00
Vincent Penquerc'h
9e99a1ca41 decodebin: consider "no demuxer" case to not have dynamic pads
This fixes a possible NULL dereference.

Coverity 1195146
2014-04-10 13:51:18 +01:00
Sebastian Dröge
2c2e286c38 decodebin: In adaptive streaming mode, only have a fixed buffer limit for the non-buffering multiqueue 2014-04-09 16:06:06 +02:00
Sebastian Dröge
5e364c1d7b decodebin: Buffer up to 5 seconds in multiqueue buffering mode
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.
2014-03-07 17:09:24 +01:00
Sebastian Dröge
539eaf73e5 decodebin: Keep the number of buffers after an adaptive streaming demuxer lower
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.
2014-03-06 22:45:30 +01:00
Sebastian Dröge
274b4eb870 decodebin: Simplify adaptive streaming demuxer code a bit 2014-03-06 22:45:30 +01:00
Sebastian Dröge
2df1e56bb7 decodebin: If we have a demuxer without dynamic srcpads, just assume no-more-pads
Otherwise we will wait until the multiqueue after the demuxer will
overrun, which is clearly not needed then.
2014-02-23 00:10:01 +01:00
Sebastian Dröge
f149c27a61 decodebin: Also make sure to not duplicate an element factory after a group
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.
2014-02-23 00:10:01 +01:00
Sebastian Dröge
41117606dd decodebin: During pre-rolling always use the auto-preroll limits on multiqueues
Even if we're buffering in the multiqueues.
2014-02-23 00:10:01 +01:00
Sebastian Dröge
2d2aa02b77 decodebin: Pass through the seekability information when setting multiqueue limits 2014-02-23 00:10:01 +01:00
Sebastian Dröge
db771185ed decodebin: During exposing of pads don't set the multiqueue limits multiple times to different values
Instead just set them once in the very end to the correct values.
2014-02-23 00:10:01 +01:00
Sebastian Dröge
c4caeb73ce decodebin: Only enable multiqueue buffering once we're pre-rolled
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.
2014-02-23 00:10:01 +01:00
Sebastian Dröge
4f32010916 decodebin: Make sure that we always have a second multiqueue for adaptive streaming demuxers
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.
2014-02-23 00:10:00 +01:00
Alessandro Decina
6a699b6c40 decodebin: make it possible to register multiple handlers for autoplug-select
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
2014-01-28 13:45:07 +11:00
Wim Taymans
a7151d0b3e decodebin2: copy sticky events 2013-11-29 17:26:13 +01:00
Wim Taymans
65e492a403 decodebin2: activate ghost pad before targetting
Activate the decodebin2 pad before setting the target. This makes sure
that the events are copied.
2013-11-28 11:27:23 +01:00
Tim-Philipp Müller
b1ff48c1a1 docs: remove old 0.10 Since markers
They're just confusing.
2013-11-16 16:10:07 +00:00
Sebastian Dröge
c49531f1b7 decodebin: Let serialize queries before caps events through
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.
2013-06-06 15:57:49 +02:00
Sebastian Dröge
14192c031a decodebin: Don't call autoplug-query on shutdown
And remove leftover debug code
2013-05-28 13:32:23 +02:00
Sebastian Dröge
e5064ee723 playbin: Refactor autoplug-query handling
We now only check sinks and factories of the corresponding media
type. It doesn't make sense to pass audio/subtitle caps to a video
decoder.
2013-05-28 13:08:00 +02:00
Sebastian Dröge
d366613401 decodebin: Block on serialized queries too
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.
2013-05-28 13:06:15 +02:00
Sebastian Dröge
9513b770f4 decodebin: Pass the element in the autoplug-query signal too 2013-05-28 12:10:33 +02:00
Sebastian Dröge
730e633d58 decodebin: Need to lock the chain mutex in autoplug_query 2013-05-28 11:40:51 +02:00
Sebastian Dröge
fa7ad8743c decodebin: Lock the state of child elements as long as we manage their states
https://bugzilla.gnome.org/show_bug.cgi?id=690420
2013-05-24 13:41:46 +02:00
Sebastian Dröge
be4dba23ea Revert "decodebin2: use NO_RESYNC flag"
This reverts commit 0feecef275.
2013-05-24 11:47:13 +02:00
Sebastian Dröge
ca1279e4a3 decodebin: Use signal handler IDs instead of disconnecting by function
This is cleaner and faster.
2013-05-22 17:29:17 +02:00
Sebastian Dröge
504e57ccc5 decodebin: Connect and disconnect the have-type signal of typefind before starting/shutting down 2013-05-22 13:49:18 +02:00
Sebastian Dröge
d802c7395a playback: Only do a subset filtering for the factories if we have fixed caps
Otherwise we're plugging a parser/converter currently and have unfixed caps.
2013-05-15 17:15:18 +02:00
Sebastian Dröge
062246fc6e decodebin: Return immediately from checking if a chain is complete if we're shutting down 2013-05-15 14:51:16 +02:00
Sebastian Dröge
83f2476976 decodebin: Hold the expose lock when freeing a chain
https://bugzilla.gnome.org/show_bug.cgi?id=700342
2013-05-15 14:47:53 +02:00
Sebastian Dröge
450a47c0a5 playback: Use subset checks instead of intersection
https://bugzilla.gnome.org/show_bug.cgi?id=700272
2013-05-14 10:07:44 +02:00
Sebastian Dröge
b719dd9f89 decodebin: Expose pads when they receive EOS before any buffers
Stops decodebin from waiting forever to expose a pad if there
is never data on it.

https://bugzilla.gnome.org/show_bug.cgi?id=691072
2013-05-06 15:49:00 +02:00
Wim Taymans
c5840ebbd9 decodebin2: also remove the bytes limit
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.
2013-04-23 11:20:28 -03:00
Wim Taymans
26c5bc1ce4 decodebin2: update buffer size in multiqueue
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.
2013-04-23 11:20:28 -03:00
Thiago Santos
5cd07bd2af decodebin2: only allow 'lower' multiqueues to emit buffering messages
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.
2013-04-23 11:20:28 -03:00
Thiago Santos
6382d4c0ad decodebin2: do not handle the next-groups list as if it was a single item
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.
2013-04-23 10:32:19 -03:00
Thiago Santos
054ffc6e2b decodebin2: preserve next groups order 2013-04-23 10:32:19 -03:00
Thiago Santos
42db7c7b08 decodebin2: still report chain as drained when not 'handled'
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
2013-04-23 10:32:19 -03:00
Sreerenj Balachandran
8cf6049643 decodebin: use _plugin_feature_rank_compare API instead of duplicating the code. 2013-04-18 13:59:36 +02:00
Sreerenj Balachandran
f07eb23728 decodebin: use ascending order for name based sorting of pluginfeatures.
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).
2013-04-15 12:05:16 +02:00
Wim Taymans
92b77c5aa4 decodebin2: forward all sticky events to decodepad
Forward all sticky events to the decodepad before exposing the pads. This makes
sure all sticky events are on the exposed pad.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=696915
2013-04-04 15:00:52 +02:00