BT.2020 color primaries are designed to cover much wider range of
CIE chromaticity than BT.709, and also it's used for both SDR and HDR
contents. So, the incorrect assumption (i.e., BT.709 as a BT.2020)
is risky and resulting image color tends to be visually very wrong.
Unless there's obvious clue, don't consider color space of high resolution
video stream as BT.2020
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1445>
The ["level-asymmetry-allowed"] field states that the peer wants the
profile specified in the "profile-level-id" fields but doesn't care
about the level. To express this in GStreamer caps term, we add a
"profile" field in the caps, which reuses the usual "profile" semantics
for H.264 streams and, and remove "profile-level-id" and
"level-asymmetry-allowed" fields.
["level-asymmetry-allowed"]: https://www.iana.org/assignments/media-types/video/H264
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1410>
There's a potential race condition with this sort of pipelines on
certain systems (depends on the processing load):
GST_DEBUG_DUMP_DOT_DIR=/tmp \
gst-launch-1.0 uridecodebin3 uri=file://stream.mp4 ! glupload ! \
glimagesink --gst-debug=*:4
Right after the pipeline passes from PAUSED to READY, bin_to_dot_file
dumps uridecodebin3 properties, but current uri and suburi might be
already freed, causing a potential use-after-freed.
This patch makes NULL the current item right after all the play items
are freed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1353>
Sometimes the resampler has enough space to store all the incoming
samples without outputting anything. When this happens,
gst_audio_resampler_get_out_frames() returns 0.
In that case, the resampler should consume samples and just return.
Otherwise, we get a segfault when gst_audio_resampler_resample() tries
to resample into a NULL 'out' pointer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1343>
If the pad does not have a current caps, get_pad() returns the query
caps which can be ANY. In such case the caps does not have any structure
resulting in a critical warning when calling gst_caps_get_structure().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1254>
... in favour of dep.get_variable('foo', ..) which in some
cases allows for further cleanups in future since we can
extract variables from pkg-config dependencies as well as
internal dependencies using this mechanism.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1183>
Currently the extension data length specified in the RTP header would
say it was shorter then the data serialised to a packet. When
combining the resulting buffer, the underlying memory would still
contain the extra (now 0-filled) padding data.
This would mean that parsing the resulting RTP packet would potentially
start with a number of 0-filled bytes which many RTP formats are not
expecting.
Such usage is found by e.g. RTP header extension when allocating the
maximum buffer (which may be larger than the written size) and shrinking
to the required size the data once all the rtp header extension data has
been written.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1146>
Since commit a55dafe341, stream-scoped tags no
longer appeared as top-level tags, introducing a behaviour regression, specially
for MP3 files.
The `gst_discoverer_info_get_tags()` API now returns all tags detected for the
given media, as documented.
A new API is introduced to get container-specific tags,
`gst_discoverer_container_info_get_tags()`. The discoverer tool was adapted to
use it. `gst_discoverer_info_get_tags()` is now deprecated in favor of
`gst_discoverer_container_info_get_tags()` and
`gst_discoverer_stream_info_get_tags()`.
Fixes#759
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1107>
For monorepo build and ugly/bad, for advanced feature
option API like get_option('xyz').required(..) which
we use in combination with the 'gpl' option.
For rest of modules for consistency (people will likely
use newer features based on the top-level requirement).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1084>
In the encoded streams we might not have all the information about the
raw video stream, but when reencoding they end up being specified, even
if those are default values.
As vp8 decoders always output frames in some YUV color space we can
ensure that when upstream doesn't specify any value in its caps we
use the default one which is what we end up doing when decoding/reencoding
anyway, so this way downstream (matroskamux in that case) doesn't need
to be able to renegotiate (which it doesn't).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1062>
