summaryrefslogtreecommitdiff
path: root/libavutil/hwcontext_qsv.c
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* avutil: use the buffer_size_t typedef where requiredJames Almer2021-03-101-1/+1
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* hwcontext: add av_hwdevice_ctx_create_derived_optsLynne2020-05-231-1/+2
| | | | | | | | | | | | | This allows for users who derive devices to set options for the new device context they derive. The main use case of this is to allow users to enable extensions (such as surface drawing extensions) in Vulkan while deriving from the device their frames are on. That way, users don't need to write any initialization code themselves, since the Vulkan spec invalidates mixing instances, physical devices and active devices. Apart from Vulkan, other hwcontexts ignore the opts argument since they don't support options at all (or in VAAPI and OpenCL's case, options are currently only used for device selection, which device_derive overrides).
* Stop hardcoding align=32 in av_frame_get_buffer() calls.Anton Khirnov2020-05-221-1/+1
| | | | Use 0, which selects the alignment automatically.
* lavc/qsvdec: add decode support for HEVC 4:2:2 8-bit and 10-bitLinjie Fu2020-05-181-0/+24
| | | | | | | | | Enables HEVC Range Extension decoding support (Linux) for 4:2:2 8/10 bit on ICL+ (gen11 +) platform. Restricted to linux only for now. Signed-off-by: Linjie Fu <linjie.fu@intel.com>
* lavu/qsv: remove redundant version queryZhong Li2019-09-271-5/+0
| | | | Signed-off-by: Zhong Li <zhong.li@intel.com>
* lavu/hwcontext_qsv: fix the memory leakLinjie Fu2019-07-301-0/+2
| | | | | | | av_dict_free child_device_opts to fix the memory leak. Signed-off-by: Linjie Fu <linjie.fu@intel.com> Signed-off-by: Zhong Li <zhong.li@intel.com>
* hwcontext_qsv: Try to select a matching VAAPI device by defaultMark Thompson2019-06-021-3/+12
| | | | | | | Tries to find a device backed by the i915 kernel driver and loads the iHD VAAPI driver to use with it. This reduces confusion on machines with multiple DRM devices and removes the surprising requirement to set the LIBVA_DRIVER_NAME environment variable to use libmfx at all.
* lavu/hwcontext_qsv: Fix the realign check for hwuploadLinjie Fu2019-04-301-2/+1
| | | | | | | | | | Fix the aligned check in hwupload, input surface should be 16 aligned too. Partly fix #7830. Signed-off-by: Linjie Fu <linjie.fu@intel.com> Signed-off-by: Zhong Li <zhong.li@intel.com>
* lavu/hwcontext_qsv: Mark a pointer as const.Carl Eugen Hoyos2019-04-161-1/+2
| | | | | Silences a warning: libavutil/hwcontext_qsv.c:912:15: warning: assignment discards 'const' qualifier from pointer target type
* lavu/qsv: allow surface size larger than requirementZhong Li2019-03-181-1/+1
| | | | | | | Just like commit 6829a079444e10818a847e153121fb458cc5c0a8, surface size larger than requirement should not be treated as error. Signed-off-by: Zhong Li <zhong.li@intel.com>
* lavu/qsv: make a copy as libmfx alignment requirement for uploadingZhong Li2018-10-111-2/+29
| | | | | | | | | | | | | | Libmfx requires 16 bytes aligned input/output for uploading. Currently only output is 16 byte aligned and assigning same width/height to input with smaller buffer size actually, thus definitely will cause segment fault. Can reproduce with any 1080p nv12 rawvideo input: ffmpeg -init_hw_device qsv=qsv:hw -hwaccel qsv -filter_hw_device qsv -f rawvideo -pix_fmt nv12 -s:v 1920x1080 -i 1080p_nv12.yuv -vf 'format=nv12,hwupload=extra_hw_frames=16,hwdownload,format=nv12' -an -y out_nv12.yuv It can fix #7418 Signed-off-by: Zhong Li <zhong.li@intel.com>
* lavu/hwcontext_qsv: Add support for AV_PIX_FMT_BGRA.Zhong Li2018-10-111-10/+34
| | | | | | | | | | | | | | | | | RGB32(AV_PIX_FMT_BGRA on intel platforms) format may be used as overlay with alpha blending. So add AV_PIX_FMT_BGRA format support. One example of alpha blending overlay: ffmpeg -hwaccel qsv -c:v h264_qsv -i BA1_Sony_D.jsv -filter_complex 'movie=lena-rgba.png,hwupload=extra_hw_frames=16[a];[0:v][a]overlay_qsv=x=10:y=10' -c:v h264_qsv -y out.mp4 Rename RGB32 to be BGRA to make it clearer as Mark Thompson's suggestion. V2: Add P010 format support else will introduce HEVC 10bit encoding regression. Thanks for LinJie's discovery. Signed-off-by: Zhong Li <zhong.li@intel.com> Verified-by: Fu, Linjie <linjie.fu@intel.com>
* Merge commit '21733b39d0af5211d7b9f168ff3667ea86362e2b'Mark Thompson2018-10-061-1/+1
|\ | | | | | | | | | | | | | | | | * commit '21733b39d0af5211d7b9f168ff3667ea86362e2b': lavu/qsv: fix a random hwupload failure regression Fixes CID #1439585. Merged-by: Mark Thompson <sw@jkqxz.net>
| * lavu/qsv: fix a random hwupload failure regressionZhong Li2018-10-031-1/+1
| | | | | | | | | | | | | | | | Variable 'ret' hasn't been initialized，thus introducing a random hwupload failure regression due to qsv session uninitialized. Signed-off-by: Zhong Li <zhong.li@intel.com> Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* | Merge commit '642fd4769becc2f4827f8375a3d9e8edd2f5df77'James Almer2018-09-111-6/+77
|\ \ | |/ | | | | | | | | | | * commit '642fd4769becc2f4827f8375a3d9e8edd2f5df77': qsvvpp: Perform full init only when needed Merged-by: James Almer <jamrial@gmail.com>
| * qsvvpp: Perform full init only when neededJoe Olivas2018-09-041-6/+77
| | | | | | | | | | | | | | | | | | | | | | Removing unused VPP sessions by initializing only when used in order to help reduce CPU utilization. Thanks to Maxym for the guidance. Signed-off-by: Joe Olivas <joseph.k.olivas@intel.com> Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com> Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* | Merge commit 'cca5e4f040971db6de0bfe6968f00c021d8a9c42'James Almer2018-04-131-0/+5
|\ \ | |/ | | | | | | | | | | * commit 'cca5e4f040971db6de0bfe6968f00c021d8a9c42': qsv: adding Multi Frame Encode support Merged-by: James Almer <jamrial@gmail.com>
| * qsv: adding Multi Frame Encode supportMaxym Dmytrychenko2018-04-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting from API 1.25 helps to improve performance of the simultaneous encode, 1:N scenario, like: ./avconv -y -hwaccel qsv -c:v h264_qsv -r 30000/1001 -i ~/bbb_sunflower_1080p_60fps_normal.mp4 -vframes 600 -an \ -filter_complex "split=2[s1][s2]; [s1]scale_qsv=1280:720[o1]; [s2]scale_qsv=960:540[o2]" \ -map [o1] -c:v h264_qsv -b:v 3200k -minrate 3200k -maxrate 3200k -f rawvideo /tmp/3200a.264 \ -map [o2] -c:v h264_qsv -b:v 1750k -minrate 1750k -maxrate 1750k -f rawvideo /tmp/1750a.264 Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>
* | Merge commit '86499771d1228d8303c8eb6509e20c0caaa02da5'James Almer2018-03-291-4/+4
|\ \ | |/ | | | | | | | | | | * commit '86499771d1228d8303c8eb6509e20c0caaa02da5': qsv: align surface width/height to 16. Merged-by: James Almer <jamrial@gmail.com>
| * qsv: align surface width/height to 16.Ruiling Song2018-03-211-4/+4
| | | | | | | | | | | | | | | | | | | | Per MediaSDK documentation, it requires width/height to 16 alignment. Without this patch, hwupload pipeline may fail if 16 alignment is not met. Although this patch also apply 16 alignment to qsv encoder/decoder, it will not bring any side-effect to them as they are already aligned. Signed-off-by: Ruiling Song <ruiling.song@intel.com> Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* | Merge commit '8ca39b855a7b0e4d9f726fa9d285bc8edcb953e6'Mark Thompson2018-03-051-0/+1
|\ \ | |/ | | | | | | | | | | * commit '8ca39b855a7b0e4d9f726fa9d285bc8edcb953e6': qsv: Default PicStruct to progressive Merged-by: Mark Thompson <sw@jkqxz.net>
View Lorry Controller Status