Always add GstTensorMeta to buffer instead of re-using existing GstTensorMeta
when it's already present. The reason for the change is when we have cascaded
inference elements overwriting (tflite) or leaking (ONNX) GstTensorMeta when we
have cascaded inferences. We didn't create and API to append to GstTensorMeta
and I think it's more convenient to have a new GstTensorMeta for each
inferences. It's also more clear that a group of tensor was produced by one
inference but doesn't limit tensordecoders from using tensors produced by
multiple inference. I don't see much value in having all tensors data always
inside one GstTensorMeta since appending would mean re-allocation of the tensors
array anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9564>
.. in decoders.
Inline session parameters allows to not create session parameters handlers for
every new stream parameters (such as SPS and PPS for H.264, for example), but
instead to pass them as a chained structure in the decoding main structure. This
is completely align with GStreamer decoder base classes.
Even that the previous approach is kept, if the devices doesn't support video
maintenance2, it shows a lot of validation errors.
Also it was required to add another parameter when enabling extension to verify
if the extension is linked with a device feature and if it is enabled.
Bump Vulkan API (and driver version for both decoders and encoders) to 1.4.306
Also bumped the ABI_CHECK_TAG because the CI finally catches up with the vulkan
video symbols that are not exposed by a public header (tough they are binary
public).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9585>
Some extensions need to have enabled certain feature in the device. This patch
does that check by adding a new field in the extension list which is a function
that can be mapped to gst_vulkan_physical_device_has_feature_*() functions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9585>
With video_maintenance1 extension is possible to create images independent of a
the video profile list, under that image will be processed.
With that extension is possible to share the same image for dynamic transcoding.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9550>
With merge request !9438 the validation layer started to complain with
VUID-VkDeviceCreateInfo-pNext-02829
This patch fixes this ill-usage of Vulkan API, by removing the feature enabling
of sampler ycbcr conversion, since it was promoted since Vulkan 1.1, and in
GStreamer is only used in Vulkan Video operations, which are only enabled in
Vulkan 1.3+.
Also, these features detection and enabling were moved to a function called when
filling the physical device data, in order to check the API version of the
device driver before adding the enabling of the feature.
Finally, the getters were adapted to use the version feature structure if the
device driver version matches.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9544>
In order to link videomaintenance1, and others to come, without knowing if
Vulkan 1.4 features are chained in the device properties structure, a static and
inlined function was added in gstvkphysicaldevice-private.h. It was added in a
header file to avoid compiler warnings if it's not used because of old Vulkan
headers.
Also the value dump videomaintenance1 was moved to another function to pack
there all the future features to query which aren't part of a Vulkan release
yet.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
This patch is the payment to my technical debt.
The symbol GST_VULKAN_HAVE_VIDEO_EXTENSIONS is defined at compilation-time if
the user requests for the usage of the Vulkan Video extensions. And we used this
symbol for anything related with Vulkan Video. But this is not the smartest
approach.
The rule should be:
- If the code allocates Vulkan Video resources, use
GST_VULKAN_HAVE_VIDEO_EXTENSIONS
- Otherwise, use the Vulkan's guard for the used API
In this way, API version bumps will be easier.
Also, this commit marks the end of GST_VULKAN_HAVE_VIDEO_EXTENSIONS guarded code
for readability.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
Both gst_vulkan_image_buffer_pool_set_config() and
gst_vulkan_image_buffer_pool_alloc() functions share the same code to create
Vulkan images for different purposes.
This patch refactor them in a new helper function that creates the images and
stores them in a buffer if it's passed as output parameters, such as the
offsets.
This patch also adds specifics guards for Vulkan's symbols for better grained
API usage, but also for prepare_buffer() the guard is set where the symbol is
used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
The Vulkan Video extensions can be available, according to the specification,
since Vulkan 1.1, but with other extensions dependencies. That's why this patch
adds a field in the extension structure, which represents the extension
dependency that the specified extension requires. And they are specified by
Vulkan Video extensions.
This allow to have a single function to check if the extension can be enabled
both by optional extensions and video extensions.
Regardless that video extension can be loaded since Vulkan 1.1, they are rather
loaded since Vulkan 1.3, when synchronization2 was promoted, so it isn't
checked as video_queue dependency.
Finally, this patch checks for each guard symbol.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
This is a continuation of !9483, but without back-porting.
Instead of checking the driver's API version to figure out if a physical device
feature is available and enabled, or even more, instead of checking for enabled
extensions in the driver, this patch adds private functions in the physical
driver to get the availability and enabling of features such as sampler ycbrc
conversion, synchronization2, timeline semaphore and video maintenance1.
And these new functions are used internally in the GstVulkanOperation object,
and the private object GstVulkanDecoder.
This approach is computationally cheaper, simpler and precise.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
For the features VkPhysicalDeviceSamplerYcbcrConversionFeaturesKHR,
VkPhysicalDeviceSynchronization2Features and
VkPhisicalDeviceTimelineSemaphoreFeatures
The Vulkan specification states:
If the `VkPhysicalDeviceXXXFeatures` structure is included in the `pNext`
chain of the `VkPhysicalDeviceFeatures2` structure passed to
`vkGetPhysicalDeviceFeatures2`, it is filled in to indicate whether each
corresponding feature is supported. If the application wishes to use a
`VkDevice` with any features described by `VkPhysicalDeviceXXXFeatures`,
it **must** add an instance of the structure, with the desired feature members
set to `VK_TRUE`, to the `pNext` chain of `VkDeviceCreateInfo` when creating
the `VkDevice`.
And that was missing in the code.
Strangely, that functionality doesn't have a Valid-Usage ID assigned, so it
isn't caught by the validation layer.
This patch adds the structures in the physical devices to get them and later set
them in the device creation.
In order to link these features, videomaintenance1, and others to come, without
knowing if Vulkan 1.3 features are chained in the device properties structure, a
static and inlined function was added in gstvkphysicaldevice-private.h. It was
added in a header file to avoid compiler warnings if it's not used because of
old Vulkan headers.
Also the value dump videomaintenance1 was moved to another function to pack
there all these queried features.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9483>
Add d3d12fisheyedewarp element that performs fisheye image dewarping
using D3D12. A UV remap LUT texture is generated via a compute shader,
and the actual remapping is performed in a pixel shader using this LUT
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9441>
Modify the API to retrieve the tensor meta to check for the dimensions
as well.
Also fix an API mistake, the buffer whose dimensions should be checheck
is the one inside the GstTensor, not another buffer some outside.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9411>
Similar to h264parse and h265parse, this patch improves the element to parse
the SEI registered user data from NAL units. The core structure of H266 SEI for
ITU-T T.35 is the same as the other parsers, so we can re-use the same logic.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9365>
