Commit graph

1733 commits

Author SHA1 Message Date
Sebastian Rasmussen
1479aba1cf tests/filesrc: Set location in wrong state
Also remove incorrect comment about code possibly not being reachable
that is now exercised by the filesrc unit test.

https://bugzilla.gnome.org/show_bug.cgi?id=709831
2013-10-13 12:18:57 -04:00
Sebastian Dröge
02a4830096 Revert "Potential GstContext regression"
This reverts commit e658379534.

This test commit should've never been pushed. Oops.
2013-09-24 12:47:52 +02:00
Alex Ashley
e658379534 Potential GstContext regression
Since the refactoring of GstContext (commits
qc9fa2771b508e9aaeecc700e66e958190476f,
a7f5dc8b8a,
690326f906dc82e41ea58b81cdb2e3e88b754,
d367dc1b0d4ecb37f4d27267e03d7bf0c6c06a6, and
82d158aed3f2e8545e1e7d35085085ff58f18) I am no longer able to get
a shared context for an element that is used twice in a pipeline.

I used the documentation and eglglessink as my reference for
implementing the GstContext logic.

As the code was tied to a hardware decoder, I have ported the
GstContext code to fakesink to show the problem. Using the old
API a single ExampleMgr instance is created, but using the new
API each element is creating its own instance.
2013-09-24 12:28:55 +02:00
Sebastian Dröge
b25b9ad6bd queue2: Only update current level if we already downloaded a range
Otherwise queue->level is NULL and dereferencing that is not a good
idea in general.

https://bugzilla.gnome.org/show_bug.cgi?id=707648
2013-09-10 10:15:03 +02:00
Gustavo Noronha Silva
4cb596ddd6 Update the buffering state before stalling for more data
In some cases the wait for more data was happening without updating
the buffering state, meaning the API user would not be able to notice
it should pause the pipeline and update UI to indicate that is the
case, the video would likely stutter instead.

https://bugzilla.gnome.org/show_bug.cgi?id=707648
2013-09-09 14:15:09 +02:00
Sebastian Dröge
631421b8af typefind: Add missing break after handling the GAP event
Thanks to Edward Hervey for noticing.
2013-09-04 14:42:38 +02:00
Matej Knopp
7f657358a8 multiqueue: Don't reduce single queue visible size below its current level
If the multiqueue has automatically grown chances are good that
we will cause the pipeline to starve if the maximum level is reduced
below that automatically grown size.

https://bugzilla.gnome.org/show_bug.cgi?id=707156
2013-09-04 10:52:13 +02:00
Sebastian Dröge
8ba5fb0b28 outputselector: Don't adjust segment->start to the current time when switching pads
This does not make any sense at all and breaks timestamp->running_time
calculations in unpredictable ways.

https://bugzilla.gnome.org/show_bug.cgi?id=707130
2013-09-02 13:55:08 +02:00
Mathieu Duponchelle
76b5278f7c capsfilter: Delete link directly in pending_events.
When removing a segment event.

https://bugzilla.gnome.org/show_bug.cgi?id=707088
2013-08-30 14:56:17 -04:00
Alessandro Decina
a2bc789de6 filesink: please gcc (avoid a warn_unused_result warning) 2013-08-27 09:31:22 +02:00
Alessandro Decina
924acf5e92 filesink: flush (discard data) on FLUSH_STOP
Reset the write position to 0 and truncate the file on FLUSH_STOP.
2013-08-27 08:00:09 +02:00
Sebastian Dröge
14f817d723 queue: Properly unlock the sinkpad streaming thread when deactivating the pad
https://bugzilla.gnome.org/show_bug.cgi?id=705835
2013-08-20 10:16:41 +02:00
Sebastian Dröge
52f2345516 queue2: Properly unlock the sinkpad streaming thread when deactivating the pad
https://bugzilla.gnome.org/show_bug.cgi?id=706360
2013-08-20 10:16:05 +02:00
Sebastian Dröge
b40599f6db multiqueue: Clean up after the streaming thread has stopped
https://bugzilla.gnome.org/show_bug.cgi?id=705835
2013-08-19 16:38:50 +02:00
Sebastian Dröge
d7c3be226c queue2: Clean up after the streaming thread has stopped
https://bugzilla.gnome.org/show_bug.cgi?id=705835
2013-08-19 16:38:40 +02:00
Sebastian Dröge
ec1dd125c7 queue: Clean up after the streaming thread has stopped
https://bugzilla.gnome.org/show_bug.cgi?id=705835
2013-08-19 16:38:16 +02:00
Tim-Philipp Müller
6b4bef214b queue2: don't crash on EOS if queue is empty
Fixes spurious crash in test_simple_shutdown_while_running
unit test.
2013-08-16 16:53:29 +01:00
Tim-Philipp Müller
c02081ca30 queue2: don't change global buffering state from within query handler
When a buffering query is handled it uses the get_buffering_percent()
function to get some statitics. Unfortunately this function also
calculates whether the queue should be buffering and adapts the
global queue2 state in case of state transitions from/to buffering
(including whether a buffering message was posted on the bus!).

