=== release 1.2.3 === 2014-02-08 Sebastian Dröge * configure.ac: releasing 1.2.3 2014-01-24 19:19:08 +0100 Arnaud Vrac * plugins/elements/gstmultiqueue.c: multiqueue: do not reduce single queue below current level 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 2014-02-04 16:20:08 +0100 Sebastian Dröge * po/id.po: * po/nl.po: * po/pt_BR.po: * po/sk.po: * po/sr.po: po: Update translations 2014-01-17 22:53:01 -0300 Thiago Santos * gst/gstpad.c: pad: fix sticky event leak after sticky_events_foreach 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 2014-01-15 00:12:26 -0300 Thiago Santos * plugins/elements/gstmultiqueue.c: multiqueue: prevent buffering forever with playbin 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 2014-01-15 11:12:08 +0100 Sebastian Dröge * gst/gstsegment.c: segment: gst_segment_offset_running_time() will be available in 1.2.3 2014-01-08 15:47:10 +0100 Wim Taymans * tests/check/gst/gstsegment.c: tests: improve check, also check stream-time 2014-01-08 15:31:28 +0100 Wim Taymans * tests/check/gst/gstsegment.c: tests: add unit test for segment _offset_running_time() Add a unit test to check that positive and negative offsets are applied correctly in various cases. 2014-01-08 14:57:04 +0100 Wim Taymans * gst/gstpad.c: pad: use new segment offset method to apply the offset Fixes https://bugzilla.gnome.org/show_bug.cgi?id=721422 2014-01-08 14:54:47 +0100 Wim Taymans * gst/gstsegment.c: * gst/gstsegment.h: * win32/common/libgstreamer.def: segment: add method to offset the segment running-time Add a method that can apply an offset to the calculated running-time of a segment. 2014-01-08 16:28:54 -0300 Thiago Santos * libs/gst/base/gstbaseparse.c: baseparse: do not ignore TIME segments 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 2014-01-08 15:23:00 +0100 Wim Taymans * gst/gstsegment.c: segment: take offset into account in _to_position() Take the offset into account when converting between running-time and segment positions. 2014-01-08 14:52:04 +0100 Wim Taymans * libs/gst/base/gstcollectpads.c: collectpads: take offset into account for expected segment position The firt valid segment position is start + offset. Also add some more debug and a FIXME 2014-01-13 08:37:37 -0300 Thiago Santos * tests/check/libs/baseparse.c: tests: baseparse: add test for reverse playback on passthrough 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 2014-01-11 10:49:17 -0300 Thiago Santos * tests/check/Makefile.am: * tests/check/libs/.gitignore: * tests/check/libs/baseparse.c: tests: baseparse: add basic test for baseparse Just a small test to check that basic playback works 2014-01-10 09:10:06 -0300 Thiago Santos * libs/gst/base/gstbaseparse.c: baseparse: do not accumulate buffers on passthrough mode 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 2014-01-02 16:22:37 -0300 Thiago Santos * libs/gst/base/gstbaseparse.c: baseparse: remove pending_segment as it was being misused 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 2014-01-02 13:43:54 -0300 Thiago Santos * libs/gst/base/gstbaseparse.c: baseparse: push pending events before GAP event 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 2014-01-02 13:41:25 -0300 Thiago Santos * libs/gst/base/gstbaseparse.c: baseparse: refactor pending events pushing Refactor code repeated 3 times to a common function https://bugzilla.gnome.org/show_bug.cgi?id=721350 2013-12-04 00:10:36 +0100 Sebastian Rasmussen * docs/Makefile.am: * docs/design/Makefile.am: docs: add missing files for distribution * 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 2014-01-03 11:47:23 +0800 YanpingZhang * plugins/elements/gstmultiqueue.c: multiqueue: Fix hanging if shut down while handling a serialized query https://bugzilla.gnome.org/show_bug.cgi?id=721253 2014-01-02 13:34:52 +0100 Sebastian Dröge * tests/check/gst/gstpad.c: pad: Add unit test for adding/removing blocking probes while a pad is blocked 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 2014-01-02 13:33:20 +0100 Sebastian Dröge * gst/gstpad.c: pad: Check if new probes need to be called when adding/removing some 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 2014-01-02 11:13:27 +0100 Sebastian Dröge * plugins/elements/gsttee.c: * plugins/elements/gsttee.h: tee: Remove dyn lock 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. 2014-01-02 11:09:59 +0100 Sebastian Dröge * plugins/elements/gsttee.c: tee: Keep another ref to our one and only srcpad around while pushing 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 2013-12-30 19:03:22 +0100 Sebastian Dröge * gst/gstpad.c: pad: Keep an extra ref of the pad when calling an IDLE probe immediately The callback might destroy the pad. 2013-12-30 18:44:24 +0100 Sebastian Dröge * gst/gstpad.c: pad: Only call IDLE probes if we are actually idle 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. 2013-12-30 10:01:39 +0100 Sebastian Dröge * gst/gstpad.c: pad: Don't ignore probe callback return value when immediately calling IDLE probe https://bugzilla.gnome.org/show_bug.cgi?id=721096 2013-12-29 14:06:55 +0000 Pedro Côrte-Real * scripts/git-update.sh: scripts: git-update.sh: fix for non-master branches Pull from tracking branch instead of origin/master, so that this works with e.g. 1.2 as well.