mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-06 01:19:38 +00:00
Code Issues 1 Projects Releases Wiki Activity
gstreamer/subprojects/gst-plugins-bad/sys/va/gstvaallocator.h

85 lines
4.4 KiB
C
Raw Normal View History

va: VA-API H.264 decoder and infrastructure New plugin with an element for H.264 decoding with VA-API. This novel approach, different from gstreamer-vaapi, uses gstcodecs library for state handling. The code is expected to looks cleaner because it uses VA-API without further layers or wrappers. * It uses the first supported DRM device as default VA display (other displays will be supported through user's GstContext) * Requires libva >= 1.6 * No multiview/stereo profiles neither interlaced streams because gstcodecs doesn't handle them yet * It is incompatible with gstreamer-vaapi * Even if memory:VAMemory is exposed, it is not handled yet by any other element * Caps templates are generated dynamically querying VAAPI, but YV12 and I420 are added for system memory caps because they seem to be supported for all the drivers when downloading frames onto main memory, as they are used by xvimagesink and others, avoiding color conversion. * Surfaces aren't bounded to context, so they can grow beyond the DBP size, allowing smooth reverse playback. * There isn't yet error handling and recovery. * 10-bit H.264 streams aren't supported by libva. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1379>
2020-03-22 18:00:50 +00:00
/* GStreamer
* Copyright (C) 2020 Igalia, S.L.
* Author: Víctor Jáquez <vjaquez@igalia.com>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Library General Public License for more details.
*
* You should have received a copy of the GNU Library General Public
* License along with this library; if not, write to the
* Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
* Boston, MA 02110-1301, USA.
*/
#pragma once
#include <gst/allocators/allocators.h>
libs: va: Move the VA common logic as a lib. The VA acceleration now has more usages in linux-like platforms, such as the MSDK. The different plugins based on the VA acceleration need to share some common logic and types. We now move the display related functions and types into a common va lib. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2196>
2021-05-06 10:23:23 +00:00
#include <gst/va/gstvadisplay.h>
va: VA-API H.264 decoder and infrastructure New plugin with an element for H.264 decoding with VA-API. This novel approach, different from gstreamer-vaapi, uses gstcodecs library for state handling. The code is expected to looks cleaner because it uses VA-API without further layers or wrappers. * It uses the first supported DRM device as default VA display (other displays will be supported through user's GstContext) * Requires libva >= 1.6 * No multiview/stereo profiles neither interlaced streams because gstcodecs doesn't handle them yet * It is incompatible with gstreamer-vaapi * Even if memory:VAMemory is exposed, it is not handled yet by any other element * Caps templates are generated dynamically querying VAAPI, but YV12 and I420 are added for system memory caps because they seem to be supported for all the drivers when downloading frames onto main memory, as they are used by xvimagesink and others, avoiding color conversion. * Surfaces aren't bounded to context, so they can grow beyond the DBP size, allowing smooth reverse playback. * There isn't yet error handling and recovery. * 10-bit H.264 streams aren't supported by libva. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1379>
2020-03-22 18:00:50 +00:00
#include <gst/video/video.h>
va: allocator: Add missing header file. Added stdint.h because uintptr_t is used. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1023>
2021-10-05 04:54:25 +00:00
#include <stdint.h>
libs: va: Move the VA common logic as a lib. The VA acceleration now has more usages in linux-like platforms, such as the MSDK. The different plugins based on the VA acceleration need to share some common logic and types. We now move the display related functions and types into a common va lib. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2196>
2021-05-06 10:23:23 +00:00
#include <va/va.h>
va: VA-API H.264 decoder and infrastructure New plugin with an element for H.264 decoding with VA-API. This novel approach, different from gstreamer-vaapi, uses gstcodecs library for state handling. The code is expected to looks cleaner because it uses VA-API without further layers or wrappers. * It uses the first supported DRM device as default VA display (other displays will be supported through user's GstContext) * Requires libva >= 1.6 * No multiview/stereo profiles neither interlaced streams because gstcodecs doesn't handle them yet * It is incompatible with gstreamer-vaapi * Even if memory:VAMemory is exposed, it is not handled yet by any other element * Caps templates are generated dynamically querying VAAPI, but YV12 and I420 are added for system memory caps because they seem to be supported for all the drivers when downloading frames onto main memory, as they are used by xvimagesink and others, avoiding color conversion. * Surfaces aren't bounded to context, so they can grow beyond the DBP size, allowing smooth reverse playback. * There isn't yet error handling and recovery. * 10-bit H.264 streams aren't supported by libva. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1379>
2020-03-22 18:00:50 +00:00
G_BEGIN_DECLS
#define GST_TYPE_VA_DMABUF_ALLOCATOR (gst_va_dmabuf_allocator_get_type())
G_DECLARE_FINAL_TYPE (GstVaDmabufAllocator, gst_va_dmabuf_allocator, GST,
VA_DMABUF_ALLOCATOR, GstDmaBufAllocator);
GstAllocator * gst_va_dmabuf_allocator_new (GstVaDisplay * display);
va: allocator: rename gst_va_dmabuf_allocator_setup_buffer() Since it's related with GstVaDmabufAllocator. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1626>
2020-09-30 13:45:54 +00:00
gboolean gst_va_dmabuf_allocator_setup_buffer (GstAllocator * allocator,
va: allocator: add _set_format() and _get_format() Since allocators keep an available memory queue to reuse, video format and usage hint are now persistant while allocator's memories are around. This patch adds _set_format() and _get_format() for both VA allocators. _set_format() validates if given format can be used or reused. If no allocated surface previously it creates a dummy one to fetch its offsets and strides. Updated info is returned to callee. GstVaPool uses _set_format() at config to verify the allocator capacity and to get the surfaces offsets and strides, which are going to be used by the video meta. Allocator extracted caps are compared with caps from config and if they have different strides or offsets, force_videometa is set. A new bufferpool method gst_va_pool_requires_video_meta() is added return the value of force_videometa. This value is checked in order to know if decoders need to copy the surface if downstream doesn't announce video meta support. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1667>
2020-10-07 16:03:20 +00:00
GstBuffer * buffer);
va: implement pooled allocators 1. Allocators don't implement memory free() methods since all the memories will implement dispose() returning FALSE 2. Memory/miniobject dispose() will act as memory release, enqueueing the release memory 3. A new allocator's method prepare_buffer() which queries the released memory queue and will add the requiered memories to the buffer. 4. Allocators added a GCond to synchronize dispose() and prepare_buffer() 5. A new allocator's method flush() which will free for real the memories. While the bufferpool will 1. Remove all the memories at reset_buffer() 2. Implement acquire_buffer() calling allocator's prepare_buffer() 3. Implement flush_start() calling allocator's flush() 4. start() is disabled since it pre-allocs buffers but also calls our reset_buffer() which will drop the memories and later the buffers are ditched, something we don't want. This approach avoids buffer pre-allocation. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1626>
2020-09-30 17:35:14 +00:00
gboolean gst_va_dmabuf_allocator_prepare_buffer (GstAllocator * allocator,
GstBuffer * buffer);
void gst_va_dmabuf_allocator_flush (GstAllocator * allocator);
va: allocator: add _set_format() and _get_format() Since allocators keep an available memory queue to reuse, video format and usage hint are now persistant while allocator's memories are around. This patch adds _set_format() and _get_format() for both VA allocators. _set_format() validates if given format can be used or reused. If no allocated surface previously it creates a dummy one to fetch its offsets and strides. Updated info is returned to callee. GstVaPool uses _set_format() at config to verify the allocator capacity and to get the surfaces offsets and strides, which are going to be used by the video meta. Allocator extracted caps are compared with caps from config and if they have different strides or offsets, force_videometa is set. A new bufferpool method gst_va_pool_requires_video_meta() is added return the value of force_videometa. This value is checked in order to know if decoders need to copy the surface if downstream doesn't announce video meta support. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1667>
2020-10-07 16:03:20 +00:00
gboolean gst_va_dmabuf_allocator_set_format (GstAllocator * allocator,
GstVideoInfo * info,
guint usage_hint);
gboolean gst_va_dmabuf_allocator_get_format (GstAllocator * allocator,
GstVideoInfo * info,
guint * usage_hint);
va: VA-API H.264 decoder and infrastructure New plugin with an element for H.264 decoding with VA-API. This novel approach, different from gstreamer-vaapi, uses gstcodecs library for state handling. The code is expected to looks cleaner because it uses VA-API without further layers or wrappers. * It uses the first supported DRM device as default VA display (other displays will be supported through user's GstContext) * Requires libva >= 1.6 * No multiview/stereo profiles neither interlaced streams because gstcodecs doesn't handle them yet * It is incompatible with gstreamer-vaapi * Even if memory:VAMemory is exposed, it is not handled yet by any other element * Caps templates are generated dynamically querying VAAPI, but YV12 and I420 are added for system memory caps because they seem to be supported for all the drivers when downloading frames onto main memory, as they are used by xvimagesink and others, avoiding color conversion. * Surfaces aren't bounded to context, so they can grow beyond the DBP size, allowing smooth reverse playback. * There isn't yet error handling and recovery. * 10-bit H.264 streams aren't supported by libva. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1379>
2020-03-22 18:00:50 +00:00
va: allocator: add gst_va_dmabuf_buffer_setup() This function will take an array of DMABuf GstMemory and an array of fd, and create a VASurfaceID with those fds. Later that VASurfaceID is attached to each DMABuf through GstVaBufferSurface. In order to free the surface GstVaBufferSurface now have GstVaDisplay member, and _buffer_surface_unref() were added. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1529>
2020-08-19 14:52:10 +00:00
gboolean gst_va_dmabuf_memories_setup (GstVaDisplay * display,
GstVideoInfo * info,
guint n_planes,
GstMemory * mem[GST_VIDEO_MAX_PLANES],
uintptr_t * fds,
gsize offset[GST_VIDEO_MAX_PLANES],
guint usage_hint);
va: VA-API H.264 decoder and infrastructure New plugin with an element for H.264 decoding with VA-API. This novel approach, different from gstreamer-vaapi, uses gstcodecs library for state handling. The code is expected to looks cleaner because it uses VA-API without further layers or wrappers. * It uses the first supported DRM device as default VA display (other displays will be supported through user's GstContext) * Requires libva >= 1.6 * No multiview/stereo profiles neither interlaced streams because gstcodecs doesn't handle them yet * It is incompatible with gstreamer-vaapi * Even if memory:VAMemory is exposed, it is not handled yet by any other element * Caps templates are generated dynamically querying VAAPI, but YV12 and I420 are added for system memory caps because they seem to be supported for all the drivers when downloading frames onto main memory, as they are used by xvimagesink and others, avoiding color conversion. * Surfaces aren't bounded to context, so they can grow beyond the DBP size, allowing smooth reverse playback. * There isn't yet error handling and recovery. * 10-bit H.264 streams aren't supported by libva. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1379>
2020-03-22 18:00:50 +00:00
#define GST_TYPE_VA_ALLOCATOR (gst_va_allocator_get_type())
G_DECLARE_FINAL_TYPE (GstVaAllocator, gst_va_allocator, GST, VA_ALLOCATOR, GstAllocator);
#define GST_ALLOCATOR_VASURFACE "VAMemory"
va: allocator: support for GST_MAP_VA map flag This flag will return the VASurface value at mapping
2020-08-02 15:52:50 +00:00
#define GST_MAP_VA (GST_MAP_FLAG_LAST << 1)
va: allocator: get a surface format from a image format For the allocator to create surfaces with the correct chroma an fourcc, it should use a surface format, not necessarily the negotiated format. Instead of the previous arbitrary extra formats list, the decoder extracts the valid pixel formats from the given VA config, and pass that list to the allocator which stores it (full transfer). Then, when the allocator allocates a new surface, it looks for a surface color format chroma-compatible with the negotiated image color format. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1483>
2020-08-01 13:47:19 +00:00
GstAllocator * gst_va_allocator_new (GstVaDisplay * display,
GArray * surface_formats);
va: allocator: add _set_format() and _get_format() Since allocators keep an available memory queue to reuse, video format and usage hint are now persistant while allocator's memories are around. This patch adds _set_format() and _get_format() for both VA allocators. _set_format() validates if given format can be used or reused. If no allocated surface previously it creates a dummy one to fetch its offsets and strides. Updated info is returned to callee. GstVaPool uses _set_format() at config to verify the allocator capacity and to get the surfaces offsets and strides, which are going to be used by the video meta. Allocator extracted caps are compared with caps from config and if they have different strides or offsets, force_videometa is set. A new bufferpool method gst_va_pool_requires_video_meta() is added return the value of force_videometa. This value is checked in order to know if decoders need to copy the surface if downstream doesn't announce video meta support. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1667>
2020-10-07 16:03:20 +00:00
GstMemory * gst_va_allocator_alloc (GstAllocator * allocator);
va: pool: use allocator pool at alloc() Check if the allocator pool has memories available before creating a new one, but only iif pool is not starting. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2013>
2021-02-07 15:12:56 +00:00
gboolean gst_va_allocator_setup_buffer (GstAllocator * allocator,
GstBuffer * buffer);
va: implement pooled allocators 1. Allocators don't implement memory free() methods since all the memories will implement dispose() returning FALSE 2. Memory/miniobject dispose() will act as memory release, enqueueing the release memory 3. A new allocator's method prepare_buffer() which queries the released memory queue and will add the requiered memories to the buffer. 4. Allocators added a GCond to synchronize dispose() and prepare_buffer() 5. A new allocator's method flush() which will free for real the memories. While the bufferpool will 1. Remove all the memories at reset_buffer() 2. Implement acquire_buffer() calling allocator's prepare_buffer() 3. Implement flush_start() calling allocator's flush() 4. start() is disabled since it pre-allocs buffers but also calls our reset_buffer() which will drop the memories and later the buffers are ditched, something we don't want. This approach avoids buffer pre-allocation. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1626>
2020-09-30 17:35:14 +00:00
gboolean gst_va_allocator_prepare_buffer (GstAllocator * allocator,
GstBuffer * buffer);
void gst_va_allocator_flush (GstAllocator * allocator);
va: allocator: add _set_format() and _get_format() Since allocators keep an available memory queue to reuse, video format and usage hint are now persistant while allocator's memories are around. This patch adds _set_format() and _get_format() for both VA allocators. _set_format() validates if given format can be used or reused. If no allocated surface previously it creates a dummy one to fetch its offsets and strides. Updated info is returned to callee. GstVaPool uses _set_format() at config to verify the allocator capacity and to get the surfaces offsets and strides, which are going to be used by the video meta. Allocator extracted caps are compared with caps from config and if they have different strides or offsets, force_videometa is set. A new bufferpool method gst_va_pool_requires_video_meta() is added return the value of force_videometa. This value is checked in order to know if decoders need to copy the surface if downstream doesn't announce video meta support. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1667>
2020-10-07 16:03:20 +00:00
gboolean gst_va_allocator_set_format (GstAllocator * allocator,
GstVideoInfo * info,
guint usage_hint);
gboolean gst_va_allocator_get_format (GstAllocator * allocator,
GstVideoInfo * info,
guint * usage_hint);
va: VA-API H.264 decoder and infrastructure New plugin with an element for H.264 decoding with VA-API. This novel approach, different from gstreamer-vaapi, uses gstcodecs library for state handling. The code is expected to looks cleaner because it uses VA-API without further layers or wrappers. * It uses the first supported DRM device as default VA display (other displays will be supported through user's GstContext) * Requires libva >= 1.6 * No multiview/stereo profiles neither interlaced streams because gstcodecs doesn't handle them yet * It is incompatible with gstreamer-vaapi * Even if memory:VAMemory is exposed, it is not handled yet by any other element * Caps templates are generated dynamically querying VAAPI, but YV12 and I420 are added for system memory caps because they seem to be supported for all the drivers when downloading frames onto main memory, as they are used by xvimagesink and others, avoiding color conversion. * Surfaces aren't bounded to context, so they can grow beyond the DBP size, allowing smooth reverse playback. * There isn't yet error handling and recovery. * 10-bit H.264 streams aren't supported by libva. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1379>
2020-03-22 18:00:50 +00:00
va: remove GstVideoInfo parameter from _get_surface() functions There shouldn't be need to retrieve GstVideoInfo per buffer or memory since it is the same for all the negotiated stream. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1667>
2020-10-06 17:54:26 +00:00
VASurfaceID gst_va_memory_get_surface (GstMemory * mem);
VASurfaceID gst_va_buffer_get_surface (GstBuffer * buffer);
va: VA-API H.264 decoder and infrastructure New plugin with an element for H.264 decoding with VA-API. This novel approach, different from gstreamer-vaapi, uses gstcodecs library for state handling. The code is expected to looks cleaner because it uses VA-API without further layers or wrappers. * It uses the first supported DRM device as default VA display (other displays will be supported through user's GstContext) * Requires libva >= 1.6 * No multiview/stereo profiles neither interlaced streams because gstcodecs doesn't handle them yet * It is incompatible with gstreamer-vaapi * Even if memory:VAMemory is exposed, it is not handled yet by any other element * Caps templates are generated dynamically querying VAAPI, but YV12 and I420 are added for system memory caps because they seem to be supported for all the drivers when downloading frames onto main memory, as they are used by xvimagesink and others, avoiding color conversion. * Surfaces aren't bounded to context, so they can grow beyond the DBP size, allowing smooth reverse playback. * There isn't yet error handling and recovery. * 10-bit H.264 streams aren't supported by libva. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1379>
2020-03-22 18:00:50 +00:00
VA: Add the aux surface for gst buffer used by decoder. The AV1 codec needs to support the film grain feature. When the film grain feature is enabled, we need two surfaces as the output of the decoded picture, one without film grain effect and the other one with it. The first one acts as the reference and is needed for later pictures' reconstruction, and the second one is the real display output. So we need to attach another aux surface to the gst buffer/mem and make that aux surface as the target of vaBeginPicture. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1636>
2021-01-19 07:17:58 +00:00
gboolean gst_va_buffer_create_aux_surface (GstBuffer * buffer);
VASurfaceID gst_va_buffer_get_aux_surface (GstBuffer * buffer);
va: VA-API H.264 decoder and infrastructure New plugin with an element for H.264 decoding with VA-API. This novel approach, different from gstreamer-vaapi, uses gstcodecs library for state handling. The code is expected to looks cleaner because it uses VA-API without further layers or wrappers. * It uses the first supported DRM device as default VA display (other displays will be supported through user's GstContext) * Requires libva >= 1.6 * No multiview/stereo profiles neither interlaced streams because gstcodecs doesn't handle them yet * It is incompatible with gstreamer-vaapi * Even if memory:VAMemory is exposed, it is not handled yet by any other element * Caps templates are generated dynamically querying VAAPI, but YV12 and I420 are added for system memory caps because they seem to be supported for all the drivers when downloading frames onto main memory, as they are used by xvimagesink and others, avoiding color conversion. * Surfaces aren't bounded to context, so they can grow beyond the DBP size, allowing smooth reverse playback. * There isn't yet error handling and recovery. * 10-bit H.264 streams aren't supported by libva. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1379>
2020-03-22 18:00:50 +00:00
G_END_DECLS
Reference in a new issue Copy permalink