aboutsummaryrefslogtreecommitdiffstats
path: root/libavutil/hwcontext_qsv.c
Commit message (Collapse)AuthorAgeFilesLines
* all: fix typos found by codespellTimo Rothenpieler7 days1-7/+7
|
* avutil/hwcontext_qsv: fix format specifier for HRESULTKacper Michajłow7 days1-10/+10
| | | | Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
* lavu/hwcontext_qsv: Use vendor id to create deviceFei Wang2024-08-091-2/+2
| | | | | | | | | | New kernel driver "xe" will be supported from Lunar Lake instead of "i915". "xe" kernel driver: https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/xe Signed-off-by: Fei Wang <fei.w.wang@intel.com>
* lavu/hwcontext_qsv: Derive bind flag from frame type if no valid surfaceFei Wang2024-07-301-2/+5
| | | | | | | | | | Fix cmd: ffmpeg.exe -init_hw_device d3d11va=d3d -init_hw_device qsv=qsv@d3d \ -filter_hw_device d3d -hwaccel qsv -hwaccel_output_format qsv \ -i in.h264 -vf "hwmap,format=d3d11,hwdownload,format=nv12" -y out.yuv Signed-off-by: Fei Wang <fei.w.wang@intel.com> Tested-by: Tong Wu <wutong1208@outlook.com>
* qsv: Initialize impl_valueMichael Niedermayer2024-05-281-4/+4
| | | | | | | | | | | Fixes: The warnings from CID1598553 Uninitialized scalar variable Passing partly initialized structs is ugly and asking for hard to rieproduce bugs, The uninitialized fields where not used Reviewed-by: "Xiang, Haihao" <haihao.xiang-at-intel.com@ffmpeg.org> Sponsored-by: Sovereign Tech Fund Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avutil/hwcontext_qsv: fix GCC 14.1 warningsoltolm2024-05-211-8/+25
| | | | | Tested-by: Tong Wu <tong1.wu@intel.com> Signed-off-by: oltolm <oleg.tolmatcev@gmail.com>
* lavu/hwcontext_qsv: add support for dynamic frame pool in qsv_map_toHaihao Xiang2024-05-201-2/+129
| | | | | | Make it work with the source which has a dynamic frame pool. Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* lavu/hwcontext_qsv: add support for dynamic frame pool in qsv_frames_derive_toHaihao Xiang2024-05-201-7/+54
| | | | | | Make it work with the source which has a dynamic frame pool. Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* lavu/hwcontext_qsv: create dynamic frame pool if requiredHaihao Xiang2024-05-201-3/+154
| | | | | | | | | When AVHWFramesContext.initial_pool_size is 0, a dynamic frame pool is required. We may support this under certain conditions, e.g. oneVPL 2.9+ support dynamic frame allocation, we needn't provide a fixed frame pool in the mfxFrameAllocator.Alloc callback. Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* lavu/hwcontext_qsv: update AVQSVFramesContext to support dynamic frame poolHaihao Xiang2024-05-201-2/+2
| | | | | | Add AVQSVFramesContext.info and update the description. Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* avutil/hwcontext_qsv: Fix mixed declaration and codeAndreas Rheinhardt2024-03-251-2/+2
| | | | | Reviewed-by: Xiang, Haihao <haihao.xiang@intel.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* lavu/hwcontext_qsv: Join the download/upload session to the main sessionHaihao Xiang2024-03-181-0/+24
| | | | | | | This may reduce the number of internal threads when using hwupload or hwdownload filter. Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* avutil/hwcontext: Allocate AVHWFramesCtx jointly with its internalsAndreas Rheinhardt2024-03-071-3/+3
| | | | | | | | | | | This is possible because the lifetime of these structures coincide. It has the advantage of allowing to remove AVHWFramesInternal from the public header; given that AVHWFramesInternal.priv is no more, most accesses to AVHWFramesInternal are no more; indeed, the only field accessed of it outside of hwcontext.c is the internal frame pool, making this commit very simple. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/hwcontext_qsv: Allocate pub and priv frames hwctx togetherAndreas Rheinhardt2024-03-051-21/+25
| | | | | | | | | This is possible because the lifetime of both coincide. Besides reducing the number of allocations this also simplifies access to QSVFramesContext as one no longer has to go through AVHWFramesInternal. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/hwcontext_qsv: Allocate public and priv device hwctx togetherAndreas Rheinhardt2024-03-051-7/+11
| | | | | | | | | This is possible because the lifetime of both coincide. Besides reducing the number of allocations this also simplifies access to QSVDeviceContext as one no longer has to go through AVHWDeviceInternal. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* lavu/hwcontext_qsv: Make sure hardware vendor is Intel for qsv on d3d11vaHaihao Xiang2023-12-071-0/+6
| | | | | | | | | 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>
* lavu/hwcontext_qsv: use mfxImplDescription instead of mfxExtendedDeviceId on ↵Haihao Xiang2023-12-051-4/+4
| | | | | | | | | | | | | Linux 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>
* lavu/hwcontext_qsv: silence the warningHaihao Xiang2023-07-311-1/+1
| | | | | | | | 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>
* lavu/hwcontext_qsv: fix memory leak for d3d9 implTong Wu2023-06-251-2/+10
| | | | Signed-off-by: Tong Wu <tong1.wu@intel.com>
* lavu/hwcontext_qsv: fix memory leak for d3d11va implTong Wu2023-06-251-4/+8
| | | | Signed-off-by: Tong Wu <tong1.wu@intel.com>
* avutil/hwcontext_qsv: register free function for device_deriveTong Wu2023-06-251-0/+9
| | | | | | | | | When qsv device is created by device_derive, the ctx->free function is not registered, causing potential memory leak because of not properly closing the MFX session. Signed-off-by: Tong Wu <tong1.wu@intel.com> Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
* lavu/hwcontext_qsv: Update after adding support for VAAPI on WindowsSil Vilerino2023-04-241-2/+12
| | | | | | | | | | | | | - qsv_internal.h: Remove unnecessary include va_drm.h - qsv_internal.h: Enable AVCODEC_QSV_LINUX_SESSION_HANDLE on Linux/VA only - hwcontext_qsv.c: Do not allow child_device_type VAAPI for Windows until support is added, keep D3D11/DXVA2 as more prioritary defaults. Initial review at https://github.com/intel-media-ci/ffmpeg/pull/619/ Signed-off-by: Sil Vilerino <sivileri@microsoft.com> Reviewed-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Reviewed-by: Wu, Tong1 <tong1.wu@intel.com>
* qsv: remove CONFIG_VAAPI for mutiple formatsTong Wu2023-02-221-3/+3
| | | | | | | | | Remove CONFIG_VAAPI for VUYX, YUYV422, Y210, XV30, Y212, XV36. Make 8-bit, 10-bit, 12-bit YUV 4:2:2 video sources as well as YUV 4:4:4 video sources supported by d3d11va and dxva2 just like what VAAPI does. Sign-off-by: Tong Wu <tong1.wu@intel.com>
* lavu/hwcontext_qsv: add support for UYVYHaihao Xiang2023-02-071-0/+7
| | | | | | | | | | | | | | The SDK supports UYVY from version 1.17, and VPP may support UYVY input on Linux [1] $ ffmpeg -loglevel verbose -init_hw_device qsv=intel -f lavfi -i \ yuvtestsrc -vf \ "format=uyvy422,hwupload=extra_hw_frames=32,vpp_qsv=format=nv12" \ -f null - [1] https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/samples/readme-vpp_linux.md Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* lavu/hwcontext_qsv: add support for 12bit content on LinuxFei Wang2022-10-101-0/+24
| | | | | | | | | | | | P012, Y212 and XV36 are used for 12bit content in FFmpeg VAAPI, so these formats should be used in FFmpeg QSV too, however the SDK only declares support for P016, Y216 and Y416. So this commit fudged mappings between AV_PIX_FMT_P012 and MFX_FOURCC_P016, AV_PIX_FMT_Y212 and MFX_FOURCC_Y216, AV_PIX_FMT_XV36 and MFX_FOURCC_Y416. Signed-off-by: Fei Wang <fei.w.wang@intel.com> Signed-off-by: Wenbin Chen <wenbin.chen@intel.com> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* lavu/hwcontext_qsv: add support for 10bit 4:4:4 content on LinuxHaihao Xiang2022-10-101-0/+7
| | | | | | | | | | 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>
* lavu/hwcontext_qsv: specify Shift for each formatHaihao Xiang2022-10-101-8/+19
| | | | | | | | | 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>
* lavu/hwcontext_qsv: add support for AV_PIX_FMT_VUYX on LinuxHaihao Xiang2022-09-071-0/+12
| | | | | | | | | | | 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>
* lavu/hwcontext_qsv: make qsv hwdevice works with oneVPLHaihao Xiang2022-08-121-38/+494
| | | | | | | | | | | | | | | | | | In oneVPL, MFXLoad() and MFXCreateSession() are required to create a workable mfx session[1] Add config filters for D3D9/D3D11 session (galinart) The default device is changed to d3d11va for oneVPL when both d3d11va and dxva2 are enabled on Microsoft Windows This is in preparation for oneVPL support [1] https://spec.oneapi.io/versions/latest/elements/oneVPL/source/programming_guide/VPL_prg_session.html#onevpl-dispatcher Co-authored-by: galinart <artem.galin@intel.com> Signed-off-by: galinart <artem.galin@intel.com> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* qsv: restrict OPAQUE memory to MFX_VERSION < 2.0Haihao Xiang2022-08-121-15/+41
| | | | | | | | OPAQUE memory isn't supported for MFX_VERSION >= 2.0[1][2]. This is in preparation for oneVPL support [1] https://spec.oneapi.io/versions/latest/elements/oneVPL/source/VPL_intel_media_sdk.html#msdk-full-name-feature-removals [2] https://github.com/oneapi-src/oneVPL
* qsv: remove mfx/ prefix from mfx headersHaihao Xiang2022-08-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The following Cflags has been added to libmfx.pc, so mfx/ prefix is no longer needed when including mfx headers in FFmpeg. Cflags: -I${includedir} -I${includedir}/mfx Some old versions of libmfx have the following Cflags in libmfx.pc Cflags: -I${includedir} We may add -I${includedir}/mfx to CFLAGS when running 'configure --enable-libmfx' for old versions of libmfx, if so, mfx headers without mfx/ prefix can be included too. If libmfx comes without pkg-config support, we may do a small change to the settings of the environment(e.g. set -I/opt/intel/mediasdk/include/mfx instead of -I/opt/intel/mediasdk/include to CFLAGS), then the build can find the mfx headers without mfx/ prefix After applying this change, we won't need to change #include for mfx headers when mfx headers are installed under a new directory. This is in preparation for oneVPL support (mfx headers in oneVPL are installed under vpl directory)
* qsv: add requirement for the mininal version of libmfxHaihao Xiang2022-05-251-2/+0
| | | | | | | | | | libmfx 1.28 was released 3 years ago, it is easy to get a greater version than 1.28. We may remove lots of compile-time checks if adding the requirement for the minimal version in the configure script. Reviewed-by: softworkz <softworkz@hotmail.com> Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* avutil/hwcontext_qsv: fix mapping issue between QSV frames and D3D11VA framesTong Wu2022-05-231-3/+4
| | | | | | | | | | | | Fixes: $ ffmpeg.exe -init_hw_device d3d11va=d3d11 -init_hw_device \ qsv=qsv@d3d11 -s:v WxH -pix_fmt nv12 -i input.yuv -vf \ "hwupload=extra_hw_frames=16,hwmap=derive_device=d3d11va,format=d3d11,\ hwmap=derive_device=qsv,format=qsv" -f null - Reviewed-by: Soft Works <softworkz@hotmail.com> Signed-off-by: Tong Wu <tong1.wu@intel.com> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* avutil/hwcontext_qsv: derive QSV frames to D3D11VA framesTong Wu2022-05-231-3/+13
| | | | | | | | | | | Fixes: $ ffmpeg.exe -y -hwaccel qsv -init_hw_device d3d11va=d3d11 \ -init_hw_device qsv=qsv@d3d11 -c:v h264_qsv -i input.h264 \ -vf "hwmap=derive_device=d3d11va,format=d3d11" -f null - Reviewed-by: Soft Works <softworkz@hotmail.com> Signed-off-by: Tong Wu <tong1.wu@intel.com> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* libavutil/hwcontext_qsv: Align width and heigh when download qsv frameWenbin Chen2022-04-131-5/+42
| | | | | | | | | | | | The width and height for qsv frame to download need to be aligned with 16. Add the alignment operation. Now the following command works: ffmpeg -hwaccel qsv -f rawvideo -s 1920x1080 -pix_fmt yuv420p -i \ input.yuv -vf "hwupload=extra_hw_frames=16,format=qsv,hwdownload, \ format=nv12" -f null - Signed-off-by: Wenbin Chen <wenbin.chen@intel.com> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* lavu/hwcontext_qsv: fix a potential infinite loopAnton Khirnov2022-02-151-49/+31
| | | | | Current code will loop forever if MFXVideoVPP_Init() fails. Also, simplify the code.
* avutil/hwcontext_qsv: fix typoTimo Rothenpieler2022-01-291-1/+1
|
* libavutil/hwcontext_opencl: fix a bug for mapping qsv frame to openclnyanmisaka2022-01-291-0/+34
| | | | | | | | | | | | | | | 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 <nst799610810@gmail.com> Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
* Revert "avutils/hwcontext: When deriving a hwdevice, search for existing ↵Haihao Xiang2022-01-051-10/+3
| | | | | | | | | | device in both directions" This reverts commit a4289497755386435783774a4f520eb7fc23cbc9. There were objections on ML (see https://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/290530.html) Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* avutils/hwcontext: When deriving a hwdevice, search for existing device in ↵Soft Works2022-01-051-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | both directions The test /libavutil/tests/hwdevice checks that when deriving a device from a source device and then deriving back to the type of the source device, the result is matching the original source device, i.e. the derivation mechanism doesn't create a new device in this case. Previously, this test was usually passed, but only due to two different kind of flaws: 1. The test covers only a single level of derivation (and back) It derives device Y from device X and then Y back to the type of X and checks whether the result matches X. What it doesn't check for, are longer chains of derivation like: CUDA1 > OpenCL2 > CUDA3 and then back to OpenCL4 In that case, the second derivation returns the first device (CUDA3 == CUDA1), but when deriving OpenCL4, hwcontext.c was creating a new OpenCL4 context instead of returning OpenCL2, because there was no link from CUDA1 to OpenCL2 (only backwards from OpenCL2 to CUDA1) If the test would check for two levels of derivation, it would have failed. This patch fixes those (yet untested) cases by introducing forward references (derived_device) in addition to the existing back references (source_device). 2. hwcontext_qsv didn't properly set the source_device In case of QSV, hwcontext_qsv creates a source context internally (vaapi, dxva2 or d3d11va) without calling av_hwdevice_ctx_create_derived and without setting source_device. This way, the hwcontext test ran successful, but what practically happened, was that - for example - deriving vaapi from qsv didn't return the original underlying vaapi device and a new one was created instead: Exactly what the test is intended to detect and prevent. It just couldn't do so, because the original device was hidden (= not set as the source_device of the QSV device). This patch properly makes these setting and fixes all derivation scenarios. (at a later stage, /libavutil/tests/hwdevice should be extended to check longer derivation chains as well) Reviewed-by: Lynne <dev@lynne.ee> Reviewed-by: Anton Khirnov <anton@khirnov.net> Tested-by: Wenbin Chen <wenbin.chen@intel.com> Signed-off-by: softworkz <softworkz@hotmail.com> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* libavutil/hwcontext_qsv: clean padding when upload qsv framesWenbin Chen2021-12-231-13/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | Fix #7830 When we upload a frame that is not padded as MSDK requires, we create a new AVFrame to copy data. The frame's padding data is uninitialized so it brings run to run problem. For example, If we run the following command serveral times we will get different outputs. ffmpeg -init_hw_device qsv=qsv:hw -qsv_device /dev/dri/renderD128 \ -filter_hw_device qsv -f rawvideo -s 192x200 -pix_fmt p010 \ -i 192x200_P010.yuv -vf "format=nv12,hwupload=extra_hw_frames=16" \ -c:v hevc_qsv output.265 According to https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#encoding-procedures "Note: It is the application's responsibility to fill pixels outside of crop window when it is smaller than frame to be encoded. Especially in cases when crops are not aligned to minimum coding block size (16 for AVC, 8 for HEVC and VP9)" I add a function to fill padding area with border pixel to fix this run2run problem, and also move the new AVFrame to global structure to reduce redundant allocation operation to increase preformance. Signed-off-by: Wenbin Chen <wenbin.chen@intel.com> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* libavutil/hwcontext_qsv: fix a bug for mapping vaapi frame to qsvnyanmisaka2021-12-041-1/+1
| | | | | | | | | | | | | | The data stored in data[3] in VAAPI AVFrame is VASurfaceID while the data stored in pair->first is the pointer of VASurfaceID, so we need to do cast to make following commandline works: ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 \ -hwaccel_output_format vaapi -i input.264 \ -vf "hwmap=derive_device=qsv,format=qsv" -c:v h264_qsv output.264 Signed-off-by: nyanmisaka <nst799610810@gmail.com> Signed-off-by: Wenbin Chen <wenbin.chen@intel.com> Signed-off-by: Anton Khirnov <anton@khirnov.net>
* avutil/hwcontext_qsv: Remove redundant checkAndreas Rheinhardt2021-11-181-2/+2
| | | | | | | | | | | | | It has already been checked immediately before that said AVDictionaryEntry exists; checking again is redundant. Furthermore, av_hwdevice_find_type_by_name() requires its argument to be non-NULL, so adding a codepath that automatically calls it with that parameter is nonsense. The same goes for the argument corresponding to %s. Fixes Coverity issue 1491394. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/hwcontext_qsv: Fix leak of AVBuffer and AVBufferRefAndreas Rheinhardt2021-11-181-2/+0
| | | | | | | | | This av_buffer_create() does nothing but leak an AVBuffer and an AVBufferRef (except on allocation error). Fixes Coverity issue 1491393. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* libavutil/hwcontext_qsv: fix a bug for mapping qsv frame to vaapiWenbin Chen2021-09-231-1/+5
| | | | | | | | | | | | | | Command below failed. ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device qsv=qs@va -hwaccel qsv -hwaccel_device qs -filter_hw_device va -c:v h264_qsv -i 1080P.264 -vf "hwmap,format=vaapi" -c:v h264_vaapi output.264 Cause: Assign pair->first directly to data[3] in vaapi frame. pair->first is *VASurfaceID while data[3] in vaapi frame is VASurfaceID. I fix this line of code. Now the command above works. Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
* Replace all occurences of av_mallocz_array() by av_calloc()Andreas Rheinhardt2021-09-201-20/+23
| | | | | | | They do the same. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 ↵Artem Galin2021-09-081-12/+25
| | | | | | | | | | | | hwcontext API Microsoft VideoProcessor requires texture with D3DUSAGE_RENDERTARGET flag as output. There is no way to allocate array of textures with D3D11_BIND_RENDER_TARGET flag and .ArraySize > 2 by ID3D11Device_CreateTexture2D due to the Microsoft limitation. Adding AVD3D11FrameDescriptors array to store array of single textures instead of texture with multiple slices resolves this. Signed-off-by: Artem Galin <artem.galin@intel.com>
* libavutil/hwcontext_qsv: add usage child_device_type argument to explicitly ↵Artem Galin2021-09-081-13/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | select d3d11va/DX11 device type UPD: Rebase of last patch set over current master and use DX9 as default device type. Makes selection of dxva2/DX9 device type by default as before with explicit d3d11va/DX11 usage to cover more HW configurations. Added warning message to expect changing default device type in the future. Fixes TGL / AV1 decode as requires DX11 with explicit DX11 type selection. Add headless/multi adapter support and fixes: https://trac.ffmpeg.org/ticket/7511 https://trac.ffmpeg.org/ticket/6827 http://ffmpeg.org/pipermail/ffmpeg-trac/2017-November/041901.html https://trac.ffmpeg.org/ticket/7933 https://github.com/InitialForce/FFmpeg/commit/338fbcd5bba1de0e1b3e3bad8985eee2fdfbeca1 https://github.com/jellyfin/jellyfin/issues/2626#issuecomment-602153952 Any other fixes are welcome including OpenCL interop patch since I don't have proper setup to validate this use case Decoding, encoding, transcoding have been validated. child_device_type option is responsible for d3d11va/dxva2 device selection Usage examples: DirectX 11: -init_hw_device qsv:hw,child_device_type=d3d11va -init_hw_device qsv:hw,child_device_type=d3d11va,child_device=0 OR -init_hw_device d3d11va=dx -init_hw_device qsv@dx DirectX 9 is still supported but requires explicit selection: -init_hw_device qsv:hw,child_device_type=dxva2 OR -init_hw_device dxva2=dx -init_hw_device qsv@dx Signed-off-by: Artem Galin <artem.galin@intel.com>
* libavutil/hwcontext_qsv: supporting d3d11va device typeArtem Galin2021-09-081-61/+265
| | | | | | | This enables usage of non-powered/headless GPU, better HDR support. Pool of resources is allocated as one texture with array of slices. Signed-off-by: Artem Galin <artem.galin@intel.com>
* avutil/buffer: Switch AVBuffer API to size_tAndreas Rheinhardt2021-04-271-1/+1
| | | | | | | Announced in 14040a1d913794d9a3fd6406a6d8c2f0e37e0062. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> Signed-off-by: James Almer <jamrial@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-10 00:33:14 +0000