On Thu, 26 Oct 2017 00:18:39 +0100
Mark Thompson <s...@jkqxz.net> wrote:
> ---
> Rebased on the frame parameter changes, and incorporating all review comments
> from last time.
>
>
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 74
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
> libavcodec/hwaccel.h | 18 +++++++++++++
> libavcodec/utils.c | 12 +++++++++
> 4 files changed, 107 insertions(+)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 9f3a1f246..490c71cc2 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -13,6 +13,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_get_hw_config().
> +
> 2017-xx-xx - xxxxxxx - lavc 58.5.0 - avcodec.h
> Add avcodec_get_hw_frames_parameters().
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 562483502..b4bd4ad16 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"
> @@ -2735,6 +2736,61 @@ typedef struct AVProfile {
> const char *name; ///< short name for the profile
> } AVProfile;
>
> +enum {
> + /**
> + * The codec supports this format via the hw_device_ctx interface.
> + *
> + * When selecting this format, AVCodecContext.hw_device_ctx should
> + * have been set to a device of the specified type before calling
> + * avcodec_open2().
> + */
> + AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX = 0x01,
> + /**
> + * The codec supports this format via the hw_frames_ctx interface.
> + *
> + * When selecting this format for a decoder,
> + * AVCodecContext.hw_frames_ctx should be set to a suitable frames
> + * context inside the get_format() callback. The frames context
> + * must have been created on a device of the specified type.
> + */
> + AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX = 0x02,
> + /**
> + * The codec supports this format by some internal method.
> + *
> + * This format can be selected without any additional configuration -
> + * no device or frames are required.
> + */
> + AV_CODEC_HW_CONFIG_METHOD_INTERNAL = 0x04,
> + /**
> + * The codec supports this format by some ad-hoc method.
> + *
> + * Additional settings and/or function calls are required. See the
> + * codec-specific documentation for details. (Methods requiring
> + * this sort of configuration are deprecated and others should be
> + * used in preference.)
> + */
> + AV_CODEC_HW_CONFIG_METHOD_AD_HOC = 0x08,
> +};
> +
> +typedef struct AVCodecHWConfig {
> + /**
> + * A hardware pixel format which the codec can use.
> + */
> + enum AVPixelFormat pix_fmt;
> + /**
> + * Bit set of AV_CODEC_HW_CONFIG_METHOD_* flags, describing the possible
> + * setup methods which can be used with this configuration.
> + */
> + int methods;
> + /**
> + * The device type associated with the configuration.
> + *
> + * Must be set for AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX and
> + * AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX, otherwise unused.
> + */
> + enum AVHWDeviceType device_type;
> +} AVCodecHWConfig;
All patches LGTM, just 3 things:
1. I'd really like if the following two things were exposed as metadata:
- whether the AVCodec supports software decoding at all (fallbacks
etc.)
- whether the software decoder is native to Libav, or something
external (for example I think qsvdec can do software decoding?)
2. Should AVCodecHWConfig have a name that identifies each entry? (The
name would be unique for the same AVCodec, but not globally.) As we
move away from identifying hwaccels via only a pixfmt or device type,
and use AVCodecHWConfig pointers instead, this might help with
introspection, debugging, command line mappings.
3. Should there be no "methods" bit field, and instead expose each mode
as a separate AVCodecHWConfig? It's a bit weird that one entry can
somehow represent multiple methods.
Ignore the last one if it'd be too hard, it's just a bikeshedding extra,
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
