- Nov 06, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Oct 24, 2014
-
-
Tim-Philipp Müller authored
Fixes 'Attempt to unlock mutex that was not locked' warning with newer GLibs when sink is shut down in certain situations. Triggered by the decodebin test_reuse_without_decoders unit test in -base sometimes, esp. on slower machines.
-
Otherwise we might have unlinked streams waiting. https://bugzilla.gnome.org/show_bug.cgi?id=738198
-
The point of this example is to show how to set caps on the source pad once it has been set on the sink pad. So, in passthrough mode, the caps is just copied to the source pad. https://bugzilla.gnome.org/show_bug.cgi?id=738153
-
Running two threads, one executing the timer and one unscheduling it, the unscheduled status set by the second thread is sometimes overwritten by the first one. https://bugzilla.gnome.org/show_bug.cgi?id=737999
-
Tim-Philipp Müller authored
-
- Oct 14, 2014
-
-
If we are pushing a serialized query into a queue and the queue is filled, we will end in a deadlock. We need to release the lock before pushing and acquire it again afterward. https://bugzilla.gnome.org/show_bug.cgi?id=737794
-
Sebastian Dröge authored
-
-
-
Sebastian Dröge authored
capsfilter: Push pending events before a buffer also if upstream never configured caps but we have srcpad caps already Otherwise we never send pending events downstream that arrive after we configured caps on the srcpad. https://bugzilla.gnome.org/show_bug.cgi?id=737735
-
- Sep 24, 2014
- Sep 23, 2014
-
-
Thibault Saunier authored
Avoiding deadlocks!
-
- Sep 22, 2014
-
-
Thibault Saunier authored
This might create deadlocks and we need to avoid holding element specific lock while posting messages For example a deadlock will happen if while posting the message, someone connected on the bus (sync) tries to DOT the pipeline. https://bugzilla.gnome.org/show_bug.cgi?id=737102
-
Thibault Saunier authored
-
Thiago Santos authored
It might cause deadlocks to post messages while holding the queue2 lock. To avoid this a new boolean flag is set whenever a new buffering percent is found. The message is posted after the lock is released. To make sure the buffering messages are posted in the right order, messages are posted holding another lock. This prevents 2 threads trying to post messages at the same time. https://bugzilla.gnome.org/show_bug.cgi?id=736969
-
- Sep 19, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Sep 17, 2014
- Sep 16, 2014
-
-
Thiago Santos authored
It might cause deadlocks to post messages while holding the multiqueue lock. To avoid this a new boolean flag is set whenever a new buffering percent is found. The message is posted after the lock can be released. To make sure the buffering messages are posted in the right order, messages are posted holding another lock. This prevents 2 threads trying to post messages at the same time. https://bugzilla.gnome.org/show_bug.cgi?id=736295
-
Otherwise we can forget to unref objects in error cases. https://bugzilla.gnome.org/show_bug.cgi?id=736680
-
Sebastian Dröge authored
This was hardcoded to "sink" / "src" by accident in previous refactoring.
-
- Sep 12, 2014
- Sep 11, 2014
- Sep 04, 2014
-
-
Fixes tests/icles/output-selector-test https://bugzilla.gnome.org/show_bug.cgi?id=729811
-
- Aug 28, 2014
-
-
Imagine the following 'pipeline' -------------- p1/| 'fullqueue' |--- 'laggy' downstream --------- / | | -| demuxer | | multiqueue | --------- \ | | p2\| 'emptyqueue' |--- 'fast' downstream -------------- In the case downstream of one single queue (fullqueue) has (a lot of) latency (for example for reverse playback with video), we can end up having the other SingleQueue (emptyqueue) emptied, before that fullqueue gets unblocked. In the meantime, the demuxer tries to push on fullqueue, and is blocking there. In that case the current code will post a BUFFERING message on the bus when emptyqueue gets emptied, that leads to the application setting the pipeline state to PAUSED. So now we end up in a situation where 'laggy downstream' is prerolled and will not unblock anymore because the pipeline is set to PAUSED, the fullequeue does not have a chance to be emptied and the emptyqueue can not get filled anymore so no more BUFERRING message will be posted and the pipeline is stucked in PAUSED for the eternity. Making sure that we do not try to "buffer" if one of the single queue does not need buffering, prevents this situtation from happening though it lets the oportunity for buffering in all other cases. That implements a new logic where we need all singlequeue to need buffering for the multiqueue to actually state buffering is needed, taking the maximum buffering of the single queue as the reference point. https://bugzilla.gnome.org/show_bug.cgi?id=734412
-
The tag memory flag will be set later if the memory is also copied. This patch avoids buffers being freed needlessly in bufferpools. https://bugzilla.gnome.org/show_bug.cgi?id=735574
-
- Aug 27, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-