- Dec 18, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Dec 16, 2014
-
-
Wim Taymans authored
PERFORMANCE log the reason why a buffer could not be recycled in the bufferpool.
-
- Dec 11, 2014
-
-
When using a negative rate (rate being segment.rate * segment.applied_rate), we will end up reporting decreasing positions, therefore adjust the clamping against last reported value accordingly. Fixes positions getting properly reported with applied_rate < 0.0 https://bugzilla.gnome.org/show_bug.cgi?id=738092
-
Otherwise the application might still get the old value if it asks between the message and the real update.
-
- Nov 28, 2014
-
-
Edward Hervey authored
The documentation states that gst_element_send_event is to "send an event to an element". Therefore we *send* upstream events to a source pad and downstream events to a sink pad
-
Edward Hervey authored
If we get a downstream event we want to send it to a random SINK pad (and vice-versa).
-
- Nov 23, 2014
-
-
Thiago Santos authored
When comparing percentage values, compare with 0-100 scale as it has already been made relative to 0-high_percent, otherwise we mark the queue as not buffering and report a 50% to the user. This leads to a buffering stall as the user assumes the queue is still buffering but it thinks it isn't. https://bugzilla.gnome.org/show_bug.cgi?id=736969
-
Thiago Santos authored
multiqueue's queues stored percent value is the percentage from 0 to 100 (max-size-*) and should be compared with the requested limit (high_percentage) set by the user and not with 100% to check if buffering should stop. Otherwise we are only stopping buffering when the queue gets completely full.
-
- Nov 20, 2014
-
-
When searching for the string terminator don't read past the ending 0-byte when escaping characters. Add unit test for various escaping cases.
-
- Nov 15, 2014
-
-
Previously, dropping a query from a pad probe would deem the query succeeded, and the caller might then assume the query's results are valid, and thus dereference an invalid object such as a GstCaps. We now assume dropped queries did not succeed. Dropped events and buffers are still deemed a success.
-
If a task thread is calling pause on it self and the controlling/"main" thread stops the task, it could end in a race where gst_task_func loops and then checks for paused after the controlling thread just changed the task state to stopped. Hence the task would actually call func again even though it was both paused and stopped. https://bugzilla.gnome.org/show_bug.cgi?id=740001
-
- 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