=== release 1.12.1 === 2017-06-20 Sebastian Dröge * configure.ac: releasing 1.12.1 2017-06-20 11:08:32 +0300 Sebastian Dröge * po/bg.po: * po/da.po: * po/de.po: * po/el.po: * po/fr.po: * po/hr.po: * po/hu.po: * po/nb.po: * po/pl.po: * po/ru.po: * po/sr.po: * po/sv.po: * po/tr.po: * po/uk.po: * po/vi.po: * po/zh_CN.po: po: Update translations 2017-06-13 17:40:19 +0300 Vivia Nikolaidou * gst/multifile/gstsplitmuxsink.c: splitmux: Drop allocation queries They can cause us to deadlock, while we're waiting for a new frame and upstream is waiting for the allocation query to be answered before sending a frame https://bugzilla.gnome.org/show_bug.cgi?id=783753 2017-06-15 10:40:51 +0300 Sebastian Dröge * gst/rtsp/gstrtspsrc.c: * gst/rtsp/gstrtspsrc.h: rtspsrc: Use a mutex for protecting against concurrent send/receives We currently send data to the RTSP connection from multiple threads: whenever a command is to be handled and whenever RTCP is generated. This can cause data corruption or worse if both happen at the same time. As such, protect gst_rtsp_connection_send() and gst_rtsp_connection_receive() calls with a mutex. While this means that we hold a mutex during the IO operation, this is not actually a problem as the IO operation can be interrupted (gst_rtsp_connection_flush()) at any time and is blocking by itself anyway. 2017-06-15 11:50:44 +0300 Sebastian Dröge * gst/isomp4/atoms.c: qtmux: Un-merge the last two stsc entries after serializing The last entry will most likely get new samples added to it in "robust" muxing mode, changing the samples_per_chunk and thus making it wrong to keep the last two entries merged. It will run into an assertion later when adding a new sample to the chunk. Thanks to gdiener@cardinalpeak.com for the analysis of the bug and proposal for a solution. 2017-06-14 00:09:25 +0300 Sebastian Dröge * gst/wavparse/gstwavparse.c: wavparse: Actually clip to upstream size instead of size of the data chunk There might be other chunks after the data chunk, so clipping the chunk size with the data size can lead to a negative number and all following calculations go wrong and cause crashes or worse. This was introduced in 3ac119bbe2c360e28c087cf3852ea769d611b120. https://bugzilla.gnome.org/show_bug.cgi?id=783760 2017-05-30 22:23:10 +0200 Juan Navarro * gst/rtpmanager/rtpsession.c: rtpsession: print value of unknown RTCP Payload Type This adds printing the actual value of any unknown RTCP PT to the already existing WARNING log message. https://bugzilla.gnome.org/show_bug.cgi?id=783248 2017-06-02 11:30:15 +0100 Tim-Philipp Müller * gst/rtp/gstrtph265depay.c: rtph265depay: fix caps leak 2017-05-24 11:33:05 +0530 vijay * gst/audioparsers/gstaacparse.c: aacparse : Fix, Caps were not set while reusing aacparse While reusing aacparse caps were not set.This fix enables aacparse to reuse in same pipeline. https://bugzilla.gnome.org/show_bug.cgi?id=783027 2017-05-16 12:56:15 +0300 Vivia Nikolaidou * gst/isomp4/gstqtmux.c: qtmux: Do not check timecode data for mp4 container Timecode trak is only supported for mov right now, not for mp4. That code would otherwise create an invalid trak if the muxed video contained timecode metadata. https://bugzilla.gnome.org/show_bug.cgi?id=782684 2017-05-10 15:58:41 +0200 Sebastian Dröge * gst/isomp4/gstqtmux.c: qtmux: Lateness is in QT timescale, diff in GstClockTime Print the right one in debug output to get meaningful numbers. 2017-05-09 11:41:25 +0200 Sebastian Dröge * ext/vpx/gstvpxdec.c: vpxdec: Set fb->priv to NULL after freeing just in case https://bugzilla.gnome.org/show_bug.cgi?id=782359 2017-05-08 15:22:00 +0000 Dustin Spicuzza * sys/directsound/gstdirectsoundsink.c: * sys/directsound/gstdirectsoundsink.h: directsoundsink: Use GstClock API instead of Sleep() for waiting It's more accurate and allows cancellation. https://bugzilla.gnome.org/show_bug.cgi?id=773681 2017-05-08 15:05:45 +0000 Tim-Philipp Müller * ext/vpx/gstvp9dec.c: vpx: fix build against older libvpx versions Such as 1.3.0 as on raspbian. 2017-05-03 23:23:10 +0530 Nirbheek Chauhan * sys/directsound/gstdirectsoundsink.c: directsoundsink: Fix corner case causing large CPU usage We were unnecessarily looping/goto-ing repeatedly when we had exactly the amount of data as the free space, and also when the free space was too small. This, as it turns out, is a very common scenario with Directsound on Windows. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=773681 We have to do polling here because the event notification API that Directsound exposes cannot be used with live playback since all events must be registered in advance with the capture buffer, you cannot add/remove them once playback has begun. Directsoundsrc had the same problem. See also: https://bugzilla.gnome.org/show_bug.cgi?id=781249