Don't update info's size with the VA image reported data size for single plane
images, since drivers might allocate bigger space than the strictly required to
store the image, but when we dump the buffer as is (using filesink, for example)
the produced stream is corrupted. For multi-plane images video meta is required
to read/write them.
We updated info's size because gstreamer-vaapi did it too, but the reason to
update it there was for uploading and rendering surfaces (commit c698a015).
Furthermore, this patch adds an error message if the allocated data size for the
image by the driver is lesser than the expected because it would be a buggy
driver.
Fixes: #2959
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5308>
Even if the segmentation feature value is not updated,
the parsed "segmentation_update_map" and "segmentation_temporal_update"
values should not be cleared as it's referenced during lower
level bitstream parsing. Also, don't use assert() in parser
unless it's clearly impossible condition.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5334>
If DPB is full already, GstH265Decoder::new_picture() might fail if
subclass uses fixed size picture pool and its size is equal to the DPB
size. Call the new_picture() after DPB is cleared in gst_h265_decoder_dpb_init()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5333>
It is similar to NV12 but has 10bits per channel instead of 8.
As it is supported by many modern GPUs, VA-API and an increasing
number of Wayland compositors, let's support it as well.
Also bump the required libdrm version accordingly and add a temporary
define for the WL_SHM format.
Tested with Weston, Mutter and Sway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5275>
Old versions of mesa doesn't support VASurfaceAttribDRMFormatModifiers. To
solve it, by just ignoring the modifiers assuming that linear is accepted and
produced, the creation of frames will be tried again without that attribute.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5256>
Setting the surface source rectangle has been omitted so far. As a side effect
surface created with padded width/height are being scaled down. Fix this using
the viewporter source rectangle configuration. This can later be enhanced
to support crop meta.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5259>
Section 3.4 in RFC8835 states that if a WebRTC endpoint uses an HTTP
proxy to access the Internet it MUST include the "ALPN" header. This
commit adds this header.
By default the ALPN used when connecting to the TURN/TCP server via a
proxy is set to "webrtc". It can be changed by adding an alpn url
option for the http-proxy. For example:
http://user:pass@my.http.proxy.com:8080?alpn=c-webrtc
This will add the header "ALPN: c-webrtc" to the HTTP proxy CONNECT
request.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4212>
Pass GstVideoInfoDmaDrm or GstVideoInfo whenever possible, avoiding passing
strange combination of GstVieoFormat + modifier. Even though we don't have any
at the moment, this also allow supporting GstVideoFormat that are not supported
in our DRM integration.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5120>
Rework the va_map_unlocked() after we keep mapping behavior (whether to
use derive) consistent with allocator_try stage. Also remove the flag
for iHD case because pitch/stride difference between vaCreateImage and
vaDeriveImage only possibly happen on iHD by now.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5046>
In gst_va_allocator_try, the first try is to use derive_image, if it
succeeds, we should use info from derived image to create bufferpool.
If derive fails, then try create_image and give created image info
to the pool.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5046>
There's no reason to release GstMemory manually at all.
If we do release GstMemory, corresponding GstBuffer will be
discarded by GstBufferPool baseclass because the size is changed
to zero.
Actual cause of heavy CPU usage in case of fixed-size pool
(i.e., decoder output buffer pool) and if we remove GstMemory from
GstBuffer is that GstBufferPool baseclass is doing busy wait in acquire_buffer()
for some reason. That needs to be investigated though, discarding
and re-alloc every GstBuffer is not ideal already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4935>
