- Apr 18, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Apr 12, 2014
-
-
-
Queued frames were not released after being pushed, this caused a leak of the GstBaseParseFrame structure. https://bugzilla.gnome.org/show_bug.cgi?id=727883
-
Looks like that was the last remaining mention in core ...
-
-
If the toplevel bin is not not a pipeline, we place the bin in a pipeline. Also make sure that we connect to the deep-notify of this new pipeline because we will g_signal_handler_disconnect() from it later.
-
-
This ensures that the lock of the internal pad is held while referencing it's peer (= the target pad), which ensures that the peer is not going to be unlinked/destroyed in the meantime. https://bugzilla.gnome.org/show_bug.cgi?id=725809
-
Refcount and writability are not related for memory objects.
-
- Apr 07, 2014
-
-
- Mar 02, 2014
-
-
- Feb 18, 2014
-
-
Wim Taymans authored
We want to keep the downloaded file untruncated so that we can use it again later. Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=724373
-
Wim Taymans authored
Make a method to get the seeking threshold. If data is further away from this threshold we want to perform a seek upstream. When the current downloaded range can merge with the next range, actually include the data of the next range into the current range instead of discarding it. Also decide if we seek to the write position of the merged range or continue reading.
-
- Feb 11, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
This allows to distinguish normal read failures from read failures where we miss authorization.
-
- 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
-