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>
The current way of using gst_video_info_set_format() will change all
fields of the GstVideoInfo. We only need to change its format, stride
and offset fields.
In order to keep the consistency with th common drm API, we rename the
gst_va_video_info_from_dma_info() into gst_va_dma_drm_info_to_video_info().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4883>
As VK_FORMAT_FEATURE_2_xxx are defined as static const variable, the
vscoce C compiler prevents the initialization of the vk_usage_map
structure with error "C2099: initializer is not a constant".
Init the structure separately.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4904>
Adding GST_CUDA_CRITICAL_ERRORS env variable so that program can be
terminated on unrecoverable error.
Example)
GST_CUDA_CRITICAL_ERRORS=2,700 gst-launch-1.0 ...
In this example, CUDA_ERROR_OUT_OF_MEMORY(2) and
CUDA_ERROR_ILLEGAL_ADDRESS(700) are registered as critical error
and program will be aborted on those errors
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4729>
Change the internal GstVideoInfo structure in the GstVaDmabufAllocator to
GstVideoInfoDmaDrm in order to keep track of the exported DRM format by the
driver, and thus removing the DRMModifier quark attached as qdata in the
GstMemory. Though, the exposed API isn't updated yet; that has to go in a
second iteration.
Also this patch clean up some code (remove an unused buffer size assignation)
and fix some typos in documentation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4821>
Some surface formats such as GST_VIDEO_FORMAT_Y42B and GST_VIDEO_FORMAT_RGB
can be created but can not be exported as DMA buffer. You can not say that
this is a driver bug because the driver may never want to share this kind of
surface out of libva.
And this function will be used to detect modifiers later, so the error message
will be annoying.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4821>
Decoder bounded CUDA memory is allocated by driver and the pool size
is fixed. Since we don't know how many buffers would be held by
downstream non-CUDA element, we should download such CUDA memory
and release it back to decoder.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4810>
New vulkan formats don't match the number of planes with the number of memories
attached to the buffer. This patch changes the pattern of using planes for
traverse the memories with the number of attached memories.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
It's a generalization of the original gst_vulkan_get_or_create_image_view().
The reason for passing the whole VkImageViewCreateInfo structure rather than
just the missing fields, is because VkImageSubresourceRange and
VkComponentMapping can be different and those are most of VkImageViewCreateInfo.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
This is going to be used when the pool is used by a video decoder for
VK_IMAGE_USAGE_VIDEO_DECODE_DST_BIT_KHR, since the frame allocation needs the
VkVideoProfileInfoKHR, and for that here GstCaps is used to wire it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