This means that there is a race which can cause buffering messages
to never posted if the global state changes happen as a result of aa
query instead of resulting from bytes flowing in/out.

Spotted by Sjoerd Simons.

Change to only query state in get_buffering_percent() and update
state only in update_buffering().

https://bugzilla.gnome.org/show_bug.cgi?id=705332
2013-08-16 16:53:03 +01:00
Wim Taymans
d7a98f9802 queue2: update buffering when changing capacity
When the capacity of the queue changes, make sure we post an updated buffering
message because we might suddenly have completed the buffering stage.
2013-08-16 12:57:17 +02:00
Sjoerd Simons
0b06804735 queue2: Fix backwards seeks into undowloaded ranges
When in download buffering mode queue2 didn't check if a range offset is
in a undownloaded range before the currently in-progress range. Causing
seeks to an earlier offset to, well, take a while.
2013-07-31 09:50:47 +02:00
Sjoerd Simons
7f8fb3861e queue2: Forward the schedule query upstream
When asked about the scheduling flags first check with upstream and
simply add the _SEEKABLE flag when using a temporary file as storage.

This enables the forwarding of _SEQUENTIAL and _BANDWIDTH_LIMITED from
sources if needed.

https://bugzilla.gnome.org/show_bug.cgi?id=704927
2013-07-29 15:07:44 +02:00
Sebastian Dröge
4aef70fed1 typefind: Only advance offset by the number of bytes we actually read
There might be a short read at EOS.
2013-07-29 11:05:09 +02:00
Arnaud Vrac
9bc26c5f25 input-selector: Fix missing pad activation notification
A new active pad might not be notified in some cases, which results
in the current track number not being set in playbin.

The active-pad notification is only sent in the chain and sink_event
functions, and only when the buffer or event that triggered the active
pad selection is from the newly activated pad. So in the other case
the notification will never be sent.

https://bugzilla.gnome.org/show_bug.cgi?id=704691
2013-07-23 08:59:07 +02:00
Sebastian Dröge
eaf333248a inputselector: Don't push new stream-start events on stream change unless they all have group ids
https://bugzilla.gnome.org/show_bug.cgi?id=704408
2013-07-22 15:30:10 +02:00
Sebastian Dröge
d9f3d3560e typefind: Use new group-id in stream-start event 2013-07-22 15:30:10 +02:00
Sebastian Dröge
0dc232e114 multiqueue: only block serialized query when it's safe
We must be certain that we don't cause a deadlock when blocking the serialized
queries. One such deadlock can happen when we are buffering and downstream is
blocked in preroll and a serialized query arrives. Downstream will not unblock
(and allow our query to execute) until we complete buffering and buffering will
not complete until we can answer the query..

https://bugzilla.gnome.org/show_bug.cgi?id=702840
2013-07-16 11:36:50 +02:00
Sebastian Dröge
717ad20912 inputselector: Deactivate and remove pad without the inputselector lock
Otherwise we might get deadlocks caused by lock order inversion:
During the chain function the stream lock is first locked and then the
inputselector lock. During pad release we first locked the inputselector
lock and then deactivating the pad would lock the stream lock.

There's no reason why the inputselector lock should be required while
deactivating and removing the pad, it's only needed before.

