An application, using for example appsink, can hold buffers from any
va allocator after setting the pipeline to NULL. We need to destroy
the allocator when that memory is unrefed.
This patch juggles a bit with the allocator reference count in
memories in order to achieve this:
1. When memory is created no alloc ref is modified
2. When memory is released, alloc ref is decreased
3. When memory is reassiged to a buffer, alloc ref is increased
4. When memory is flushed, alloc ref is increased becase it is going
to be decreased in gst_memory_unref()
Also this patch moves the deallocation of member variables to
finalize() rather than dispose()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1815>
In case that "pic_order_cnt_type" is equal to zero, ref picture
list for B slice should not include non-existing picture
as per spec 8.2.4.2.3. And, the second field is not needed
for the process of frame picture reference list construction
since it needs to be frame unit, not field picture in that case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1812>
force_videometa should mean that the buffer must use video meta to
map correctly. When the stride or the offset of the alloc_info is
different from the src caps, the downstream must use video meta.
So this flag should not link with the RAW caps only. All kinds of
caps(memory:VAMemory, memory:DMABuf) should have this flag.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1711>
When the downstream element reports an ANY caps, and it also fails to
support VideoMeta, we should fallback to the system memory.
Note: the basetransform kind elements never return valid allocation
query before set_caps(). So, if a basetransform return an ANY sink
caps, we always fallback to system memory for it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1711>
Allocate a GArray which is used to fill
VAPictureParameterBufferH264.ReferenceFrames (called per frame),
instead of alloc/free per frame.
Also this commit is to fix the condition where long-term reference
picture is needed for VAPictureParameterBufferH264.ReferenceFrames
entry.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1813>
When gst_va_dmabuf_allocator_setup_buffer_full() receives info (not NULL) it is
supposed that this buffer is not part of the allocator pool, so it has to be
de-allocated as soon it is freed.
This patch sets the destroy notify of the assigned GstVaBufferSurface if info is
not NULL.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1811>
Managing reference picture type by using two variables
(ref and long_term) seems to be redundant and that can be
represented by using a single enum value.
This is to sync this implementation with gstreamer-vaapi so that
make comparison between this and gstreamer-vaapi easier and also
in order to minimize the change required for subclass to be able
to support interlaced.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1534>
This add HEVC decoding support into the new VA plugin. This implementation has
been tested using the ITU comformance test (through fluster). It fails all
MAIN10 tests, as this is not implemented yet along with the following:
CONFWIN_A_Sony_1 (looks fine, but md5sum is incorrect)
PICSIZE_A_Bossen_1 (height too high)
PICSIZE_B_Bossen_1 (same)
VPSSPSPPS_A_MainConcept_1 (parser issue)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1714>
In our va implemenation, we just use image's info to map the buffer.
The padding info just plays a role as a place holder to expand the
allocation size in caps when decoding size is bigger than display
size. So the padding_right or padding_left does not change the result.
But we find if using padding_left, it is hard to meet the requirement
of gst_video_meta_validate_alignment(), when the video meta's stride
is different from the allocation width.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1698>
We have already done the jobs in gst_va_base_dec_decide_allocation()
and no need to call base class' decide_allocation() again. The base
class' decide_allocation() will set_format() again and let use do the
image/surface testing again, which is low performance and no needed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1698>
Use this standalone function to update the allocator info and make
all ensure_image() and mem_alloc() API clean.
We also change the default way of using image. We now set the non
derive manner as the default manner, and if it fails, then fallback
to the derived image manner.
On a lot of platforms, the derived image does not have caches, so the
read and write operations have very low performance.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1698>
Moving the parameters testing and setting from the allocator_alloc_full()
to the allocator_try(). The allocator_alloc_full() will be called every
time when we need to allocate a new memory. But all these parameters such
as the surface and the image format, rt_format, etc, are unchanged during
the whole allocator lifetime. Just setting them in set_format() is enough.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1698>
Fix a bug in _create_other_pool(). The old way of checking the
base->other_pool make that other_pool never be changed until the
gst_va_base_dec_stop() to stop the current decoding context.
But in some stream, the resolution may change during the decoding
process, and we need to re-negotiate the buffer pool. Then, the
old other_pool can not be clean correctly and the new correct one
can not be created.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1692>
The current bufferpool wastes all pre-allocate buffers when the
buffer pool is actived.
The pool->priv->size is 0 for va buffer pool. And every time, the
reset_buffer() will clean all mem and make the buffer size 0, that
can cache the gst_buffer in the buffer pool.
But when the buffer pool is activing, the default_start() just
allocate the buffer and release_buffer() immediately, all the pre
allocated buffers and surfaces are destroyed because of
gst_buffer_get_size (buffer) != pool->priv->size.
We need to use release_buffer() to do the clean job at the pool
start time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1686>
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>
Without preallocating buffers and memories a deadlock in pool allocator is
highly probably since it might hit the case were buffer is returned to the pool
but their memories are still hold by a copy downstream, without other
preallocated buffers available.
This kind of a hack, where buffer_reset() follow the normal path if it's called
from start().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1667>
Every time a new surface is created the counter increases by one, and when it is
destroyed (or will be destroyed in case of GstVaAllocator), the counter is
decreased. Then, at allocator dispose, it is warning if the counter is not zero.
This counter will be also used to check if the allocator can change its
configuration if the counter is zero or can not.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1667>
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>
Renamed the first variable member of GstVaMemory from parent to mem in
order to avoid confusion with GstMemory's parent.
When freeing the structure, memory's parent is check in order to
decide if surfaces has to be destroyed or not, since only the parent
class have to destroy it.
Removed GST_MEMORY_FLAG_NO_SHARE in memory initialization, since it is
deprecated.
Implemented allocator's share virtual method which creates a new
shallow GstVaMemory structure based on the passed one which will be
it's parent.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1626>
These function were repeated in the different implemented
elements. This patch centralize them.
The side effect is dmabuf memory type is no longer checked with the
current VAContext, but assuming that dmabuf is a consequence of caps
negotiation from dynamic generated caps templates, where the context's
memory types are validated, there's no need to validate them twice.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1644>
Add a global mutex to exclusive access to shared stream buffers, such
as DMABufs or VASurfaces after a tee:
LIBVA_DRIVER_NAME=iHD \
gst-launch-1.0 v4l2src ! tee name=t t. ! queue ! \
vapostproc skin-tone=9 ! xvimagesink \
t. ! queue ! vapostproc ! xvimagesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1529>
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>
There are, in VPP, surfaces that doesn't support 4:2:2 fourccs but it
supports the chroma. So this patch gives that opportunity to the
driver.
This patch also simplifiies
gst_va_video_surface_format_from_image_format() to just an iterator
for surfaces available formats.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1529>
Add a new parameter to _create_surfaces(): a pointer to
VASurfaceAttribExternalBuffers.
If it's defined the memory type is changed to DRM_PRIME, also a new item is
added to the VASurfaceAttrib array with
VASurfaceAttribExternalBufferDescriptor.
Also, the VASurfaceAttrib for pixel format is not mandatory anymore. If fourcc
parameter is 0, is not added in the array, relying on the chroma. This is
useful when creating surfaces for uploading or downloading images.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1529>
The min latency is calculated with the maximum number of frames that
precede any frame, if available, and it is lower than the maximum
number of frames in DBP.
The max latency is calculated with the maxium size of frames in DBP.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1500>
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>
Instead of adding a list of ad-hoc formats for raw caps (I420 and
YV12), the display queries the available image formats and we assume
that driver can download frames in that available format with same
chroma of the config surfaces chroma.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1483>
All subclasses are retrieving list to get target output frame, which
can be done by baseclass. And pass the ownership of the GstH264Picture
to subclass so that subclass can clear implementation dependent resources
before finishing the frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1449>
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>
