A client may map dmabufs without the intention to either read or write
to the memory. One example is clients wanting to use the
`gst_video_frame_map()` helper function.
Thus, in order to make buffers from `GstVaDmabufAllocator` conveniently
usable, ignore the modifier check if the client specified neither
`GST_MAP_READ` nor `GST_MAP_WRITE`.
Also skip the `va_sync_surface()` call in that case, as it's likely only
needed for CPU reads/writes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5965>
clang does not like the array index assignment without the `=` sign in
it. This is a gnu extension I believe, and adding the sign is proper.
This fixes the following two warnings:
```
../subprojects/gst-plugins-bad/gst-libs/gst/vulkan/gstvkvideo-private.c:32:40:
warning: use of GNU 'missing =' extension in designator [-Wgnu-designator]
[GST_VK_VIDEO_EXTENSION_DECODE_H264] {
^
=
../subprojects/gst-plugins-bad/gst-libs/gst/vulkan/gstvkvideo-private.c:36:40:
warning: use of GNU 'missing =' extension in designator [-Wgnu-designator]
[GST_VK_VIDEO_EXTENSION_DECODE_H265] {
^
=
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5996>
This protocol does what it says on the box, avoiding the need for a 1x1
wl_shm buffer.
A wayland-projects wrap has been added for users who do not have v1.26
available.
This commit was partly authored by Robert Mader.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2662>
The pool currently defaults to performing a layout transition to
VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL, with some special exceptions for
video usages. This may not be a legal transition depending on the usage.
Provide an API to explicitly control the initial image layout.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5881>
Since the AV1 specification is not explicitly mentioning about
the array size bounds, array sizes in scalability structure
should be defined as possible maximum sizes that can have.
Also, this commit removes GST_AV1_MAX_SPATIAL_LAYERS define from
public header which is API break but the define is misleading
and this patch is introducing ABI break already
ZDI-CAN-22300
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5823>
- AU boundary detection reviewed to follow more closely H.264 spec. and more
specifically clauses 7.4.1.2.3 and 7.4.1.2.4.
- The gist of the changes is a look-a-head in then next AU required identify the
last vcl-nal of current AU and firt vcl-nal of next AU (according to
7.4.1.2.4) followed by the identification of the first nal of next AU
(according to 7.4.1.2.3).
- A backlog of all nals of current AU and next AU up to the point where current
AU can identified completed is kept.
- In NAL alignement mode vcl-nal are sent immediatly but the history is kept to
allow AU boundary detection. Non-vcl-nal can be delayed up to the reception of
the next vcl-nal to allow a correct AUD insertion.
- Based on this improved AU boudary detection we can avoid erronous AUD
insertion, like the one highlighted by test
test_parse_sliced_with_prefix_and_sei_nal_au.
- Add support for MVC AU boundary detection. (H.7.4.1.2.4)
- Explicitly report SVC not supported. We don't have the SVC NAL parsing
required to identify boundary. (missing dependency_id and quality_id fields
from SVC, see G.7.4.1.2.4)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5741>
VA drivers allocate surfaces given their properties, so there's no need to
provide a buffer size to the VA pool.
Though, the buffer size is provided by the driver, or the canonical size
is used for single planed surfaces.
This patch removes the need to provide a size for the function
gst_va_pool_new_with_config() and adds a helper method to retrieve the surface
size, gst_va_pool_get_buffer_size(). Also change the callers accordingly.
Changes for custom VA pool creation will be addressed in the following commits.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5805>
The original idea was to select the type of mapping (either using derive images
or downloading the image) in runtime, under the assumption that both methods
shared the same memory layout (offsets and strides), because a single
GstVideoMeta is assigned by the buffer pool at allocation time. Nonetheless, in
recent hardware this assumption is invalid, raising memory access errors.
This patch removes completely the mapping type selection at runtime, using the
method selected when the allocator is configured, synced with the bufferpool
allocation.
This problem was fixed originally for iHD driver only. But now it makes sense to
remove all of it.
Original-patch-by: Mengkejiergeli Ba <mengkejiergeli.ba@intel.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5760>
When exporting a DMABuf from a VASurface the user might tell that the surface
was allocated with certain fourcc, but the returned VADRMPRIMESurfaceDescriptor
migth tell a different fourcc, as in the case or radeonsi driver, for duplicated
fourcc, such as YUY2 and YUYV.
Originally it was supposed to be a failed exportation. This patch relax this
validation by allowing different fourcc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5760>
Clip tile rows and cols to 64 as describe in AV1 specification
to avoid writing outside array range but preserve sb_cols
and sb_rows value which are used to futher computation.
Fixes ZDI-CAN-22226 / CVE-2023-44429
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5702>
Direct3D feature level 10 supported GPUs were released
more than 15 years ago, around the time when Windows
Vista / 7 were released. Also our d3d11 plugin/library
does not support feature level 9.x very well already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5709>
- GstAnalyticRelationMeta is a base class for analytics
meta. It's able to store analytics results (GstAnalyticRelatableMtd)
and describe the relation between each analysis results.
- GstAnalysisRelationMeta also contain an algorithm able to explore
analysis results relation using a bfs.
- Relation(edge) between analysis results (vertice) are stored in an adjacency-matrix
that allow to quickly identify if two analysis results are related and by
which relation they related. It also work for indirect relation
and can provide the path of analysis results by which two
analysis results are related.
- One allocation per buffer to store analysis results. Here we rely on
the application to guess how much space will be required to store all
analysis results. This is something that could be improved
significantly but it's a starting point.
- Define common analysis results, classification, object-detection,
tracking that are subclass of GstAnalyticRelatableMtd. The also
provide exemple of how to extend GstAnalyticRelatableMtd to have them
benefit for the mechanim to express relation with other analysis
results.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4962>
During the video session memory allocation, the property flags can
be different from the expected ones, so do not expect all the
property flags and test it with G_MAXUINT32
It's failing with driver 525.47.26 and NVidia HW NVIDIA GeForce
RTX 3050 and 2060
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4850>
This is how it was documented and how it worked before the port to GstPlay.
Without this, applications expecting signals to be emitted directly
without anything running the main context will simply not receive any
signals.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5672>
This commit corrects the mapping relationship between RGB and BGR in GST and DRM.
The previous mapping was incorrect, causing potential color mismatches in the output.
The changes are as follows:
{WL_SHM_FORMAT_RGB888, DRM_FORMAT_RGB888, GST_VIDEO_FORMAT_BGR},
{WL_SHM_FORMAT_BGR888, DRM_FORMAT_BGR888, GST_VIDEO_FORMAT_RGB},
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5620>
Instead of guessing the DRM format and modifier, pass a DRM video info to
gst_va_dmabuf_memories_setup().
Still, it checks for the DRM parameters in DRM info, if they are not available,
as in the case of V4L2 buffers, the part of the video info is used.
This is an API breakage, but since the plugin is still in stage, it's still
allowed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5264>
To import DMAbufs we used VASurfaceAttribExternalBuffers which works, but it's
not specific for DRM PRIME 2, since it lacks of many metadata. This patch
replaces VASurfaceAttribExternalBuffers with VADRMPRIMESurfaceDescriptor in
va_create_surfaces().
Still, this patch assumes linear modifier only.
The hack for RGB surfaces in I965 driver was pushed down into
va_create_surfaces() to avoid handling both structures.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5264>
Now that nvidia-vaapi-driver appeared and isn't yet supported by GstVA, we've to
add an allowed list of supported drivers.
This patch implements it adding a environment variable to disable this driver
check: GST_VA_ALL_DRIVERS
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5616>
