- Feb 08, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Feb 04, 2014
-
-
When the single queue size was just bumped by 1 to allow more buffers to be added, the buffers limit could be reduced to the current level when setting the max-size-buffers property. This would result in a stall since the queue would not grow anymore at this point. Prevent this by not reducing a single queue size below the current number of buffers + 1. https://bugzilla.gnome.org/show_bug.cgi?id=712597
-
Sebastian Dröge authored
-
- Jan 18, 2014
-
-
Thiago Santos authored
events_foreach adds an extra ref when giving the event to the user function. In case it was unrefed by the user, this extra ref disappeared, but events_foreach still should unref again to lose its own ref before removing the event from the array. https://bugzilla.gnome.org/show_bug.cgi?id=722467
-
- Jan 15, 2014
-
-
Thiago Santos authored
When prerolling/buffering, multiqueue has its buffers limit set to 0, this means it can take an infinite amount of buffers. When prerolling/buffering finishes, its limit is set back to 5, but only if the current level is lower than 5. It should (almost) never be and this will cause prerolling/buffering to need to wait to reach the hard bytes and time limits, which are much higher. This can lead to a very long startup time. This patch fixes this by setting the single queues to the max(current, new_value) instead of simply ignoring the new value and letting it as infinite(0) https://bugzilla.gnome.org/show_bug.cgi?id=712597
-
-
Wim Taymans authored
-
Wim Taymans authored
Add a unit test to check that positive and negative offsets are applied correctly in various cases.
-
Wim Taymans authored
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=721422
-
Wim Taymans authored
Add a method that can apply an offset to the calculated running-time of a segment.
-
- Jan 14, 2014
-
-
TIME segments are being ignored and a standard initialized segment is used instead. This causes issues as not properly detecting reverse playback or not cliping output based on the segment. This seems to be a regression from one of the GstSegment/GstEvent redesigns on the 0.10 -> 1.0 transition
-
Take the offset into account when converting between running-time and segment positions.
-
The firt valid segment position is start + offset. Also add some more debug and a FIXME
-
- Jan 13, 2014
-
-
Thiago Santos authored
Baseparse stores buffers for reverse playback to push on the next DISCONT, the issue was that it wouldn't ever check for a discont on passthrough mode as it skips all real parsing. This test was create to verify this issue and prevent it from happening again https://bugzilla.gnome.org/show_bug.cgi?id=721941
-
Thiago Santos authored
Just a small test to check that basic playback works
-
Thiago Santos authored
If on passthrough during reverse playback, do not accumulate buffers as baseparse will never check for DISCONT flag to push those buffers. So just push buffers downstream as if it was forward playback. https://bugzilla.gnome.org/show_bug.cgi?id=721941
-
- Jan 08, 2014
-
-
Thiago Santos authored
It wasn't required, instead baseparse was using it to check the media caps to identify if it was handling audio or video. The pending_segment was removed and a checked_media boolean replaced it for a more accurate naming. https://bugzilla.gnome.org/show_bug.cgi?id=721350
-
Thiago Santos authored
A GAP event is handled as an empty buffer by sinks and they expect to receive start up events before GAP events (like a segment). This is important specially if there is a GAP at the beginning of a stream (before any buffers) so that the segment event can be pushed downstream before the GAP https://bugzilla.gnome.org/show_bug.cgi?id=721350
-
Thiago Santos authored
Refactor code repeated 3 times to a common function https://bugzilla.gnome.org/show_bug.cgi?id=721350
-
* add some documentation files in docs/design * add docs/list-ulink.xsl so check in docs/manual works Fixes https://bugzilla.gnome.org/show_bug.cgi?id=719814
-
- Jan 06, 2014
- Jan 03, 2014
-
-
Sebastian Dröge authored
And make sure that these new probes are actually called if they should instead of silently blocking the pad forever. https://bugzilla.gnome.org/show_bug.cgi?id=721289
-
Sebastian Dröge authored
This allows blocking a pad, add a new blocking probe, removing the first probe and then having the second probe called. Which could then decide that data-flow should actually continue instead of blocking now. https://bugzilla.gnome.org/show_bug.cgi?id=721289
-
Sebastian Dröge authored
It was used for pad-alloc in 0.10 but currently is completely unused and not necessary. All pad access is protected by the tee object lock and keeping another reference to the current pad.
-
Sebastian Dröge authored
A pad probe on that pad might otherwise just release the pad, drop the last reference and cause great misery. https://bugzilla.gnome.org/show_bug.cgi?id=721300
-
- Dec 31, 2013
-
-
Sebastian Dröge authored
The callback might destroy the pad.
-
Sebastian Dröge authored
Also only check the data types for non-IDLE probes. When we are idle, we have no data type obviously. Previously we were calling IDLE probes during data flow whenever a non-blocking probe would be called. The pad was usually not idle at that time.
-
-
- Dec 29, 2013
-
-
Pull from tracking branch instead of origin/master, so that this works with e.g. 1.2 as well.
-
- Dec 26, 2013
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
funnel outputs whatever one of the upstreams currently outputs, a caps query to a random upstream does not give the right answer here.
-
Sebastian Dröge authored
-
This makes buffering stop in case a stream switch happens. This is important for adaptive streams that can disable not-linked streams to avoid consuming the network bandwidth. https://bugzilla.gnome.org/show_bug.cgi?id=719575
-
- Dec 13, 2013
-
-
Pass the event return value upstream. Remove strange goto construct.
-
- Dec 06, 2013
-
-
Tim-Philipp Müller authored
g_source_remove() works on the default main context, and we're doing things with a custom context. Fixes warning with newer GLib versions.
-
Tim-Philipp Müller authored
It's considered a programming error in recent GLib versions now. We may already have removed the source by returning FALSE from the callback if it was fired. Fixes warning with newer GLibs when interrupting a pipeline with Control-C.
-
- Dec 03, 2013
-
-
Olivier Crête authored
After patch bda406c4, the state of the singlequeue was set to OK, but nothing would then wake up the thread, as the other wakeup functions only look at singlequeues that are marked as having received as not-linked. https://bugzilla.gnome.org/show_bug.cgi?id=708200
-