=== release 1.6.2 ===

2015-12-14  Sebastian Dröge <slomo@coaxion.net>

	* configure.ac:
	  releasing 1.6.2

2015-12-14 19:05:35 +0100  Sebastian Dröge <sebastian@centricular.com>

	* po/sv.po:
	  po: Update translations

2015-12-11 11:01:53 +0000  Tim-Philipp Müller <tim@centricular.com>

	* gst-libs/gst/rtp/gstrtpbasedepayload.c:
	  rtpbasedepay: when setting discont flag make sure rtpbuffer is current
	  Depayloaders will look at rtpbuffer->buffer for the discont flag.
	  When we set the discont flag on a buffer in the rtp base depayloader
	  and we have to make the buffer writable, make sure the rtpbuffer
	  actually contains the newly-flagged buffer, not the original input
	  buffer. This was introduced with the addition of the process_rtp_packet
	  vfunc, but would only trigger if the input buffer wasn't flagged
	  already and was not writable already.

2015-12-11 10:25:00 +0000  Tim-Philipp Müller <tim@centricular.com>

	* gst-libs/gst/rtp/gstrtpbasedepayload.c:
	  rtpbasedepay: fix possible refcounting issue when detecting a discont
	  When we detect a discont and the input buffer isn't already flagged
	  as discont, handle_buffer() does a gst_buffer_make_writable() on the
	  input buffer in order to set the flag. This assumed it had ownership
	  of the input buffer though, which it didn't. This would still work
	  fine in most scenarios, but could lead to crashes or mini object
	  unref criticals in some cases when a discont is detected, e.g. when
	  using pcapparse in front of a depayloader. This problem was
	  introduced in bc14cdf529e.

2015-12-02 16:16:22 +0200  Sebastian Dröge <sebastian@centricular.com>

	* gst/playback/gstdecodebin2.c:
	  decodebin: Update buffering messages when removing an element that had buffering pending
	  Otherwise we'll remove that element while keeping its buffering message in our
	  list, and because of that never ever report buffering 100% as that element
	  will always be at a lower percentage.
	  This fixes e.g. seeking over Period boundaries in DASH and various other
	  issues when buffering happens between group switches.
	  Also use a new mutex for protecting the buffering messages. The object lock is
	  already used by gst_object_has_as_ancestor() and we need to use it now for
	  checking if the buffering message sender has the to-be-removed element as
	  ancestor.

2015-12-02 09:00:31 -0500  Evan Callaway <evan.callaway@ipconfigure.com>

	* gst-libs/gst/rtsp/gstrtspdefs.c:
	* gst-libs/gst/rtsp/gstrtspdefs.h:
	  rtspconnection: Update capitalization of x-sessioncookie
	  Some servers incorrectly parse header names with strict case-sensitivity.  For
	  compatibility with these systems change X-Sessioncookie to x-sessioncookie.
	  https://bugzilla.gnome.org/show_bug.cgi?id=758921

2015-11-17 09:06:34 +0900  Vineeth TM <vineeth.tm@samsung.com>

	* sys/ximage/ximagesink.c:
	* sys/xvimage/xvimagesink.c:
	  xvimagesink/ximagesink: Fix structure memory leak
	  https://bugzilla.gnome.org/show_bug.cgi?id=758204

2015-11-06 19:31:47 +0100  Edward Hervey <edward@centricular.com>

	* gst/playback/gstdecodebin2.c:
	  decodebin: Properly deactivate ghostpads
	  Just setting the ghostpad as flushing wasn't enough. It needs to be
	  consistent on the internal proxypad also, otherwise you end up in
	  situations where:
	  * a pending buffer on the target pad triggers the sticky event
	  propagation
	  * the default implementation sees that the proxypad is not flushing,
	  so it tries to push it to the other pad (the actual ghostpad)
	  * the ghostpad is flushing, so returns FALSE
	  * the push_event function sees that pushing the event failed...
	  * ... and pending buffer push returns GST_FLOW_ERROR, instead of
	  GST_FLOW_FLUSHING
	  By using gst_pad_set_active(FALSE), we ensure that both the ghostpad
	  and the proxypad are flushing/deactivated. The situation above will
	  no longer occur, and a GST_FLOW_FLUSHING will be returned.

2015-11-05 11:34:07 +0100  Thibault Saunier <tsaunier@gnome.org>

	* gst/volume/gstvolume.c:
	  volume: Do not try to get binding value array if we are not processing any sample
	  In some conditions we might process empty buffers, calling
	  gst_control_binding_get_value_array in that case will lead
	  to the assertion:
	  (lt-ges-launch-1.0:18859): GStreamer-CRITICAL **: gst_control_binding_get_value_array: assertion 'values' failed

2015-10-26 21:32:41 +0100  Csaba Toth <tocsanti@gmail.com>

	* gst/tcp/gstmultisocketsink.c:
	  multisocketsink: fix "client-removed" signal on 64-bit platforms and with bindings
	  The client-removed signal used G_INT_TYPE instead of G_SOCKET_TYPE
	  in its definition leading to problems on platforms where the size
	  of a pointer is larger than the size of an integer, It would also
	  not work at all with dynamic language bindings.
	  https://bugzilla.gnome.org/show_bug.cgi?id=757155

2015-10-28 18:36:41 +0100  Joan Pau Beltran <joanpau.beltran@socib.cat>

	* gst/videotestsrc/gstvideotestsrc.c:
	  videotestsrc: fix handling of Bayer format 'gbrg'
	  Due to a typo, videotestsrc did not handle the Bayer
	  format 'gbrg' properly and reported it as invalid,
	  causing negotiation errors.
	  https://bugzilla.gnome.org/show_bug.cgi?id=757264