GNOME.org
 

gstreamer 1.8.3

ChangeLog
=========

2016-08-19  Sebastian Dröge <slomo coaxion net>

        * configure.ac:
          releasing 1.8.3

2016-08-19 11:50:15 +0300  Sebastian Dröge <sebastian centricular com>

        * po/af.po:
        * po/az.po:
        * po/be.po:
        * po/bg.po:
        * po/ca.po:
        * po/cs.po:
        * po/da.po:
        * po/de.po:
        * po/el.po:
        * po/en_GB.po:
        * po/eo.po:
        * po/es.po:
        * po/eu.po:
        * po/fi.po:
        * po/fr.po:
        * po/gl.po:
        * po/hr.po:
        * po/hu.po:
        * po/id.po:
        * po/it.po:
        * po/ja.po:
        * po/lt.po:
        * po/nb.po:
        * po/nl.po:
        * po/pl.po:
        * po/pt_BR.po:
        * po/ro.po:
        * po/ru.po:
        * po/rw.po:
        * po/sk.po:
        * po/sl.po:
        * po/sq.po:
        * po/sr.po:
        * po/sv.po:
        * po/tr.po:
        * po/uk.po:
        * po/vi.po:
        * po/zh_CN.po:
        * po/zh_TW.po:
          Update .po files

2016-08-12 16:15:25 +0200  Edward Hervey <edward centricular com>

        * plugins/elements/gstqueue2.c:
          queue2: Post buffering messages earlier in ringbuffer mode
          In ringbuffer mode we need to make sure we post buffering messages *before*
          blocking to wait for data to be drained.
          Without this, we would end up in situations like this:
          * pipeline is pre-rolling
          * Downstream demuxer/decoder has pushed data to all sinks, and demuxer thread
          is blocking downstream (i.e. not pulling from upstream/queue2).
          * Therefore pipeline has pre-rolled ...
          * ... but queue2 hasn't filled up yet, therefore the application waits for
          the buffering 100% messages before setting the pipeline to PLAYING
          * But queue2 can't post that message, since the 100% message will be posted
          *after* there is room available for that last buffer.
          https://bugzilla.gnome.org/show_bug.cgi?id=769802

2016-07-11 09:58:47 +0200  Edward Hervey <edward centricular com>

        * plugins/elements/gstqueue2.c:
          queue2: Fix average input rate calculation on small input range
          When dealing with small-ish input data coming into queue2, such as
          adaptivedemux fragments, we would never take into account the last
          <200ms of data coming in.
          The problem is that usually on TCP connection the download rate
          gradually increases (i.e. the rate is lower at the beginning of a
          download than it is later on). Combined with small download time (less
          than a second) we would end up with a computed average input rate
          which was sometimes up to 30-50% off from the *actual* average input
          rate for that fragment.
          In order to fix this, force the average input rate calculation when
          we receive an EOS so that we take into account that final window
          of data.
          https://bugzilla.gnome.org/show_bug.cgi?id=768649

2016-05-24 00:40:27 +0100  Tim-Philipp Müller <tim centricular com>

        * gst/Makefile.am:
        * libs/gst/base/Makefile.am:
        * libs/gst/check/Makefile.am:
        * libs/gst/controller/Makefile.am:
        * libs/gst/net/Makefile.am:
          g-i: pass compiler env to g-ir-scanner
          It's what introspection.mak does as well. Should
          fix spurious build failures on gnome-continuous.

2016-05-23 21:15:48 +0100  Tim-Philipp Müller <tim centricular com>

        * gst/Makefile.am:
          gst: g-i: pass compiler with quotes
          So CC="ccache gcc" works properly.

2016-05-23 21:06:53 +0100  Ray Strode <rstrode redhat com>

        * gst/Makefile.am:
          gst: attempt to fix/track-down mysterious gnome-continuous build failures

2016-07-25 19:15:15 +1000  Jan Schmidt <jan centricular com>

        * plugins/elements/gstinputselector.c:
          inputselector: Wake other pads when selected goes EOS
          Other pads that are waiting for the stream on the selected
          pad to advance before they finish waiting themselves
          should be given the chance to do so when the selected pad
          goes EOS. Fixes problems where input streams can end up
          waiting forever if the active stream goes EOS earlier than
          their own end time.

2016-07-05 16:50:16 +0200  Miguel París Díaz <mparisdiaz gmail com>

        * gst/gstpad.c:
          pad: check query caps answered and caps not NULL
          https://bugzilla.gnome.org/show_bug.cgi?id=768450

2016-07-04 10:00:38 +0200  Sebastian Dröge <sebastian centricular com>

        * libs/gst/base/gstbaseparse.c:
          baseparse: Make sure to not create an invalid event order when generating the default CAPS event 
