ROI (region of interest) feature implementation
in va.
It does not support ROI priority, and supports
qp delta, and the maximum number of supported
region is defined as 32, the region sequence implies
the priority, the lower the sequence number, the higher
the region priority, when region overlapping happened,
the higher priority region overwrites the lower
priority one.
And specifically for AV1, the adjust step will be
rounded by 5 when rate control is used, for example,
if qp_delta (q index) is 6, it will use 5, if
qp_delta is 8, it will use 10.
For AVC/HEVC (RC/CQP) and AV1 CQP mode, the
qp_delta granularity is 1.
Reviewed-by: Boyuan Zhang <boyuan.zhang@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26659>
add support to check jpeg crop decode cap and to set the crop
rectangle. the interface is avialble on libva 1.21.0 and higher.
v2: (Ruijing)
enclose the entire case block within VA_CHECK_VERSION
if attr unsupported set the return value to VA_ATTRIB_NOT_SUPPORTED
Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26588>
This reverts commit 578e10e157.
The only reason for reallocating surfaces as interlaced (on drivers
that supports both progressive and interlaced) was deinterlacing
with postproc filter, but that now also supports interleaved surfaces.
With this change interlaced surfaces are no longer used on radeonsi.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26174>
If application requests to map surface that was most recently used
as decoder or postproc target and also doesn't explicitly set the
map flags (vaMapBuffer2) it's very likely the intent is to read from
this surface, so we need to map it as such.
This fixes regression on radeonsi where mapping NV12 surfaces for
reading would fail with applications using vaDeriveImage. The reason
for this is that the VA frontend doesn't allow vaDeriveImage for
interlaced surfaces so the applications would use vaGetImage fallback,
but radeonsi doesn't allocate NV12 surfaces as interlaced anymore.
This also fixes mapping other formats surfaces (P010, RGBx, ...)
for reading, which never worked before.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9935
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10048
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26008>
The assert in vlVaSetSurfaceContext would very rarely fail because
the mutex was already unlocked when calling this function from
vlVaBeginPicture.
Keep the lock until returning from vlVaBeginPicture, as that's what
other functions are already doing.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25823>
Move setting the default values from getEncParamPresetH264/5 as this
function is called on each frame which would result in overwriting
values set by application.
This fixes setting HRD parameters and max_qp/min_qp when
PIPE_VIDEO_CAP_ENC_QUALITY_LEVEL is not supported.
Cc: mesa-stable
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25355>
The encoder is created in handleVAEncSequenceParameterBufferType and it
also sets some default parameters, so we need to make sure to handle
this buffer first because application may have already set those
parameters from earlier buffers.
This fixes setting HRD parameters with gstreamer vah264enc/vah265enc
when PIPE_VIDEO_CAP_ENC_QUALITY_LEVEL is supported.
Cc: mesa-stable
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25355>
Video textures include padding, so make sure to not sample outside
src rect. Also remove the parameter and always use the offset.
When not scaling, this fixes blurry output.
When scaling, this fixes incorrect color at right/bottom edge.
Acked-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24869>
Set correct matrix according to format, color standard and range.
Change default value for color range when not explicitly specified.
Use limited range for YUV and full range for RGB.
This also adds support for converting from full range YUV to RGB.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24788>
The buffer data is not directly accessible to application and it's
internally used to only store VACodedBufferSegment struct.
Ignore the size requested by application and instead allocate
sizeof(VACodedBufferSegment). Use calloc to zero out the struct.
This can save significant amount of memory, for example FFmpeg
will request up to tens of MB for single buffer.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6462
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24410>
Mapping multi-plane surfaces won't work correctly without driver
supporting PIPE_VIDEO_CAP_SUPPORTS_CONTIGUOUS_PLANES_MAP.
Remove the check for ffmpeg process and instead check for
multi-plane format and driver support only.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24381>
When decoding interlaced pics, the output surface should
also be allocated as interlaced to make the deinterlace
postproc filter work correctly.
This makes deinterlacing work for drivers that supports, but
not prefers, interlaced surfaces.
Use extra buffer instead of reallocating as non-interlaced
when exporting interlaced surfaces.
v2: Avoid reallocating in vlVaExportSurfaceHandle
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24361>
