+=== release 1.19.2 ===
+
+2021-09-23 01:36:02 +0100 Tim-Philipp Müller <tim@centricular.com>
+
+ * ChangeLog:
+ * NEWS:
+ * RELEASE:
+ * gst-omx.doap:
+ * meson.build:
+ Release 1.19.2
+
+2021-07-09 15:14:15 +0200 Guillaume Desmottes <guillaume.desmottes@collabora.com>
+
+ * omx/gstomxvideodec.c:
+ omxvideodec: fix OMX flags on header buffer
+ The header (SPS/PPS) buffer should have the CODECONFIG flag
+ Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-omx/-/merge_requests/49>
+
+2021-07-09 14:52:59 +0200 Guillaume Desmottes <guillaume.desmottes@collabora.com>
+
+ * omx/gstomxvideodec.c:
+ omxvideodec: allow to start decoder on HEADER buffer
+ If the headers are sent in their own buffer
+ it won't have the SYNC_FRAME flag but we still
+ do want to start decoding rather than dropping it.
+ Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-omx/-/merge_requests/49>
+
+2018-09-06 21:56:57 +0000 Nicolas Dufresne <nicolas.dufresne@collabora.com>
+
+ * omx/gstomx.c:
+ * omx/gstomxh264dec.c:
+ * omx/gstomxh265dec.c:
+ * omx/gstomxvideodec.c:
+ omxh26xdec: videodecoder support subframe
+ Use of subframe API from videodecoder base class.
+ This subframe allows to decode subframe instead of
+ waiting for a whole frame.
+ The subframe uses the same frame over the whole
+ subframe passing process and will wait
+ for a signal to know the last subframe.
+ In this implementation it will use
+ GST_VIDEO_BUFFER_FLAG_MARKER as the
+ end of batch of subframes.
+ This implement subframe mode negotation for the Zynq based on caps
+ negotation. This mode can be combined with low-latency mode, in order to
+ reach the lowest possible latency (assuming the stream is within the
+ low-latency constraints for the HW).
+ ... ! video/x-h264,alignment=nal ! omxh264dec ! ...
+ Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-omx/-/merge_requests/49>
+
+2021-06-01 15:29:18 +0100 Tim-Philipp Müller <tim@centricular.com>
+
+ * meson.build:
+ Back to development
+
=== release 1.19.1 ===
2021-06-01 00:16:41 +0100 Tim-Philipp Müller <tim@centricular.com>
GStreamer 1.20 Release Notes
GStreamer 1.20 has not been released yet. It is scheduled for release
-around July 2021.
+around October/November 2021.
1.19.x is the unstable development version that is being developed in
-the git master branch and which will eventually result in 1.20, and
-1.19.1 is the current development release in that series
+the git main branch and which will eventually result in 1.20, and 1.19.2
+is the current development release in that series
-It is expected that feature freeze will be around June/July 2021,
-followed by several 1.19 pre-releases and the new 1.20 stable release
-around July 2021.
+It is expected that feature freeze will be in early October 2021,
+followed by one or two 1.19.9x pre-releases and the new 1.20 stable
+release around October/November 2021.
1.20 will be backwards-compatible to the stable 1.18, 1.16, 1.14, 1.12,
1.10, 1.8, 1.6,, 1.4, 1.2 and 1.0 release series.
See https://gstreamer.freedesktop.org/releases/1.20/ for the latest
version of this document.
-Last updated: Sunday 30 May 2021, 16:00 UTC (log)
+Last updated: Wednesday 22 September 2021, 18:00 UTC (log)
Introduction
Possibly Breaking Changes
- this section will be filled in in due course
+- MPEG-TS SCTE-35 API changes (FIXME: flesh out)
+- gst_parse_launch() and friends now error out on non-existing
+ properties on top-level bins where they would silently fail and
+ ignore those before.
Known Issues
1.20.0
-1.20.0 is scheduled to be released around July 2021.
+1.20.0 is scheduled to be released around October/November 2021.
Schedule for 1.22
Our next major feature release will be 1.22, and 1.21 will be the
unstable development version leading up to the stable 1.22 release. The
-development of 1.21/1.22 will happen in the git master branch.
+development of 1.21/1.22 will happen in the git main branch.
-The plan for the 1.22 development cycle is yet to be confirmed, but it
-is hoped that feature freeze will take place some time in December 2021.
+The plan for the 1.22 development cycle is yet to be confirmed.
1.22 will be backwards-compatible to the stable 1.20, 1.18, 1.16, 1.14,
1.12, 1.10, 1.8, 1.6, 1.4, 1.2 and 1.0 release series.