ChangeLog ========= 2019-12-03 10:57:30 +0000 Tim-Philipp Müller <t...@centricular.com>
* ChangeLog: * NEWS: * RELEASE: * configure.ac: * gstreamer.doap: * meson.build: Release 1.16.2 2019-12-03 10:57:30 +0000 Tim-Philipp Müller <t...@centricular.com> * docs/plugins/inspect/plugin-coreelements.xml: * docs/plugins/inspect/plugin-coretracers.xml: Update docs 2019-12-03 10:57:29 +0000 Tim-Philipp Müller <t...@centricular.com> * po/hu.po: Update translations 2019-12-03 10:40:37 +0000 Tim-Philipp Müller <t...@centricular.com> * gst/parse/grammar.y: * gst/parse/meson.build: Revert "gst/parse: define pure-parser depending on bison version" This reverts commit 77141834bb5d124fb5781ed3be6230cc66cb42de. This breaks the autotools build and it seems too much effort to fix that up just to fix a bison warning. 2019-11-27 15:47:32 +0100 Edward Hervey <bilb...@bilboed.com> * plugins/tracers/gstlatency.c: tracers: Don't leak temporary GstStructure CID: 1455462 2019-08-26 12:48:28 +0200 Víctor Manuel Jáquez Leal <vjaq...@igalia.com> * gst/parse/grammar.y.in: * gst/parse/meson.build: gst/parse: define pure-parser depending on bison version After release bison 2.5 the declaration %pure-parser was deprecated in favor of %define api.pure Nonetheless, until bison 3.4, the declaration was treated as backward compatibility, but now bison shows a warning: warning: deprecated directive, use ‘%define api.pure’ The patch's approach is to handle both directives according with the used bison's version, by string replacement at source configuration stage. 2019-10-25 01:41:27 +0300 Sebastian Dröge <sebast...@centricular.com> * plugins/elements/gsttee.c: tee: First deactivate the pad and then remove it when releasing pads This reverts a96002bb28c21b30fb9338a4620ad20504c70aa5, which is not necessary anymore. If we release the pad after removing it then none of the deactivation code will actually be called because the pad has no parent anymore, and we require a parent on the pad for deactivation to happen. This can then, among other things, cause a streaming thread to be still stuck in a pad probe because the pad was never flushed, and waiting there forever because now the pad will actually never be flushed anymore. 2019-10-25 01:39:50 +0300 Sebastian Dröge <sebast...@centricular.com> * plugins/elements/gsttee.c: tee: Check for the removed pad flag also in the slow pushing path If a pad is currently being released we don't want to forward the FLUSHING flow return but instead consider it as NOT_LINKED. FLUSHING would also cause upstream to be FLUSHING. This part was missed in a3c4a3201a705eb1934ceeea34d1ca42d4571c07 and resulted in a different (and wrong) workaround in a96002bb28c21b30fb9338a4620ad20504c70aa5. 2019-10-25 01:39:05 +0300 Sebastian Dröge <sebast...@centricular.com> * plugins/elements/gsttee.c: tee: Lock mutex before reading the removed flag of the pads Otherwise we're not guaranteed to read the very latest value that another thread might've written in there when the pad was released, and could instead work with an old value. 2019-09-30 11:34:51 +0300 Sebastian Dröge <sebast...@centricular.com> * gst/gstbin.c: bin: Drop need-context messages without source instead of crashing 2019-09-30 11:49:35 +0300 Sebastian Dröge <sebast...@centricular.com> * gst/gstbuffer.c: * gst/gstcaps.c: gst: Don't pass miniobjects to GST_DEBUG_OBJECT() and similar macros The argument must be at least a GObject according to the GstLogFunction definition, and while the default C log function handles miniobjects just fine this is crashing bindings and user-supplied log functions that (rightfully) don't expect anything but GObjects. 2019-08-20 01:02:48 +0900 Seungha Yang <seungha.y...@navercorp.com> * tools/gst-launch.c: gst-launch: Use gst_print* instead of g_print* to fix broken stdout on Windows Concurrent Windows' colored debug message and g_print will print string hard to read. Instead, use gst_print* which serialize debug output and the APIs call. 2019-08-20 00:59:15 +0900 Seungha Yang <seungha.y...@navercorp.com> * gst/gstinfo.c: info: Take lock around all prinf on Windows On Windows, concurrent colored gstreamr debug output and usual stdout/stderr string will cause broken output on terminal. Since it's OS specific behavior, that's hard to completely avoid it but we can protect it at least among our printing interfaces side. Download ======== https://download.gnome.org/sources/gstreamer/1.16/gstreamer-1.16.2.tar.xz (3.17M) sha256sum: e3f044246783fd685439647373fa13ba14f7ab0b346eadd06437092f8419e94e _______________________________________________ ftp-release-list mailing list ftp-release-list@gnome.org https://mail.gnome.org/mailman/listinfo/ftp-release-list