because of a GAP event
          There must be a SEGMENT event before the GAP event, and SEGMENT events must
          come after any CAPS event. We however did not produce any CAPS yet, so we need
          to ensure to insert the CAPS event before the SEGMENT event into the pending
          events list.
          https://bugzilla.gnome.org/show_bug.cgi?id=766970

2016-06-28 15:01:17 +0200  Guillaume Desmottes <guillaume desmottes collabora co uk>

        * gst/gstbus.c:
          bus: chain up GObject::constructed() to the parent class' implementation
          Needed so GstBus can be tracked by the leaks tracer.
          https://bugzilla.gnome.org/show_bug.cgi?id=768141

2016-06-15 13:43:59 +0100  Vincent Penquerc'h <vincent penquerch collabora co uk>

        * plugins/elements/gstqueue2.c:
          queue2: fix crash deleting current region for small ring buffers
          Ensure we do not attempt to destroy the current range. Doing so
          causes the current one to be left dangling, and it may be dereferenced
          later, leading to a crash.
          This can happen with a very small queue2 ring buffer (10000 bytes)
          and 4 kB buffers.
          repro case:
          gst-launch-1.0 fakesrc sizetype=2 sizemax=4096 ! \
          queue2 ring-buffer-max-size=1000 ! fakesink sync=true
          https://bugzilla.gnome.org/show_bug.cgi?id=767688

2016-07-01 09:44:12 +0200  Edward Hervey <edward centricular com>

        * plugins/elements/gstmultiqueue.c:
          multiqueue: Fix behaviour with not-linked and eos pads
          This is an update on c9b6848885f4675d447e823c8fb117e247658252
          multiqueue: Fix not-linked pad handling at EOS
          While that commit did fix the behaviour if upstream sent a GST_EVENT_EOS,
          it would break the same issue when *downstream* returns GST_FLOW_EOS
          (which can happen for example when downstream decoders receive data
          from after the segment stop).
          GST_PAD_IS_EOS() is only TRUE when a GST_EVENT_EOS has flown through it
          and not when a GST_EVENT_EOS has gone through it.
          In order to handle both cases, also take into account the last flow
          return.
          https://bugzilla.gnome.org/show_bug.cgi?id=763770

2016-06-08 12:34:53 -0400  Nicolas Dufresne <nicolas dufresne collabora com>

        * plugins/elements/gsttee.c:
          tee: Properly handle return value when only 1 pad
          This patch handle the case when you have 1 pad (so the fast path is
          being used) but this pad is removed. If we are in allow-not-linked, we
          should return GST_FLOW_OK, otherwise, we should return GST_FLOW_UNLINKED
          and ignore the meaningless return value obtained from pushing.
          https://bugzilla.gnome.org/show_bug.cgi?id=767413

2016-06-13 18:33:27 +0200  Sebastian Dröge <sebastian centricular com>

        * libs/gst/base/gstbasesink.c:
          basesink: Update start time when losing state only if we were in PLAYING
          If we were in PAUSED, the current clock time and base time don't have much to
          do with the running time anymore as the clock might have advanced while we
          were PAUSED. The system clock does that for example, audio clocks often don't.
          Updating the start time in PAUSED will cause a) the wrong position to be
          reported, b) step events to step not just the requested amount but the amount
          of time we spent in PAUSED. The start time should only ever be updated when
          going from PLAYING to PAUSED to remember the current running time (to be able
          to compensate later when going to PLAYING for the clock time advancing while
          PAUSED), not when we are already in PAUSED.
          Based on a patch by Kishore Arepalli <kishore arepalli gmail com>
          The updating of the start time when the state is lost was added in commit
          ba943a82c0bbfd17c9ee9f5068d44c9d9274fd13 to fix the position reporting when
          the state is lost. This still works correctly after this change.
          https://bugzilla.gnome.org/show_bug.cgi?id=739289

2016-02-19 16:18:12 +0100  Linus Svensson <linussn axis com>

        * tests/check/gst/gstpad.c:
          gstpad tests: Add a test for flush event only probes
          https://bugzilla.gnome.org/show_bug.cgi?id=762330

2016-03-24 12:13:39 -0300  Thiago Santos <thiagoss osg samsung com>

        * gst/gstpad.c:
          pad: consider PROBE_TYPE_EVENT_FLUSH when using PROBE_TYPE_ALL_BOTH
          When GST_PAD_PROBE_EVENT_FLUSH is used, the probes already have
          a data type and it is not needed to automatically add the default
          types. Without this, EVENT_FLUSH probes that didn't specify a data
          type would be called also for other data such as buffers.
          https://bugzilla.gnome.org/show_bug.cgi?id=762330



Download
========
https://download.gnome.org/sources/gstreamer/1.8/gstreamer-1.8.3.tar.xz (3.54M)
  sha256sum: 66b37762d4fdcd63bce5a2bec57e055f92420e95037361609900278c0db7c53f
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]