https://bugzilla.gnome.org/show_bug.cgi?id=704002
2013-07-12 10:08:26 +02:00
Sebastian Dröge
c8cfaff1ff inputselector: Keep previous active sinkpad around until we're done with it
Otherwise we'll send a new segment event downstream for each buffer.
2013-07-10 14:30:31 +02:00
Olivier Crête
bbb26f8756 funnel: Re-push all sticky events when buffers come from a different pad
Don't special case segment/caps, just push all sticky events when they are
received on the currently active pad or when the active pad changes.
2013-07-01 20:45:42 -04:00
Olivier Crête
176e16aa5f funnel: Use default pad function for upstream event/queries
The default functions in 1.x already do the right thing
2013-07-01 20:21:10 -04:00
Wim Taymans
2f78e96299 queue2: only block serialized query when it's safe
We must be certain that we don't cause a deadlock when blocking the serialized
queries. One such deadlock can happen when we are buffering and downstream is
blocked in preroll and a serialized query arrives. Downstream will not unblock
(and allow our query to execute) until we complete buffering and buffering will
not complete until we can answer the query..

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=702840
2013-06-24 23:29:16 +02:00
Sebastian Dröge
2f8e572887 queue: Don't hold the queue mutex while doing serialized queries downstream
https://bugzilla.gnome.org/show_bug.cgi?id=702520
2013-06-19 10:53:21 +02:00
Brendan Long
f0a3d8bb09 input-selector: send notify::active signal for input-selector pads.
https://bugzilla.gnome.org/show_bug.cgi?id=701319
2013-06-06 17:16:47 +02:00
Brendan Long
76f0e18f92 input-selector: return FALSE for "active" property if selector is NULL
https://bugzilla.gnome.org/show_bug.cgi?id=701323
2013-06-04 17:46:25 +02:00
Sebastian Dröge
ab6a1085ee (multi)queue: Don't access query items during flushing 2013-05-27 16:38:18 +02:00
Sebastian Dröge
e472d9d261 multiqueue: Don't do serialized queries when we're flushing
Just immediately fail the query, otherwise we would wait forever
for the query to be answered.
2013-05-27 16:22:00 +02:00
Sebastian Dröge
a03435dfba queue2: First set query result, then signal GCond 2013-05-27 16:08:39 +02:00
Sebastian Dröge
6f042f13ae queue: Fix handling of serialized queries
During FLUSH_START the query needs to be unblocked already, otherwise
it can lead to deadlocks if the FLUSH_START is the result of something
done from the streaming thread of the srcpad (the queue will never be
emptied!).
2013-05-27 15:59:07 +02:00
Sebastian Dröge
cdc429f296 queue2: Unblock any waiting serialize queries on FLUSH_START
Fixes some deadlocks during flushing.

And store queue items differently to not accidentially read
already unreffed queries when flushing. Queries are owned by
upstream and not us.
2013-05-27 15:41:14 +02:00
Sebastian Dröge
b6fac17502 queue/queue2/multiqueue: When flushing, make sure to not lose any sticky events
https://bugzilla.gnome.org/show_bug.cgi?id=688824
2013-05-27 13:01:43 +02:00
Nicolas Dufresne
5bbc6f1c8c valve: Don't read sticky flag from unrefed event 2013-05-25 22:03:53 -04:00
Tim-Philipp Müller
789b68e506 tee: fix property description for now-unused "alloc-pad" property
Should probably proxy ALLOCATION queries on that though, if set.
But what else? CAPS and ACCEPT_CAPS too?
2013-05-24 23:28:04 +01:00
Sebastian Dröge
e692993e79 queue2: Add support for serialized queries if using a memory queue 2013-05-24 19:22:22 +02:00
Sebastian Dröge
46270f8925 queue: Set the last serialized query result to FALSE when flushing 2013-05-24 18:47:24 +02:00
Sebastian Dröge
a79d3a0220 multiqueue: Initialize all GstMultiQueueItem fields in both code paths 2013-05-24 18:42:55 +02:00
Sebastian Dröge
1c6341e6a4 multiqueue: Don't access the query after signalling the waiting thread
It might've free'd the query already.
2013-05-24 18:38:40 +02:00
Sebastian Dröge
3b44a44a01 multiqueue: Make sure to always signal any possible pending serialized queries
And don't unref them when flushing the queue, they're owned by the caller!

https://bugzilla.gnome.org/show_bug.cgi?id=700342
2013-05-24 18:30:44 +02:00
Sebastian Dröge
1d1946a321 typefind: Handle the force-caps property more similar to all typefinding code flow
This makes sure that events happen in order and simplifies the code a bit.
2013-05-15 13:22:04 +02:00
Sebastian Dröge
8e1f70473b queue: Store sticky events on the srcpad if we're dropping them because of leaking 2013-05-09 12:50:20 +02:00
Sebastian Dröge
f93c52684a outputselector: Always forward sticky events to all pads 2013-05-09 12:27:12 +02:00