As per spec 7.4.3 Slice header semantics, the flag value is derived as
MbaffFrameFlag = (mb_adaptive_frame_field_flag && !field_pic_flag)
and DXVA uses the value.
Regarding FrameNumList, in case of long-term ref, FrameNumList[i]
value should be long_term_frame_idx not long_term_pic_num.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1780>
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>
This causes no changes to the profile but keeps the existing settings.
The profile can also be changed from e.g. the card's configuration
application and in that case probably should be left alone.
The default is the new value as it keeps the profile setting as it is,
which is consistent with the previous behaviour in 1.18.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1721>
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>
Output texture of d3d11 decoder cannot have the bind flag
D3D11_BIND_SHADER_RESOURCE (meaning that it cannot be used for shader
input resource). So d3d11convert (and it's subclasses) was copying
texture into another internal texture to use d3d11 shader.
It's obviously overhead and we can avoid texture copy for
colorspace conversion or resizing via ID3D11VideoProcessor
as it supports decoder output texture.
This commit would be a visible optimization for d3d11 decoder with
d3d11compositor use case because we can avoid texture copy per frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1718>
GstMemory object could be disposed if GstBuffer is not allocated
by GstD3D11BufferPool such as via gst_buffer_copy() and/or
gst_buffer_make_writable(). So attaching qdata on GstMemory
object would cause unnecessary view alloc/free.
By using view pool which is implemented in GstD3D11Allocator,
we can avoid redundant view alloc/free.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1716>
In order to know the chroma format, besides profile, subsampling_x and
subsampling_y are needed (Spec 7.2.2 Color config semantics). These values are
in GstVp9Parser but not in GstVp9Framehdr.
Also, bit_depth is available in parser but not frame header. Evenmore, those
values are copied to picture structure later.
In case of VA-API, to configure the pipeline, it is require to know the chroma
format and depth.
It is possible to know chroma and depth through caps coming from vp9parser, but
it requires string parsing. It would be less error prone to get these values
through the parser structure at new_sequence() virtual method.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1700>
Add new video composition element which is equivalent to compositor
and glvideomixer elements. When d3d11 decoder elements are used,
d3d11compositor can do efficient graphics memory handling
(zero copying or at least copying memory on GPU memory space).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1323>
