Some GPUs support BGRA format and it will be converted to subsampled
YUV format by GPU internally. Disable this implicit conversion
since the conversion parameters such as input/output colorimetry
are not exposed nor it's written in bitstream (e.g., VUI).
We prefer explicit conversion via our conversion elements.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2410>
When the window is called, we properly destroy all surfaces, which effectively
will unmap that surface and should make it disapear on screen, but we also
destroy the wl_source, a GSource that is resposibble of dispatching and executing
messages to/from the Wayland server.
As a side effect, the server never gets the message and the surfaces are
"leaked" on the server. We fix this using wl_display_flush() before destroying
the wl_source.
Fixes#815
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1226>
Some manifests use the ContentProtection node to store additional information
such as the license server url. Our MPD parser used to process the
ContentProtection node, extracting Playready PSSH boxes. However for other DRM
systems, only the `value` attribute was passed down to the protection event, so
for example, Widevine data was not parsed at all and "Widevine" was passed to
the event, which is not very useful for decryptors that require a PSSH init
data.
Parsing should now be done by decryptors which will receive the entire
ContentProtection XML node as a string. This gives more "freedom" to the
decryptor which can then detect and parse custom nodes as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2400>
The VP9 streams have the ability to change the resolution dynamically
at any time point. It does not send ad KEY frame before change the
resolution, even the INTER frame can change the resolution immediately.
So we need to check the resolution change for each frame and do the
re-negiotiation if needed.
Some insaned stream may play in resolution A first and then dynamically
changes to B, and after 1 or 2 frames, it use a show_existing_frame to
repeat the old frame of resolution A before. So, not only new_picture(),
but also duplicate_picture() need to check this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2407>
Some codecs such as VP9, its config and context have the ability to
dynamically. When we only change the width and height, no need to
re-create the config and context. The helper function can just change
the resolution without re-creating config and context.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2407>
When the muxer is operating in VBR mode, it's kind of expected
for now that we might not put the PCR in exactly the right place,
because the muxer doesn't schedule packets that way. In that case
don't warn constantly about the PCR ending up a few ms off target.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2295>
The spec mandates this field be parsed using unsigned arithmetic. Nevertheless,
av1parser will use -1 apparently as an uninitialized value in
gst_av1_parse_frame_header. This immediately underflows last_frame_idx
though, since its type was defined as guint8. Fix this by converting to gint8.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2401>
When the sink goes from PLAYING to READY and then back to PLAYING,
the initialization of the audioclient in prepare() fails with the
error AUDCLNT_E_ALREADY_INITIALIZED. As a result, the playback
stops.
To fix this, we need to drop the AudioClient in unprepare() and
grab a new one in prepare() to be able to initialize it again
with the new buffer spec.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2096>
The functionality now resides in
gst_wasapi_util_get_device() and
gst_wasapi_util_get_audio_client().
This is a preparatory patch. It will be used in the following
patch to init/deinit the AudioClient separately from the device.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2096>
Previously one of the branches did not check for the property value. To
avoid this in the future, check inside the QoS calculation function
instead.
As a side effect this now always prints the debug messages into the logs
when samples are dropped, which is useful information even without the
QoS messages.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1224>
If a buffer is dropped during resyncing on a discont because either its
end offset is already before the current output offset of the
aggregator or because it fully overlaps with the part of the current
output buffer that was already filled, then don't just assume that the
next buffer is going to start at exactly the expected offset. It might
still require some more dropping of samples.
This caused the input to be mixed with an offset to its actual position
in the output stream, causing additional latency and wrong
synchronization between the different input streams.
Instead consider each buffer after a discont as a discont until the
aggregator actually resynced and starts mixing samples from the input
again.
Also update the start output offset of a new input buffer if samples
have to be dropped at the beginning. Otherwise it might be mixed too
early into the output and overwrite part of the output buffer that
already took samples from this input into account.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/912
which is a regression introduced by https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1180/
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1224>
failure to pass a display in 'handle' would result in uninitialized value
being returned, which would often segfault later down the road when trying
to initialize gstreamer context with it.
Check the return value of gst_structure_get() to make sure we return valid
data.
Furthermore, the gstglimagesink in gst-plugins-base also has a similar
mechanism but uses 'display' as field name to pass the value; instead of
requiring the application to behave differently depending on what sink
was automatically detected just try to read both values here, with display
being the new default.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2292>
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>
The current setting of color properties are not very correct and
we will get some kind of "unknown Color Standard for YUV format"
warnings printed out by drivers. The video-color already provides
some standard APIs for us, and we can use them directly.
We also change the logic to: Finding the exactly match or explicit
standard first. If not found, we continue to find the most similar
one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2385>
