On 04/10/17 09:49, wm4 wrote:
> On Wed, 4 Oct 2017 09:07:10 +0100
> Mark Thompson <s...@jkqxz.net> wrote:
>
>> ---
>> doc/APIchanges | 3 +++
>> libavcodec/avcodec.h | 74
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> libavcodec/utils.c | 11 ++++++++
>> 3 files changed, 88 insertions(+)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index fa27007f4..80a8ac1fa 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.hw_configs.
>> +
>> 2017-xx-xx - xxxxxxx - lavu 56.6.0 - pixdesc.h
>> Add av_color_range_from_name(), av_color_primaries_from_name(),
>> av_color_transfer_from_name(), av_color_space_from_name(), and
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 162f1abe4..5f4a95287 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,65 @@ 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,
>
> In addition to this, should there be an AVCodec flag that tells the API
> user whether this decoder can do half-transparent software fallback?
> Half-transparent as in it can call get_format mid-stream to reconfigure
> it to sw decoding.
>
> Or would such a flag be redundant with AVCodecHWConfig.hwaccel?
Is there any decoder which does support software output formats but doesn't
support this case from the point of view of the user? (Including in the other
tine.)
I think all decoders which offer a software format in get_format() are required
to be able to do this - if they can't then they need to filter the list
provided to get_format().
>> +};
>> +
>> +typedef struct AVCodecHWConfig {
>
> The name might still need to be bikeshedded a bit, but I don't insist
> on changing it.
>
> This name in particular sounds a bit like an instantiated runtime
> decoder configuration (maybe).
Cuerrent bikeshed paint job is provisional. Painters welcome!
>> + /**
>> + * 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;
>> + /**
>> + * Set if this configuration is for a decoder which uses AVHWAccel.
>> + */
>> + int hwaccel;
>
> Maybe clarify that it's a bool (value 0 or 1).
Flag has disappeared in next version - the hwaccel-or-not state is not
user-visible.
>> + /**
>> + * 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;
>> +
>> typedef struct AVCodecDefault AVCodecDefault;
>>
>> struct AVSubtitle;
>> @@ -2859,9 +2919,23 @@ typedef struct AVCodec {
>> * packets before decoding.
>> */
>> const char *bsfs;
>> +
>> + /**
>> + * Array of pointers to hardware configurations supported by the codec,
>> + * or NULL if no hardware supported. The array must be terminated with
>> + * a NULL pointer.
>> + *
>> + * This field should only be accessed via avcodec_get_hw_config().
>> + */
>> + const AVCodecHWConfig **hw_configs;
>
> If it's an array of pointers, we don't actually need an accessor. (Only
> if it were an array of structs.) An array of pointers can be directly
> accessed by anyone without ABI issues, even if the AVCodecHWConfig
> struct is extended.
It's now part of an internal struct, so the accessor is needed.
>> } AVCodec;
>>
>> /**
>> + * Retrieve supported hardware configurations for a codec.
>> + */
>> +const AVCodecHWConfig *avcodec_get_hw_config(const AVCodec *codec, int
>> index);
>> +
>> +/**
>> * @defgroup lavc_hwaccel AVHWAccel
>> * @{
>> */
>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>> index bc421f67f..39c4000a7 100644
>> --- a/libavcodec/utils.c
>> +++ b/libavcodec/utils.c
>> @@ -1335,6 +1335,17 @@ int ff_match_2uint16(const uint16_t(*tab)[2], int
>> size, int a, int b)
>> return i;
>> }
>>
>> +const AVCodecHWConfig *avcodec_get_hw_config(const AVCodec *codec, int
>> index)
>> +{
>> + int i;
>> + if (!codec->hw_configs || index < 0)
>> + return NULL;
>> + for (i = 0; i < index; i++)
>> + if (!codec->hw_configs[i])
>> + return NULL;
>> + return codec->hw_configs[index];
>> +}
>> +
>> static AVHWAccel *first_hwaccel = NULL;
>>
>> void av_register_hwaccel(AVHWAccel *hwaccel)
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
