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? What is LEGACY_SHIT exactly? > 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. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
