On 16/11/2021 08:16, Wenbin Chen wrote:
From: nyanmisaka <[email protected]>
mfxHDLPair was added to qsv, so modify qsv->opencl map function as well.
Now the following commandline works:
ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128 \
-init_hw_device qsv=qs@va -init_hw_device opencl=ocl@va -filter_hw_device ocl \
-hwaccel qsv -hwaccel_output_format qsv -hwaccel_device qs -c:v h264_qsv \
-i input.264 -vf "hwmap=derive_device=opencl,format=opencl,avgblur_opencl, \
hwmap=derive_device=qsv:reverse=1:extra_hw_frames=32,format=qsv" \
-c:v h264_qsv output.264
Signed-off-by: nyanmisaka <[email protected]>
Signed-off-by: Wenbin Chen <[email protected]>
---
libavutil/hwcontext_opencl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index 26a3a24593..4b6e74ff6f 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -2249,7 +2249,8 @@ static int opencl_map_from_qsv(AVHWFramesContext *dst_fc,
AVFrame *dst,
#if CONFIG_LIBMFX
if (src->format == AV_PIX_FMT_QSV) {
mfxFrameSurface1 *mfx_surface = (mfxFrameSurface1*)src->data[3];
- va_surface = *(VASurfaceID*)mfx_surface->Data.MemId;
+ mfxHDLPair *pair = (mfxHDLPair*)mfx_surface->Data.MemId;
+ va_surface = *(VASurfaceID*)pair->first;
} else
#endif
if (src->format == AV_PIX_FMT_VAAPI) {
Since these frames can be user-supplied, this implies that the user-facing
API/ABI for AV_PIX_FMT_QSV has changed.
It looks like this was broken by using HDLPairs when D3D11 was introduced,
which silently changed the existing API for DXVA2 and VAAPI as well.
Could someone related to that please document it properly (clearly not all
possible valid mfxFrameSurface1s are allowed), and note in APIchanges when the
API change happened?
- Mark
_______________________________________________
ffmpeg-devel mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
