Currently it always copies the metadata fields from the last input when
there are multiple inputs for the filter. For example, the metadata
fields from input1 are copied to the output for overlay_qsv filter,
however for regular overlay filters, the metadata fields from input0 are
copied to the output. With this fix, we may copy the metadata fields
from input0 to the ouput as well.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
It is possible that ff_progress_frame_await() is called but
ff_progress_frame_report() isn't called when a hardware acceleration
method is used, so a thread for vp9 decoding might get stuck.
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Otherwise there are link errors:
LD ffprobe_g
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to
`ff_dovi_rpu_generate'
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to
`ff_dovi_configure'
collect2: error: ld returned 1 exit status
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
By default don't use the color properties from input frame as output
frame properties when performing HDR to SDR conversion
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
libva2 doesn't require a fixed surface-array any more, so we may use
dynamic frame pool for decoding when libva2 is available, which allows a
downstream element stores more frames from VAAPI decoders and fixes the
error below:
$ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi \
-i input.mp4 -c:v hevc_vaapi -f null -
...
[h264 @ 0x557a075a1400] get_buffer() failed
[h264 @ 0x557a075a1400] thread_get_buffer() failed
[h264 @ 0x557a075a1400] decode_slice_header error
[h264 @ 0x557a075a1400] no frame!
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Otherwise the derived device and the source device might have different
PCI ID in a multiple-device system.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
When all cached frames are drained, the output mfxSyncPoint pointer is
NULL and MFX_ERR_MORE_DATA is returned, hence needn't print warning for
this expected behavior, otherwise the user might think the output from
qsv decoders are wrong.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The runtime doesn't set the frame type to MFX_FRAMETYPE_IDR on the
returned mfx bitstream for a keyframe, it set the frame type to
MFX_FRAMETYPE_I only. This patch added workaround for VP9 keyframe to
make the coded stream seekable.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
option kernel_driver for vaapi device creation can be used to choose the
desired device on Linux, which is more convenient than DRM render node
in a multiple-device system (e.g. Intel iGPU + AMD dGPU or inverse), but
this option requires libdrm works. vaapi is autodetected at
configuration time, let's make libdrm autodetected too.
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
When multiple hardwares are available, the default one might not be
Intel Hardware. We can use option vendor_id to choose the required
vendor.
Tested-by: Artem Galin <artem.galin@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Both qsv encoders and decoders use 4 as the default value of
async_depth, let's use 4 as the default value for vpp_qsv filter too.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
mfxExtendedDeviceId mightn't be supported in certain configurations of
oneVPL on Linux, so we can't ensure a property filter for
mfxExtendedDeviceId.DeviceID or mfxExtendedDeviceId.VendorID works as
expected. This fixed the issue mentioned in [1]
[1] http://ffmpeg.org/pipermail/ffmpeg-user/2023-October/056983.html
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The type of qsv decoders is FF_CODEC_CB_TYPE_DECODE which must not
return AVERROR(EAGAIN). commit 42b20c9 added an assertion to check the
returned value.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
libvpl deprecated some symbols (e.g. MFX_EXTBUFF_VPP_DENOISE2 is used to
replace MFX_EXTBUFF_VPP_DENOISE), however the new symbols aren't support
by MediaSDK runtime. In order to support the combination of libvpl and
MediaSDK runtime on legacy devices, we continue to use the deprecated
symbols in FFmpeg. This patch added -DMFX_DEPRECATED_OFF to CFLAGS to
silence the corresponding compilation warnings.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
User may set color range / matrix coefficient set / primaries / transfer
characteristics for output.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
libavutil/hwcontext_qsv.c: In function ‘qsv_map_to’:
libavutil/hwcontext_qsv.c:1905:47: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
glcontext was added under CONFIG_SDL2
libavdevice/opengl_enc.c: In function ‘opengl_draw’:
libavdevice/opengl_enc.c:1204:15: error: ‘OpenGLContext’ has no member
named ‘glcontext’
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The HDR metadata should be removed after HDR to SDR conversion,
otherwise the output frame still has HDR side data.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
We will postpone the vpp session initialization to when input and output
frames are ready, this copy of the sequence parameters will be used to
initialize vpp session.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Intel MediaSDK and oneVPL expect continuous allocation for data[i],
however there are mandatory padding bytes between data[i] and data[i+1].
when calling av_frame_get_buffer. This patch removes all extra padding
bytes.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The data copy is unnecessary for packed formats when frame width and
height are aligned
For example:
$ ffmpeg -f lavfi -i testsrc=size=1920x1088 -vf "format=yuyv422" -c:v hevc_qsv -f null -
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The mfx implementation based on D3D11 is expected for an internal
session on Windows, however sometimes this implemntation is not
supported [1]. A fallback to the default mfx implementation is added in
this patch.
[1] https://github.com/intel/cartwheel-ffmpeg/issues/246
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Otherwise main and overlay videos share the same input region. Note NULL
pointer imples the whole overlay video will be processed.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Otherwise the output format is not changed when output is in system
memory. For example, the output format is still p010le in the following
case:
$ ffmpeg -qsv_device /dev/dri/renderD128 -f lavfi -i testsrc -vf
"format=p010le,vpp_qsv=extra_hw_frames=8:format=nv12" -f null -
...
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf60.4.100
Stream #0:0: Video: wrapped_avframe, p010le(tv, progressive), 320x240
[SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
It only works on Linux
$ ffmpeg -loglevel verbose -init_hw_device qsv=intel -f lavfi -i \
yuvtestsrc -vf "format=uyvy422,vpp_qsv=format=nv12" -f null -
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
QSVDeintContext and VPPContext have the same base context, and all
features in deinterlace_qsv are implemented in vpp_qsv filter, so
deinterlace_qsv can be taken as a special case of vpp_qsv filter, and we
may use VPPContext with a different option array, preinit callback and
support pixel formats to implement deinterlace_qsv, then remove
QSVDeintContext.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Like what we did for scale_qsv filter, we use QSVVPPContext as a base
context to manage MFX session for deinterlace_qsv filter.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
This is used to control the output at frame rate or field rate when
deinterlace is expected and framerate is not specified.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
QSVScaleContext and VPPContext have the same base context, and all
features in scale_qsv are implemented in vpp_qsv filter, so scale_qsv
can be taken as a special case of vpp_qsv filter, and we may use
VPPContext with a different option array, preinit callback and supported
pixel formats to implement scale_qsv then remove QSVScaleContext
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Use QSVVPPContext as a base context of QSVScaleContext, hence we may
re-use functions defined for QSVVPPContext to manage MFX session for
scale_qsv filter.
In addition, system memory has been taken into account in
QSVVVPPContext, we may add support for non-QSV pixel formats in the
future.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The same members between QSVVPPContext and VPPContext are removed from
VPPContext, and async_depth is moved from QSVVPPParam to QSVVPPContext
so that all QSV filters using QSVVPPContext may support async depth.
In addition, we may use QSVVPPContext as base context in other QSV
filters in the future so that we may re-use functions defined in
qsvvpp.c for other QSV filters.
This commit shouldn't change the functionality of vpp_qsv / overlay_qsv.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
This is in preparation for reusing the code for other QSV filters. E.g.
deinterlacing_qsv may have an option array without format option
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
QSV filters may set this flag in preinit callback to turn on / off pass
through mode
This is in preparation for reusing the code for other QSV filters. E.g.
scale_qsv filter doesn't support pass through mode.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Set the expected default value for options in this callback, hence we
have the right values even if these options are not included in the
option arrray.
This is in preparation for reusing the code for other QSV filters.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Special values are:
0 = original width/height
-1 = keep original aspect
This is in preparation for reusing the code for other QSV filters.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
This patch provides default value if the expression is NULL.
This is in preparation for reusing the code for other QSV filters.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Also fix the naming style in enum var_name.
This is in preparation for reusing the code for other QSV filters.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
PI, PHI and E are defined in libavutil/eval.c, and user may use these
constants for scale_qsv filter, so we needn't re-define these variables
in vf_scale_qsv.c
Reviewed-by: Gyan Doshi <ffmpeg@gyani.pro>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
VPP in the SDK requires the frame rate to be set to a valid value,
otherwise init will fail, so always set a default framerate when the
input link doesn't have a valid framerate.
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The SDK will return error if feeding h264_qsv encoder p010 input.
$ ffmpeg -f lavfi -i testsrc -vf "format=p010" -c:v h264_qsv -f null -
[...]
[h264_qsv @ 0x55584888b080] Current pixel format is unsupported
[h264_qsv @ 0x55584888b080] some encoding parameters are not supported
by the QSV runtime. Please double check the input parameters.
Error initializing output stream 0:0 -- Error while opening encoder for
output stream #0:0 - maybe incorrect parameters such as bit_rate, rate,
width or height
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The SDK may provides HDR metadata for HDR streams via mfxExtBuffer
attached on output mfxFrameSurface1
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The next commit and other commits in future will use more ExtParam
buffers.
And combine 2 free functions into single one
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
qsvenc makes a copy when the input in system memory is not padded as the
SDK requires, however the padding area is not filled with right data
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
HEVC spec has CRA frame which allows random access with open GOP, hence
it can achieve higher compression efficiency.
Removing the entry was suggested by Andreas
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
XV30 is used for 10bit 4:4:4 content in FFmpeg VAAPI, so XV30 should be
used for 10bit 4:4:4 content in FFmpeg QSV too because QSV is based on
VAAPI on Linux. However the SDK only declares support for Y410 but does
nothing with the alpha in Y410, so this commit fudged a mapping between
AV_PIX_FMT_XV30 and MFX_FOURCC_Y410.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
We can't get Shift from bit depth for some formats in the SDK. For
example, bit depth is 10, however Shift is 0 for Y410 (XV30 in FFmpeg).
In order to support these formats in the next commits, this patch
specified Shift for each format
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The current pbc might be small for an obu frame, so a new pbc is
required then parse this obu frame again. Because
CodedBitstreamAV1Context has already been updated for this obu frame, we
need to restore CodedBitstreamAV1Context, otherwise
CodedBitstreamAV1Context doesn't match this obu frame when parsing obu
frame again, e.g. CodedBitstreamAV1Context.order_hint.
$ ffmpeg -i input.ivf -c:v copy -f null -
[...]
[av1_frame_merge @ 0x558bc3d6f880] ref_order_hint[i] does not match
inferred value: 20, but should be 22.
[av1_frame_merge @ 0x558bc3d6f880] Failed to write unit 1 (type 6).
[av1_frame_merge @ 0x558bc3d6f880] Failed to write packet.
[obu @ 0x558bc3d6e040] av1_frame_merge filter failed to send output
packet
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
AV_PIX_FMT_VUYX is used in FFmpeg and MFX_FOURCC_AYUV is used in the SDK
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
AV_PIX_FMT_VUYX is used for 8bit 4:4:4 content in FFmpeg VAAPI, so
AV_PIX_FMT_VUYX should be used for 8bit 4:4:4 content in FFmpeg QSV too
because QSV is based on VAAPI on Linux. However the SDK only declares
support for AYUV and does nothing with the alpha, so this commit fudged
a mapping between AV_PIX_FMT_VUYX and MFX_FOURCC_AYUV.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Currently AVBR is disabled and VBR is the default method if maxrate is
not specified on Linux, but AVBR is the default one if maxrate is not
specified on Windows. In order to make user experience better accross
Linux and Windows, use VBR by default on Windows if maxrate is not
specified. User need to set both avbr_accuracy and avbr_convergence to
non-zero explicitly and not to specify maxrate if AVBR is expected.
In addition, AVBR works for H264 and HEVC only in the SDK.
$ ffmpeg.exe -v verbose -f lavfi -i yuvtestsrc -vf "format=nv12" -c:v
vp9_qsv -f null -
Haihao Xiang
