From: Mark Thompson <sw@jkqxz.net>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] hwcontext_videotoolbox: add vt_device_derive
Date: Thu, 22 Feb 2024 19:50:36 +0000
Message-ID: <f109f260-a0f7-4280-8f24-31e348398d12@jkqxz.net> (raw)
In-Reply-To: <C002D5FD-1C78-4D07-B4FC-F70423DA7935@me.com>
On 22/02/2024 19:39, ChenLiucheng via ffmpeg-devel wrote:
>> On Feb 23, 2024, at 03:28, Mark Thompson <sw@jkqxz.net> wrote:
>>
>> On 22/02/2024 18:46, gnattu via ffmpeg-devel wrote:
>>> There is no device context to be setup, nor devices to be
>>> selected with VideoToolbox. Just a simple return would allow
>>> us to use derived device in filters like
>>> `hwupload=derive_device=videotoolbox`
>>> Signed-off-by: Gnattu OC <gnattuoc@me.com>
>>> ---
>>> libavutil/hwcontext_videotoolbox.c | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>> diff --git a/libavutil/hwcontext_videotoolbox.c b/libavutil/hwcontext_videotoolbox.c
>>> index fe469dc161..d13199eca7 100644
>>> --- a/libavutil/hwcontext_videotoolbox.c
>>> +++ b/libavutil/hwcontext_videotoolbox.c
>>> @@ -759,6 +759,14 @@ static int vt_device_create(AVHWDeviceContext *ctx, const char *device,
>>> return 0;
>>> }
>>> +static int vt_device_derive(AVHWDeviceContext *device_ctx,
>>> + AVHWDeviceContext *src_ctx, AVDictionary *opts,
>>> + int flags)
>>> +{
>>> + // There is no context to be setup with VT, just return.
>>> + return 0;
>>> +}
>>> +
>>> const HWContextType ff_hwcontext_type_videotoolbox = {
>>> .type = AV_HWDEVICE_TYPE_VIDEOTOOLBOX,
>>> .name = "videotoolbox",
>>> @@ -766,6 +774,7 @@ const HWContextType ff_hwcontext_type_videotoolbox = {
>>> .frames_priv_size = sizeof(VTFramesContext),
>>> .device_create = vt_device_create,
>>> + .device_derive = vt_device_derive,
>>> .frames_hwctx_size = sizeof(AVVTFramesContext),
>>> .frames_init = vt_frames_init,
>>> .frames_get_buffer = vt_get_buffer,
>>
>> This derivation behaviour doesn't make any sense inside libavutil. Features which are only for the ffmpeg utility should be implemented inside the ffmpeg utility.
>>
>> (Also, try -init_hw_device.)
>>
> Well this does make sense.
>
> If only one type of hardware device is in use, then `-init_hw_device` will suffice. However, if we use hardware filters with different device types, such as OpenCL, and we want to switch to a VideoToolbox filter later in the chain, we will have a issue. Since there is no `hwmap` between OpenCL and VideoToolbox, we need to perform a `hwdownload` followed by a `hwupload`. If the `derive_device` option cannot be used with `hwupload` due to `device_derive` not being implemented, the filter will struggle to find the correct device for uploading. It may attempt to upload to the OpenCL device without `device_derive` set if it comes after an OpenCL filter.
>
Yes, it is unfortunate that the ffmpeg utility is missing this feature.
A libavfilter API user will set the correct hw_device_ctx on each filter and your use-case will work properly, but the ffmpeg utility does not fully expose the functionality of libavfilter to be able to do this.
This is mostly for syntax reasons; implementation would be straightforward. If you can think of a good way to represent this in options to the ffmpeg utility (which doesn't become too horrible with escaping) then I would very much welcome suggestions.
Thanks,
- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2024-02-22 19:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-22 18:46 gnattu via ffmpeg-devel
2024-02-22 19:28 ` Mark Thompson
2024-02-22 19:39 ` ChenLiucheng via ffmpeg-devel
2024-02-22 19:50 ` Mark Thompson [this message]
2024-02-22 20:19 ` Gnattu OC via ffmpeg-devel
2024-02-23 1:20 ` Zhao Zhili
2024-02-23 1:31 ` Zhao Zhili
2024-02-23 14:25 ` Zhao Zhili
2024-02-23 17:20 ` Gnattu OC via ffmpeg-devel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f109f260-a0f7-4280-8f24-31e348398d12@jkqxz.net \
--to=sw@jkqxz.net \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git