From: "Wu, Tong1" <tong1.wu-at-intel.com@ffmpeg.org> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH v2 1/3] avutil/hwcontext: add a function to get the AVHWDeviceType Date: Fri, 1 Jul 2022 06:51:28 +0000 Message-ID: <SN6PR11MB29908D2FFFD18BC7ABEE8C07C0BD9@SN6PR11MB2990.namprd11.prod.outlook.com> (raw) In-Reply-To: <SN6PR11MB299062B5FFD2141BCC5D3508C0BD9@SN6PR11MB2990.namprd11.prod.outlook.com> > > > On Jun 30, 2022, at 7:56 PM, Andreas Rheinhardt > > <andreas.rheinhardt@outlook.com> wrote: > > > > > > "zhilizhao(赵志立)": > > >> > > >> > > >>> On Jun 30, 2022, at 4:43 PM, Anton Khirnov <anton@khirnov.net> > wrote: > > >>> > > >>> Quoting Tong Wu (2022-06-30 04:45:56) > > >>>> Add a function to get the corresponding AVHWDeviceType from a > > >>>> given hardware pixel format. > > >>>> > > >>>> Signed-off-by: Tong Wu <tong1.wu@intel.com> > > >>>> --- > > >>>> libavutil/hwcontext.c | 12 ++++++++++++ libavutil/hwcontext.h | > > >>>> 9 > > >>>> +++++++++ > > >>>> 2 files changed, 21 insertions(+) > > >>>> > > >>>> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c index > > >>>> ab9ad3703e..3521ed34f4 100644 > > >>>> --- a/libavutil/hwcontext.c > > >>>> +++ b/libavutil/hwcontext.c > > >>>> @@ -80,6 +80,18 @@ static const char *const hw_type_names[] = { > > >>>> [AV_HWDEVICE_TYPE_VULKAN] = "vulkan", }; > > >>>> > > >>>> +enum AVHWDeviceType av_hwdevice_get_type_by_pix_fmt(enum > > >>>> +AVPixelFormat fmt) { > > >>>> + int i, j; > > >>> > > >>> Nit: you can and should declare loop indices in the loop statement > > >>> itself > > Sure, will modify them in v3. > > > >>> > > >>>> + for (i = 0; hw_table[i]; i++) { > > >>>> + for (j = 0; hw_table[i]->pix_fmts[j] != AV_PIX_FMT_NONE; j++) { > > >>>> + if (hw_table[i]->pix_fmts[j] == fmt) > > >>>> + return hw_table[i]->type; > > >>>> + } > > >>>> + } > > >>>> + return AV_HWDEVICE_TYPE_NONE; } > > >>>> + > > >>>> enum AVHWDeviceType av_hwdevice_find_type_by_name(const char > > *name) > > >>>> { > > >>>> int type; > > >>>> diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h index > > >>>> c18b7e1e8b..97f94403e2 100644 > > >>>> --- a/libavutil/hwcontext.h > > >>>> +++ b/libavutil/hwcontext.h > > >>>> @@ -229,6 +229,15 @@ typedef struct AVHWFramesContext { > > >>>> int width, height; > > >>>> } AVHWFramesContext; > > >>>> > > >>>> +/** > > >>>> + * Get the device type by a given pixel format. > > >>>> + * > > >>>> + * @param fmt Pixel format from enum AVPixelFormat. > > >>>> + * @return The type from enum AVHWDeviceType, or > > AV_HWDEVICE_TYPE_NONE if > > >>>> + * not found. > > >>>> + */ > > >>>> +enum AVHWDeviceType av_hwdevice_get_type_by_pix_fmt(enum > > >>>> +AVPixelFormat fmt); > > >>> > > >>> I wonder if we should consider the possibility of a format being > > >>> supported by more than one device type. > > >> > > >> For future proof, we can make it clear that there is no guarantee > > >> that the device type is unique, e.g., > > >> > > >> "Get any device type which support the given pixel format” > > >> > > > > > > Then you'd need to return a list or modify the user accept an iterator. > > > > Iterator should be fine. > > > > However, the use case is unclear: since we only return an > > AVHWDeviceType without description like av_pix_fmt_desc_get(), user > > has little information to skip to the next one, unless user only wants > > to get all of the device types which support a pixel format. > > Since so far there's no hardware format being supported by more than one > hardware device, can we just keep current implementation and clarify it in > comments such as "Get any device type which support the given pixel > format”? > > Thanks, > Tong > Plus, do you think adding a AV_PIX_FMT_FLAG_HWACCEL check for the input pixel format and change the function name to av_hwdevice_get_type_by_hwaccel_pix_fmt will help? Let users know only hardware pixel formats are acceptable for this function and like I said at this moment not any hardware format is supported by more than one hardware devices. Tong > > > > > > > > - Andreas > > > _______________________________________________ > > > 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". > > > > _______________________________________________ > > 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". > _______________________________________________ > 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". _______________________________________________ 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:[~2022-07-01 6:51 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-30 2:45 Tong Wu 2022-06-30 2:45 ` [FFmpeg-devel] [PATCH v2 2/3] avfilter/vf_hwmap: get the AVHWDeviceType from outlink format Tong Wu 2022-06-30 11:49 ` Paul B Mahol 2022-07-01 2:11 ` Wu, Tong1 2022-06-30 2:45 ` [FFmpeg-devel] [PATCH v2 3/3] avfilter/avfiltergraph: add an auto hwmap filter Tong Wu 2022-06-30 8:43 ` [FFmpeg-devel] [PATCH v2 1/3] avutil/hwcontext: add a function to get the AVHWDeviceType Anton Khirnov 2022-06-30 11:52 ` "zhilizhao(赵志立)" 2022-06-30 11:56 ` Andreas Rheinhardt 2022-06-30 12:12 ` "zhilizhao(赵志立)" 2022-07-01 2:37 ` Wu, Tong1 2022-07-01 6:51 ` Wu, Tong1 [this message] 2022-07-02 8:50 ` Anton Khirnov 2022-07-03 12:11 ` Wu, Tong1
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=SN6PR11MB29908D2FFFD18BC7ABEE8C07C0BD9@SN6PR11MB2990.namprd11.prod.outlook.com \ --to=tong1.wu-at-intel.com@ffmpeg.org \ --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