Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
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".

  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