gstreamer 1.2.3

From: Sebastian Dröge <install-module master gnome org>
To: FTP Releases <ftp-release-list gnome org>
Subject: gstreamer 1.2.3
Date: Mon, 10 Feb 2014 09:20:15 +0000 (UTC)
ChangeLog
=========

2014-02-08  Sebastian Dröge <slomo coaxion net>

        * configure.ac:
          releasing 1.2.3

2014-01-24 19:19:08 +0100  Arnaud Vrac <avrac freebox fr>

        * 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 <sebastian centricular com>

        * 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 <ts santos sisa samsung com>

        * 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 <ts santos sisa samsung com>

        * 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 <sebastian centricular com>

        * 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 <wtaymans redhat com>

        * tests/check/gst/gstsegment.c:
          tests: improve check, also check stream-time

2014-01-08 15:31:28 +0100  Wim Taymans <wtaymans redhat com>

        * 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 <wtaymans redhat com>

        * 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 <wtaymans redhat com>

        * 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 <ts santos sisa samsung com>

        * 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 <wtaymans redhat com>

        * 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 <wtaymans redhat com>

        * 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 <ts santos sisa samsung com>

        * 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 <ts santos sisa samsung com>

        * 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 <ts santos sisa samsung com>

        * 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 <ts santos sisa samsung com>

        * 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 <ts santos sisa samsung com>

        * 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 <ts santos sisa samsung com>

        * 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 <sebras hotmail com>

        * 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 <zhangyanping210 163 com>

        * 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 <sebastian centricular com>

        * 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 <sebastian centricular com>

        * 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 <sebastian centricular com>

        * 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 <sebastian centricular com>

        * 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 <sebastian centricular com>

        * 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 <sebastian centricular com>

        * 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 <sebastian centricular com>

        * 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 <pedro pedrocr net>

        * 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.



Download
========
https://download.gnome.org/sources/gstreamer/1.2/gstreamer-1.2.3.tar.xz (3.07M)
  sha256sum: 0f9a9817a384b3448c368c23345e5122435caef9c00f1c40d7b1953827b0d8eb
[Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index]