On 06/09/17 19:14, wm4 wrote: > On Wed, 6 Sep 2017 18:55:46 +0100 > Mark Thompson <[email protected]> wrote: > >> On 06/09/17 17:29, wm4 wrote: >>> On Wed, 6 Sep 2017 16:53:04 +0100 >>> Mark Thompson <[email protected]> wrote: >>> >>>> On 06/09/17 15:37, wm4 wrote: >>>>> On Tue, 5 Sep 2017 23:59:31 +0100 >>>>> Mark Thompson <[email protected]> wrote: >>>>> >>>>>> --- >>>>>> doc/APIchanges | 3 +++ >>>>>> libavcodec/avcodec.h | 23 +++++++++++++++++++++++ >>>>>> 2 files changed, 26 insertions(+) >>>>>> >>>>>> diff --git a/doc/APIchanges b/doc/APIchanges >>>>>> index 6f70f3c96..f21dc4db0 100644 >>>>>> --- a/doc/APIchanges >>>>>> +++ b/doc/APIchanges >>>>>> @@ -14,6 +14,9 @@ libavutil: 2017-03-23 >>>>>> API changes, most recent first: >>>>>> >>>>>> 2017-xx-xx - xxxxxxx - lavc 58.x+1.0 - avcodec.h >>>>>> + Add AVCodecHWConfig and AVCodec.hw_configs. >>>>>> + >>>>>> +2017-xx-xx - xxxxxxx - lavc 58.x+1.0 - avcodec.h >>>>>> Add AV_HWACCEL_FLAG_REUSE_CONTEXT. >>>>>> >>>>>> 2017-xx-xx - xxxxxxx - lavfi 7.x+1.0 - avfilter.h >>>>>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h >>>>>> index 89e432d16..4f6b76203 100644 >>>>>> --- a/libavcodec/avcodec.h >>>>>> +++ b/libavcodec/avcodec.h >>>>>> @@ -35,6 +35,7 @@ >>>>>> #include "libavutil/cpu.h" >>>>>> #include "libavutil/dict.h" >>>>>> #include "libavutil/frame.h" >>>>>> +#include "libavutil/hwcontext.h" >>>>>> #include "libavutil/log.h" >>>>>> #include "libavutil/pixfmt.h" >>>>>> #include "libavutil/rational.h" >>>>>> @@ -2773,6 +2774,19 @@ typedef struct AVProfile { >>>>>> const char *name; ///< short name for the profile >>>>>> } AVProfile; >>>>>> >>>>>> +typedef struct AVCodecHWConfig { >>>>>> + /** >>>>>> + * A device type which can be supplied to the codec. >>>>>> + */ >>>>>> + enum AVHWDeviceType device_type; >>>>>> + /** >>>>>> + * The matching hardware pixel format which the codec can produce. >>>>>> + * >>>>>> + * Set to AV_PIX_FMT_NONE if no hardware pixel format is available. >>>>>> + */ >>>>>> + enum AVPixelFormat pix_fmt; >>>>>> +} AVCodecHWConfig; >>>>>> + >>>>>> typedef struct AVCodecDefault AVCodecDefault; >>>>>> >>>>>> struct AVSubtitle; >>>>>> @@ -2808,6 +2822,15 @@ typedef struct AVCodec { >>>>>> const AVClass *priv_class; ///< AVClass for the >>>>>> private context >>>>>> const AVProfile *profiles; ///< array of recognized >>>>>> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN} >>>>>> >>>>>> + /** >>>>>> + * Array of hardware configurations supported by the codec, or NULL >>>>>> + * if no hardware supported. >>>>>> + * >>>>>> + * The array is terminated by a configuration with a device_type of >>>>>> + * AV_HW_DEVICE_TYPE_NONE. >>>>>> + */ >>>>>> + const AVCodecHWConfig *hw_configs; >>>>>> + >>>>>> /***************************************************************** >>>>>> * No fields below this line are part of the public API. They >>>>>> * may not be used outside of libavcodec and can be changed and >>>>> >>>>> What if a decoder provides hardware decoding, but has no associated >>>>> AVHWDeviceType? (Such as mmal.) >>>> >>>> They are in the pix_fmts list. What other information do you want? >>> >>> They don't necessarily output a hw format. For example, crystalhd >>> (ffmpeg only) doesn't. It would also not be very uniform. >> >> If it doesn't require any additional setup and it outputs software frames >> then it's indistinguishable from a normal software decoder; therefore, treat >> it as such. >> >> MMAL is harder - I'm only treating the real hwaccels here because they now >> have a consistent form we can make use of. >> >> I haven't really thought about this properly, but how about something like: >> >> enum AVCodecHWConfigMethod { >> AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE = 1, >> AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES = 2, >> AV_CODEC_HW_CONFIG_METHOD_LEGACY_SHIT = 4, >> AV_CODEC_HW_CONFIG_METHOD_MAGIC = 8, >> }; >> >> struct AVCodecHWConfig { >> int methods; >> enum AVHWDeviceType device_type; >> enum AVPixelFormat pix_fmt; >> }; >> >> Then you would label MMAL as MAGIC, because it can just output the MMAL >> frames without additional setup. VAAPI/VDPAU would be HW_DEVICE | HW_FRAMES >> | LEGACY_SHIT. QSV would be HW_FRAMES | LEGACY_SHIT. > > That sounds OK too. Maybe we should include the information whether it's > a hwaccel, i.e. something that has an actual software decoder under the > hood, and that dynamic fallback/resuming HW decoding is supported?
I was thinking that was implied by not-MAGIC, but it isn't. Yeah, that flag would help. Does it actually need to be externally-visible, though? > What is LEGACY_SHIT exactly? "This has some arcane rules that can't be expressed here, go read the code" - the old hwaccels where you have to put structure X in hwaccel_context and call special function Y before you do anything. >> Is there then sufficient information for ff_get_format() to look at this >> list to decide on whether it needs an AVHWAccel, and therefore eliminate >> dummy hwaccels? > > I suspect it is. I wonder why this check is even being done at all. With the needs_hwaccel flag then yes. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
