summaryrefslogtreecommitdiff
path: root/libavutil/hwcontext.c
Commit message (Collapse)AuthorAgeFilesLines
* avutil/hwcontext: verify hw_frames_ctx in transfer_data_allocZhao Zhili2022-11-211-1/+5
| | | | Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
* lavu/hwcontext: clarify behavior on av_hwframe_map() failureAnton Khirnov2022-02-171-2/+25
| | | | | Clear anything that av_hwframe_map() might have done to the destination frame, but leave caller-provided fields unchanged.
* Revert "avutils/hwcontext: When deriving a hwdevice, search for existing ↵Haihao Xiang2022-01-051-38/+0
| | | | | | | | | | 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-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Replace all occurences of av_mallocz_array() by av_calloc()Andreas Rheinhardt2021-09-201-1/+1
| | | | | | | They do the same. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* hwcontext: add av_hwdevice_ctx_create_derived_optsLynne2020-05-231-3/+13
| | | | | | | | | | | | | 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.
* avutil/hwcontext: correctly set extended_data on hwframe_get_bufferTimo Rothenpieler2020-03-281-0/+2
|
* lavu: add Vulkan hwcontext codeLynne2020-02-041-0/+4
| | | | | | | | | | This commit adds the necessary code to initialize and use a Vulkan device within the hwcontext libavutil framework. Currently direct mapping to VAAPI and DRM frames is functional, and transfers to CUDA and native frames are supported. Lets hope the future Vulkan video decode extension fits well within this framework.
* lavu/hwcontext: Add support for HW -> HW transfersPhilip Langdale2020-02-041-10/+43
| | | | | | | | | | | | | | | | | | | | We are beginning to consider scenarios where a given HW Context may be able to transfer frames to another HW Context without passing via system memory - this would usually be when two contexts represent different APIs on the same device (eg: Vulkan and CUDA). This is modelled as a transfer, as we have today, but where both the src and the dst are hardware frames with hw contexts. We need to be careful to ensure the contexts are compatible - particularly, we cannot do transfers where one of the frames has been mapped via a derived frames context - we can only do transfers for frames that were directly allocated by the specified context. Additionally, as we have two hardware contexts, the transfer function could be implemented by either (or indeed both). To handle this uncertainty, we explicitly look for ENOSYS as an indicator to try the transfer in the other direction before giving up.
* hwcontext_internal: add ff_hwframe_map_replaceRostislav Pehlivanov2018-06-211-0/+7
| | | | | | Used to fix unmapping when no direct interop exists between APIs. Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
* hwcontext: Do not call device_init again when deriving an existing deviceMark Thompson2018-05-151-4/+3
| | | | | | The change in 309d660775e2b47af6723a0477c4d753bc0c54f4 to call device_init when doing derivation missed this case - we should only call it if we actually made a new device.
* Merge commit '2eb396b175e55e515aa6a13c5b1789a2a18d3935'James Almer2018-02-111-1/+3
|\ | | | | | | | | | | | | * commit '2eb396b175e55e515aa6a13c5b1789a2a18d3935': hwcontext: Fix memory leak on derived frame allocation failure Merged-by: James Almer <jamrial@gmail.com>
| * hwcontext: Fix memory leak on derived frame allocation failureMark Thompson2018-02-041-1/+3
| |
| * hwcontext: Mark local table static constMark Thompson2017-06-151-1/+1
| |
| * lavu: add new D3D11 pixfmt and hwcontextwm42017-06-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To be used with the new d3d11 hwaccel decode API. With the new hwaccel API, we don't want surfaces to depend on the decoder (other than the required dimension and format). The old D3D11VA pixfmt uses ID3D11VideoDecoderOutputView pointers, which include the decoder configuration, and thus is incompatible with the new hwaccel API. This patch introduces AV_PIX_FMT_D3D11, which uses ID3D11Texture2D and an index. It's simpler and compatible with the new hwaccel API. The introduced hwcontext supports only the new pixfmt. Frame upload code untested. Significantly based on work by Steve Lhomme <robux4@gmail.com>, but with heavy changes/rewrites. Signed-off-by: Diego Biurrun <diego@biurrun.de>
| * hwcontext: Improve allocation in derived contextsMark Thompson2017-04-301-1/+13
| | | | | | | | | | | | | | Use the flags argument of av_hwframe_ctx_create_derived() to pass the mapping flags which will be used on allocation. Also, set the format and hardware context on the allocated frame automatically - the user should not be required to do this themselves.
| * hwcontext: Add frame context mapping for nontrivial contextsMark Thompson2017-04-301-1/+8
| | | | | | | | | | | | | | Some frames contexts are not usable without additional format-specific state in hwctx. This change adds new functions frames_derive_from and frames_derive_to to initialise this state appropriately when deriving a frames context which will require it to be set.
* | lavu/hwcontext: add AV_HWDEVICE_TYPE_MEDIACODECAman Gupta2017-12-161-0/+4
| | | | | | | | Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
* | hwcontext: Perform usual uninitialisation on derived frames contextsMark Thompson2017-11-221-10/+7
| |
* | lavu: OpenCL hwcontext implementationMark Thompson2017-11-221-0/+4
| |
* | Merge commit '1bd986ed4b0e95ded368a8eeb5c044853c090f9b'James Almer2017-10-241-1/+2
|\ \ | |/ | | | | | | | | | | * commit '1bd986ed4b0e95ded368a8eeb5c044853c090f9b': hwcontext: Move NONE to the be the first member of AVHWDeviceType Merged-by: James Almer <jamrial@gmail.com>
| * hwcontext: Move NONE to the be the first member of AVHWDeviceTypeMark Thompson2017-03-271-1/+2
| | | | | | | | Also use that to fix a warning in av_hwdevice_get_type_name().
| * hwcontext: Make it easier to work with device typesMark Thompson2017-03-201-0/+41
| | | | | | | | | | | | Adds functions to convert to/from strings and a function to iterate over all supported device types. Also adds a new invalid type AV_HWDEVICE_TYPE_NONE, which acts as a sentinel value.
| * hwcontext: Add device derivationMark Thompson2017-03-201-0/+65
| | | | | | | | | | Creates a new device context from another of a different type which refers to the same underlying hardware.
* | hwcontext: Perform usual initialisation on derived device contextsMark Thompson2017-10-091-0/+4
| | | | | | | | | | | | | | The initialisation should be common. For libmfx, it was previously happening in the derivation function and this moves it out. For VAAPI, it fixes some failures when deriving from a DRM device because this initialisation did not run.
* | Merge commit 'fd9212f2edfe9b107c3c08ba2df5fd2cba5ab9e3'James Almer2017-09-261-1/+1
|\ \ | |/ | | | | | | | | | | * commit 'fd9212f2edfe9b107c3c08ba2df5fd2cba5ab9e3': Mark some arrays that never change as const. Merged-by: James Almer <jamrial@gmail.com>
| * Mark some arrays that never change as const.Anton Khirnov2017-02-011-1/+1
| |
* | lavu: Add DRM hwcontextMark Thompson2017-09-131-0/+4
| |
* | lavu: add new D3D11 pixfmt and hwcontextwm42017-06-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To be used with the new d3d11 hwaccel decode API. With the new hwaccel API, we don't want surfaces to depend on the decoder (other than the required dimension and format). The old D3D11VA pixfmt uses ID3D11VideoDecoderOutputView pointers, which include the decoder configuration, and thus is incompatible with the new hwaccel API. This patch introduces AV_PIX_FMT_D3D11, which uses ID3D11Texture2D and an index. It's simpler and compatible with the new hwaccel API. The introduced hwcontext supports only the new pixfmt. Frame upload code untested. Significantly based on work by Steve Lhomme <robux4@gmail.com>, but with heavy changes/rewrites. Merges Libav commit fff90422d181744cd75dbf011687ee7095f02875. Signed-off-by: Diego Biurrun <diego@biurrun.de>
* | hwcontext: Improve allocation in derived contextsMark Thompson2017-06-141-1/+13
| | | | | | | | | | | | | | | | | | Use the flags argument of av_hwframe_ctx_create_derived() to pass the mapping flags which will be used on allocation. Also, set the format and hardware context on the allocated frame automatically - the user should not be required to do this themselves. (cherry picked from commit c5714b51aad41fef56dddac1d542e7fc6b984627)
* | hwcontext: Add frame context mapping for nontrivial contextsMark Thompson2017-06-141-1/+8
| | | | | | | | | | | | | | | | | | Some frames contexts are not usable without additional format-specific state in hwctx. This change adds new functions frames_derive_from and frames_derive_to to initialise this state appropriately when deriving a frames context which will require it to be set. (cherry picked from commit 27978155bc661eec9f22bcf82c9cfc099cff4365)
* | hwcontext: Make it easier to work with device typesMark Thompson2017-06-141-1/+43
| | | | | | | | | | | | | | | | Adds functions to convert to/from strings and a function to iterate over all supported device types. Also adds a new invalid type AV_HWDEVICE_TYPE_NONE, which acts as a sentinel value. (cherry picked from commit b7487f4f3c39b4b202e1ea7bb2de13902f2dee45)
* | hwcontext: Add device derivationMark Thompson2017-06-141-0/+65
| | | | | | | | | | | | | | Creates a new device context from another of a different type which refers to the same underlying hardware. (cherry picked from commit b266ad56fe0e4ce5bb70118ba2e2b1dabfaf76ce)
* | videotoolbox: add hwcontext supportwm42017-05-151-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds tons of code for no other benefit than making VideoToolbox support conform with the new hwaccel API (using hw_device_ctx and hw_frames_ctx). Since VideoToolbox decoding does not actually require the user to allocate frames, the new code does mostly nothing. One benefit is that ffmpeg_videotoolbox.c can be dropped once generic hwaccel support for ffmpeg.c is merged from Libav. Does not consider VDA or VideoToolbox encoding. Fun fact: the frame transfer functions are copied from vaapi, as the mapping makes copying generic boilerplate. Mapping itself is not exported by the VT code, because I don't know how to test.
* | Merge commit 'd06aa24ba583ad08025da9e1b29afcd8218ff9b0'Clément Bœsch2017-03-301-6/+233
|\ \ | |/ | | | | | | | | | | * commit 'd06aa24ba583ad08025da9e1b29afcd8218ff9b0': hwcontext: Hardware frame mapping Merged-by: Clément Bœsch <cboesch@gopro.com>
| * hwcontext: Hardware frame mappingMark Thompson2016-11-031-6/+233
| | | | | | | | | | | | | | | | | | | | Adds the new av_hwframe_map() function, which allows mapping between hardware frames and normal memory, along with internal support for implementing it. Also adds av_hwframe_ctx_create_derived(), for creating a hardware frames context associated with one device using frames mapped from another by some hardware-specific means.
* | Merge commit 'fdfe01365d579189d9a55b3741dba2ac46eb1df8'Hendrik Leppkes2016-11-131-2/+6
|\ \ | |/ | | | | | | | | | | * commit 'fdfe01365d579189d9a55b3741dba2ac46eb1df8': hwcontext: allocate the destination frame for the pool size Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
| * hwcontext: allocate the destination frame for the pool sizeAnton Khirnov2016-06-281-2/+6
| | | | | | | | | | | | The source frame may be cropped, so that its dimensions are smaller than the pool dimensions. The transfer_data API requires the allocated size of the destination frame to be the same as the pool size.
* | avutil/hwcontext: use CONFIG_QSV instead of CONFIG_LIBMFX for qsvJames Almer2016-09-281-1/+1
| | | | | | | | | | | | | | See "[FFmpeg-devel] [PATCH] hwcontext: add a QSV implementation" Suggested-by: nablet developer <sdk@nablet.com> Signed-off-by: James Almer <jamrial@gmail.com>
* | Merge commit '59e7361cc791e5103be1712dc59a2055f118d0da'James Almer2016-09-281-0/+3
|\ \ | |/ | | | | | | | | | | | | | | | | | | * commit '59e7361cc791e5103be1712dc59a2055f118d0da': hwcontext: add a QSV implementation Conflicts: doc/APIchanges libavutil/version.h Merged-by: James Almer <jamrial@gmail.com>
| * hwcontext: add a QSV implementationAnton Khirnov2016-06-211-0/+3
| |
* | Merge commit '1c9e8616c535ef496e7ee8a5cbc5e9e972a6977d'Hendrik Leppkes2016-06-261-0/+36
|\ \ | |/ | | | | | | | | | | * commit '1c9e8616c535ef496e7ee8a5cbc5e9e972a6977d': hwcontext: add a function for opening devices Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
| * hwcontext: add a function for opening devicesAnton Khirnov2016-05-261-0/+36
| |
* | Merge commit 'c46db38cde8e8fd8ecb1c6602f10ec0e002f29a8'Hendrik Leppkes2016-06-221-0/+3
|\ \ | |/ | | | | | | | | | | * commit 'c46db38cde8e8fd8ecb1c6602f10ec0e002f29a8': hwcontext: add a dxva2 implementation Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
| * hwcontext: add a dxva2 implementationAnton Khirnov2016-05-171-0/+3
| |
* | Merge commit 'a0f469da744db83db32f3fe13186ee4aa2bc7dc5'Derek Buitenhuis2016-05-111-0/+1
|\ \ | |/ | | | | | | | | | | * commit 'a0f469da744db83db32f3fe13186ee4aa2bc7dc5': hwcontext: initialize sw_format in av_hwframe_ctx_alloc() Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
| * hwcontext: initialize sw_format in av_hwframe_ctx_alloc()Anton Khirnov2016-04-151-0/+1
| |
* | Merge commit '551c6775abb5e0ad34c26d7e23bc6fbbe8ccc9d4'Derek Buitenhuis2016-04-141-0/+3
|\ \ | |/ | | | | | | | | | | * commit '551c6775abb5e0ad34c26d7e23bc6fbbe8ccc9d4': lavu: VAAPI hwcontext implementation Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
| * lavu: VAAPI hwcontext implementationMark Thompson2016-03-191-0/+3
| | | | | | | | Signed-off-by: Anton Khirnov <anton@khirnov.net>
View Lorry Controller Status