=== release 1.8.3 === 2016-08-19 Sebastian Dröge * configure.ac: releasing 1.8.3 2016-08-19 11:50:15 +0300 Sebastian Dröge * 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 * 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 * 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 * 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 * 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 * gst/Makefile.am: gst: attempt to fix/track-down mysterious gnome-continuous build failures 2016-07-25 19:15:15 +1000 Jan Schmidt * 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 * 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 * 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 * 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 * 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 * 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 * 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 * 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 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 * 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 * 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