Message ID | 20240405185721.111072-1-ffmpeg@haasn.xyz |
---|---|
State | New |
Headers | show |
Series | [FFmpeg-devel,01/11] avcodec: add avcodec_get_supported_config() | expand |
Context | Check | Description |
---|---|---|
andriy/make_fate_x86 | success | Make fate finished |
andriy/make_x86 | warning | New warnings during build |
On Fri, 05 Apr 2024 20:57:11 +0200 Niklas Haas <ffmpeg@haasn.xyz> wrote: > From: Niklas Haas <git@haasn.dev> > In addition to the already covered lists, add two new entries for color > space and color range, mirroring the newly added negotiable fields in > libavfilter. If this passes review, I will submit a second series implementing these new fields for relevant codecs.
On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > From: Niklas Haas <git@haasn.dev> > > This replaces the myriad of existing lists in AVCodec by a unified API > call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite > substantially, while also making this more trivially extensible. > > In addition to the already covered lists, add two new entries for color > space and color range, mirroring the newly added negotiable fields in > libavfilter. > > I decided to drop the explicit length field from the API proposed by > Andreas Rheinhardt, because having it in place ended up complicating > both the codec side and the client side implementations, while also > being strictly less flexible (it's trivial to recover a length given > a terminator, but requires allocation to add a terminator given > a length). Using a terminator also presents less of a porting challenge > for existing users of the current API. > > Once the deprecation period passes for the existing public fields, the > rough plan is to move the commonly used fields (such as > pix_fmt/sample_fmt) into FFCodec, possibly as a union of audio and video > configuration types, and then implement the rarely used fields with > custom callbacks. > --- > doc/APIchanges | 5 ++++ > libavcodec/avcodec.c | 51 +++++++++++++++++++++++++++++++++++++ > libavcodec/avcodec.h | 27 ++++++++++++++++++++ > libavcodec/codec.h | 19 +++++++++++--- > libavcodec/codec_internal.h | 21 +++++++++++++++ > libavcodec/version.h | 4 +-- > 6 files changed, 121 insertions(+), 6 deletions(-) If the API is changed, it should be to an API that allows externally maintained codecs. (it would result in more developers working on codecs) thx [...]
Quoting Michael Niedermayer (2024-04-07 01:16:39) > On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > > From: Niklas Haas <git@haasn.dev> > > > > This replaces the myriad of existing lists in AVCodec by a unified API > > call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite > > substantially, while also making this more trivially extensible. > > > > In addition to the already covered lists, add two new entries for color > > space and color range, mirroring the newly added negotiable fields in > > libavfilter. > > > > I decided to drop the explicit length field from the API proposed by > > Andreas Rheinhardt, because having it in place ended up complicating > > both the codec side and the client side implementations, while also > > being strictly less flexible (it's trivial to recover a length given > > a terminator, but requires allocation to add a terminator given > > a length). Using a terminator also presents less of a porting challenge > > for existing users of the current API. > > > > Once the deprecation period passes for the existing public fields, the > > rough plan is to move the commonly used fields (such as > > pix_fmt/sample_fmt) into FFCodec, possibly as a union of audio and video > > configuration types, and then implement the rarely used fields with > > custom callbacks. > > --- > > doc/APIchanges | 5 ++++ > > libavcodec/avcodec.c | 51 +++++++++++++++++++++++++++++++++++++ > > libavcodec/avcodec.h | 27 ++++++++++++++++++++ > > libavcodec/codec.h | 19 +++++++++++--- > > libavcodec/codec_internal.h | 21 +++++++++++++++ > > libavcodec/version.h | 4 +-- > > 6 files changed, 121 insertions(+), 6 deletions(-) > > If the API is changed, it should be to an API that allows externally > maintained codecs. > (it would result in more developers working on codecs) ???? This seems like a complete non sequitur in relation to this patch.
On Sun, 07 Apr 2024 01:16:39 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote: > On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > > From: Niklas Haas <git@haasn.dev> > > > > This replaces the myriad of existing lists in AVCodec by a unified API > > call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite > > substantially, while also making this more trivially extensible. > > > > In addition to the already covered lists, add two new entries for color > > space and color range, mirroring the newly added negotiable fields in > > libavfilter. > > > > I decided to drop the explicit length field from the API proposed by > > Andreas Rheinhardt, because having it in place ended up complicating > > both the codec side and the client side implementations, while also > > being strictly less flexible (it's trivial to recover a length given > > a terminator, but requires allocation to add a terminator given > > a length). Using a terminator also presents less of a porting challenge > > for existing users of the current API. > > > > Once the deprecation period passes for the existing public fields, the > > rough plan is to move the commonly used fields (such as > > pix_fmt/sample_fmt) into FFCodec, possibly as a union of audio and video > > configuration types, and then implement the rarely used fields with > > custom callbacks. > > --- > > doc/APIchanges | 5 ++++ > > libavcodec/avcodec.c | 51 +++++++++++++++++++++++++++++++++++++ > > libavcodec/avcodec.h | 27 ++++++++++++++++++++ > > libavcodec/codec.h | 19 +++++++++++--- > > libavcodec/codec_internal.h | 21 +++++++++++++++ > > libavcodec/version.h | 4 +-- > > 6 files changed, 121 insertions(+), 6 deletions(-) > > If the API is changed, it should be to an API that allows externally > maintained codecs. > (it would result in more developers working on codecs) The only way this could work is by making all of FFCodec public, which is orthogonal to the API proposed here. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > it is not once nor twice but times without number that the same ideas make > their appearance in the world. -- Aristotle > _______________________________________________ > 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".
On Mon, Apr 08, 2024 at 10:18:33PM +0200, Michael Niedermayer wrote: > On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > > From: Niklas Haas <git@haasn.dev> > > > > This replaces the myriad of existing lists in AVCodec by a unified API > > call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite > > substantially, while also making this more trivially extensible. > > > > In addition to the already covered lists, add two new entries for color > > space and color range, mirroring the newly added negotiable fields in > > libavfilter. > > > > I decided to drop the explicit length field from the API proposed by > > Andreas Rheinhardt, because having it in place ended up complicating > > both the codec side and the client side implementations, while also > > being strictly less flexible (it's trivial to recover a length given > > a terminator, but requires allocation to add a terminator given > > a length). Using a terminator also presents less of a porting challenge > > for existing users of the current API. > > > > Once the deprecation period passes for the existing public fields, the > > rough plan is to move the commonly used fields (such as > > pix_fmt/sample_fmt) into FFCodec, possibly as a union of audio and video > > configuration types, and then implement the rarely used fields with > > custom callbacks. > > --- > > doc/APIchanges | 5 ++++ > > libavcodec/avcodec.c | 51 +++++++++++++++++++++++++++++++++++++ > > libavcodec/avcodec.h | 27 ++++++++++++++++++++ > > libavcodec/codec.h | 19 +++++++++++--- > > libavcodec/codec_internal.h | 21 +++++++++++++++ > > libavcodec/version.h | 4 +-- > > 6 files changed, 121 insertions(+), 6 deletions(-) > > This patchset seems to overlap a bit with AVOptionRanges > > I think ideally the user should at some point be able to query using some > API on a AVCodecContext/AVCodecParameters/AVFormatContex/AVStream > what for that specific instance are supported settings for each field let me clarify this a bit more, what i envission is some generic API that can take any AVClass/AVOption suporting struct and query a instance of it for supported ranges/lists of a AVOption field. some AVCodec passed into that call in addition to a AVCodecContext would be more messy in a generic API thx [...]
On Mon, 08 Apr 2024 22:18:33 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote: > On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > > From: Niklas Haas <git@haasn.dev> > > > > This replaces the myriad of existing lists in AVCodec by a unified API > > call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite > > substantially, while also making this more trivially extensible. > > > > In addition to the already covered lists, add two new entries for color > > space and color range, mirroring the newly added negotiable fields in > > libavfilter. > > > > I decided to drop the explicit length field from the API proposed by > > Andreas Rheinhardt, because having it in place ended up complicating > > both the codec side and the client side implementations, while also > > being strictly less flexible (it's trivial to recover a length given > > a terminator, but requires allocation to add a terminator given > > a length). Using a terminator also presents less of a porting challenge > > for existing users of the current API. > > > > Once the deprecation period passes for the existing public fields, the > > rough plan is to move the commonly used fields (such as > > pix_fmt/sample_fmt) into FFCodec, possibly as a union of audio and video > > configuration types, and then implement the rarely used fields with > > custom callbacks. > > --- > > doc/APIchanges | 5 ++++ > > libavcodec/avcodec.c | 51 +++++++++++++++++++++++++++++++++++++ > > libavcodec/avcodec.h | 27 ++++++++++++++++++++ > > libavcodec/codec.h | 19 +++++++++++--- > > libavcodec/codec_internal.h | 21 +++++++++++++++ > > libavcodec/version.h | 4 +-- > > 6 files changed, 121 insertions(+), 6 deletions(-) > > This patchset seems to overlap a bit with AVOptionRanges > > I think ideally the user should at some point be able to query using some > API on a AVCodecContext/AVCodecParameters/AVFormatContex/AVStream > what for that specific instance are supported settings for each field > > The API here seems to use a enum, which can make sense but it differs from > how AVOption works which doesnt use enums to identify fields I didn't know AVOptionRanges exists; indeed it can be seen as somewhat overlapping here. That said, there is a vital distinction here: AVOptionRanges represents *static* limits on what options can be set (e.g. via `av_opt_set_int`), whereas this API represents *dynamic* limits on what can be coded. In particular, the list of supported colorspaces etc. can *depend* on the value of other options. Currently, only strict_std_compliance, but I can easily see this list growing in the future (e.g. for different profiles, dolbyvision, ...). That aside, I personally find an API based on strings and doubles rather cumbersome to use, especially when downstream clients expect an enum list. > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Never trust a computer, one day, it may think you are the virus. -- Compn > _______________________________________________ > 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".
On Mon, Apr 08, 2024 at 11:55:02PM +0200, Niklas Haas wrote: > On Mon, 08 Apr 2024 22:18:33 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote: > > On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > > > From: Niklas Haas <git@haasn.dev> > > > > > > This replaces the myriad of existing lists in AVCodec by a unified API > > > call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite > > > substantially, while also making this more trivially extensible. > > > > > > In addition to the already covered lists, add two new entries for color > > > space and color range, mirroring the newly added negotiable fields in > > > libavfilter. > > > > > > I decided to drop the explicit length field from the API proposed by > > > Andreas Rheinhardt, because having it in place ended up complicating > > > both the codec side and the client side implementations, while also > > > being strictly less flexible (it's trivial to recover a length given > > > a terminator, but requires allocation to add a terminator given > > > a length). Using a terminator also presents less of a porting challenge > > > for existing users of the current API. > > > > > > Once the deprecation period passes for the existing public fields, the > > > rough plan is to move the commonly used fields (such as > > > pix_fmt/sample_fmt) into FFCodec, possibly as a union of audio and video > > > configuration types, and then implement the rarely used fields with > > > custom callbacks. > > > --- > > > doc/APIchanges | 5 ++++ > > > libavcodec/avcodec.c | 51 +++++++++++++++++++++++++++++++++++++ > > > libavcodec/avcodec.h | 27 ++++++++++++++++++++ > > > libavcodec/codec.h | 19 +++++++++++--- > > > libavcodec/codec_internal.h | 21 +++++++++++++++ > > > libavcodec/version.h | 4 +-- > > > 6 files changed, 121 insertions(+), 6 deletions(-) > > > > This patchset seems to overlap a bit with AVOptionRanges > > > > I think ideally the user should at some point be able to query using some > > API on a AVCodecContext/AVCodecParameters/AVFormatContex/AVStream > > what for that specific instance are supported settings for each field > > > > The API here seems to use a enum, which can make sense but it differs from > > how AVOption works which doesnt use enums to identify fields > > I didn't know AVOptionRanges exists; indeed it can be seen as somewhat > overlapping here. That said, there is a vital distinction here: AVOptionRanges > represents *static* limits on what options can be set (e.g. via > `av_opt_set_int`), whereas this API represents *dynamic* limits on what can be > coded. AVOptionRanges where definitly not intended to be static see the docs: * The returned list may depend on other fields in obj like for example profile. that would not be static > > In particular, the list of supported colorspaces etc. can *depend* on the value > of other options. Currently, only strict_std_compliance, but I can easily see > this list growing in the future (e.g. for different profiles, dolbyvision, > ...). > > That aside, I personally find an API based on strings and doubles rather > cumbersome to use, especially when downstream clients expect an enum list. AVOption* is intended to be a generic API. For example something that an App can query to build a drop down menu in a GUI for each parameter For this, it must be possible to iterate over all paremeters, then for each iterate over all possible settings if its a discrete type or range if its a continous type. And then present the user with the corresponding GUI elements thx [...]
On Thu, 11 Apr 2024 00:09:05 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote: > On Mon, Apr 08, 2024 at 11:55:02PM +0200, Niklas Haas wrote: > > On Mon, 08 Apr 2024 22:18:33 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote: > > > On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > > > > From: Niklas Haas <git@haasn.dev> > > > > > > > > This replaces the myriad of existing lists in AVCodec by a unified API > > > > call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite > > > > substantially, while also making this more trivially extensible. > > > > > > > > In addition to the already covered lists, add two new entries for color > > > > space and color range, mirroring the newly added negotiable fields in > > > > libavfilter. > > > > > > > > I decided to drop the explicit length field from the API proposed by > > > > Andreas Rheinhardt, because having it in place ended up complicating > > > > both the codec side and the client side implementations, while also > > > > being strictly less flexible (it's trivial to recover a length given > > > > a terminator, but requires allocation to add a terminator given > > > > a length). Using a terminator also presents less of a porting challenge > > > > for existing users of the current API. > > > > > > > > Once the deprecation period passes for the existing public fields, the > > > > rough plan is to move the commonly used fields (such as > > > > pix_fmt/sample_fmt) into FFCodec, possibly as a union of audio and video > > > > configuration types, and then implement the rarely used fields with > > > > custom callbacks. > > > > --- > > > > doc/APIchanges | 5 ++++ > > > > libavcodec/avcodec.c | 51 +++++++++++++++++++++++++++++++++++++ > > > > libavcodec/avcodec.h | 27 ++++++++++++++++++++ > > > > libavcodec/codec.h | 19 +++++++++++--- > > > > libavcodec/codec_internal.h | 21 +++++++++++++++ > > > > libavcodec/version.h | 4 +-- > > > > 6 files changed, 121 insertions(+), 6 deletions(-) > > > > > > This patchset seems to overlap a bit with AVOptionRanges > > > > > > I think ideally the user should at some point be able to query using some > > > API on a AVCodecContext/AVCodecParameters/AVFormatContex/AVStream > > > what for that specific instance are supported settings for each field > > > > > > The API here seems to use a enum, which can make sense but it differs from > > > how AVOption works which doesnt use enums to identify fields > > > > I didn't know AVOptionRanges exists; indeed it can be seen as somewhat > > overlapping here. That said, there is a vital distinction here: AVOptionRanges > > represents *static* limits on what options can be set (e.g. via > > `av_opt_set_int`), whereas this API represents *dynamic* limits on what can be > > coded. > > AVOptionRanges where definitly not intended to be static > > see the docs: > * The returned list may depend on other fields in obj like for example profile. > > that would not be static > > > > > > > In particular, the list of supported colorspaces etc. can *depend* on the value > > of other options. Currently, only strict_std_compliance, but I can easily see > > this list growing in the future (e.g. for different profiles, dolbyvision, > > ...). > > > > That aside, I personally find an API based on strings and doubles rather > > cumbersome to use, especially when downstream clients expect an enum list. > > AVOption* is intended to be a generic API. > For example something that an App can query to build a drop down menu in a GUI > for each parameter > > For this, it must be possible to iterate over all paremeters, then for each > iterate over all possible settings if its a discrete type or range if its a > continous type. And then present the user with the corresponding GUI elements > > thx Okay, then I do not present as strong an objection as I thought. That said, I still think that downstream API users will be very thankful for having a replacement API that's easy to migrate to, rather one that's IMO rather difficult to use (and which requires both FPU and malloc to access what used to be just a static list). What do other people think? Should we introduce this new API as-is, or should it be scrapped in favor of reusing AVOptionRanges?
diff --git a/doc/APIchanges b/doc/APIchanges index 0a39b6d7ab8..fdeae67159d 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -2,6 +2,11 @@ The last version increases of all libraries were on 2024-03-07 API changes, most recent first: +2024-04-xx - xxxxxxxxxx - lavc 59.6.100 - avcodec.h + Add avcodec_get_supported_config() and enum AVCodecConfig; deprecate + AVCodec.pix_fmts, AVCodec.sample_fmts, AVCodec.supported_framerates, + AVCodec.supported_samplerates and AVCodec.ch_layouts. + 2024-04-03 - xxxxxxxxxx - lavu 59.13.100 - pixfmt.h Add AVCOL_SPC_IPT_C2, AVCOL_SPC_YCGCO_RE and AVCOL_SPC_YCGCO_RO to map new matrix coefficients defined by H.273 v3. diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c index 525fe516bd2..3615dc7c1f3 100644 --- a/libavcodec/avcodec.c +++ b/libavcodec/avcodec.c @@ -700,3 +700,54 @@ int attribute_align_arg avcodec_receive_frame(AVCodecContext *avctx, AVFrame *fr return ff_decode_receive_frame(avctx, frame); return ff_encode_receive_frame(avctx, frame); } + +#define WRAP_CONFIG(allowed_type, field) \ + do { \ + if (codec->type != (allowed_type)) \ + return AVERROR(EINVAL); \ + *out_configs = (field); \ + return 0; \ + } while (0) + +int ff_default_get_supported_config(const AVCodecContext *avctx, + const AVCodec *codec, + enum AVCodecConfig config, + unsigned flags, + const void **out_configs) +{ + switch (config) { +FF_DISABLE_DEPRECATION_WARNINGS + case AV_CODEC_CONFIG_PIX_FORMAT: + WRAP_CONFIG(AVMEDIA_TYPE_VIDEO, codec->pix_fmts); + case AV_CODEC_CONFIG_FRAME_RATE: + WRAP_CONFIG(AVMEDIA_TYPE_VIDEO, codec->supported_framerates); + case AV_CODEC_CONFIG_SAMPLE_RATE: + WRAP_CONFIG(AVMEDIA_TYPE_AUDIO, codec->supported_samplerates); + case AV_CODEC_CONFIG_SAMPLE_FORMAT: + WRAP_CONFIG(AVMEDIA_TYPE_AUDIO, codec->sample_fmts); + case AV_CODEC_CONFIG_CHANNEL_LAYOUT: + WRAP_CONFIG(AVMEDIA_TYPE_AUDIO, codec->ch_layouts); +FF_ENABLE_DEPRECATION_WARNINGS + case AV_CODEC_CONFIG_COLOR_RANGE: + case AV_CODEC_CONFIG_COLOR_SPACE: + *out_configs = NULL; + return 0; + default: + return AVERROR(EINVAL); + } +} + +int avcodec_get_supported_config(const AVCodecContext *avctx, const AVCodec *codec, + enum AVCodecConfig config, unsigned flags, + const void **out) +{ + const FFCodec *codec2; + if (!codec) + codec = avctx->codec; + codec2 = ffcodec(codec); + if (codec2->get_supported_config) { + return codec2->get_supported_config(avctx, codec, config, flags, out); + } else { + return ff_default_get_supported_config(avctx, codec, config, flags, out); + } +} diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h index 83dc487251c..64f31375fc6 100644 --- a/libavcodec/avcodec.h +++ b/libavcodec/avcodec.h @@ -2690,6 +2690,33 @@ int avcodec_get_hw_frames_parameters(AVCodecContext *avctx, enum AVPixelFormat hw_pix_fmt, AVBufferRef **out_frames_ref); +enum AVCodecConfig { + AV_CODEC_CONFIG_PIX_FORMAT, ///< AVPixelFormat, terminated by AV_PIX_FMT_NONE + AV_CODEC_CONFIG_FRAME_RATE, ///< AVRational, terminated by {0, 0} + AV_CODEC_CONFIG_SAMPLE_RATE, ///< int, terminated by 0 + AV_CODEC_CONFIG_SAMPLE_FORMAT, ///< AVSampleFormat, terminated by AV_SAMPLE_FMT_NONE + AV_CODEC_CONFIG_CHANNEL_LAYOUT, ///< AVChannelLayout, terminated by {0} + AV_CODEC_CONFIG_COLOR_RANGE, ///< AVColorRange, terminated by AVCOL_RANGE_UNSPECIFIED + AV_CODEC_CONFIG_COLOR_SPACE, ///< AVColorSpace, terminated by AVCOL_SPC_UNSPECIFIED +}; + +/** + * Retrieve a list of all supported values for a given configuration type. + * + * @param avctx An optional context to use. Values such as + * `strict_std_compliance` may affect the result. If NULL, + * default values are used. + * @param codec The codec to query, or NULL to use avctx->codec. + * @param config The configuration to query. + * @param flags Currently unused; should be set to zero. + * @param out_configs On success, set to a list of configurations, terminated + * by a config-specific terminator, or NULL if all + * possible values are supported. + */ +int avcodec_get_supported_config(const AVCodecContext *avctx, + const AVCodec *codec, enum AVCodecConfig config, + unsigned flags, const void **out_configs); + /** diff --git a/libavcodec/codec.h b/libavcodec/codec.h index 6f9b42760d7..f7541ffc42b 100644 --- a/libavcodec/codec.h +++ b/libavcodec/codec.h @@ -205,10 +205,19 @@ typedef struct AVCodec { */ int capabilities; uint8_t max_lowres; ///< maximum value for lowres supported by the decoder - const AVRational *supported_framerates; ///< array of supported framerates, or NULL if any, array is terminated by {0,0} - const enum AVPixelFormat *pix_fmts; ///< array of supported pixel formats, or NULL if unknown, array is terminated by -1 - const int *supported_samplerates; ///< array of supported audio samplerates, or NULL if unknown, array is terminated by 0 - const enum AVSampleFormat *sample_fmts; ///< array of supported sample formats, or NULL if unknown, array is terminated by -1 + + /** + * Deprecated codec capabilities. + */ + attribute_deprecated + const AVRational *supported_framerates; ///< @deprecated use avcodec_get_supported_config() + attribute_deprecated + const enum AVPixelFormat *pix_fmts; ///< @deprecated use avcodec_get_supported_config() + attribute_deprecated + const int *supported_samplerates; ///< @deprecated use avcodec_get_supported_config() + attribute_deprecated + const enum AVSampleFormat *sample_fmts; ///< @deprecated use avcodec_get_supported_config() + const AVClass *priv_class; ///< AVClass for the private context const AVProfile *profiles; ///< array of recognized profiles, or NULL if unknown, array is terminated by {AV_PROFILE_UNKNOWN} @@ -226,7 +235,9 @@ typedef struct AVCodec { /** * Array of supported channel layouts, terminated with a zeroed layout. + * @deprecated use avcodec_get_supported_config() */ + attribute_deprecated const AVChannelLayout *ch_layouts; } AVCodec; diff --git a/libavcodec/codec_internal.h b/libavcodec/codec_internal.h index d6757e2deff..3c6328364cb 100644 --- a/libavcodec/codec_internal.h +++ b/libavcodec/codec_internal.h @@ -22,6 +22,7 @@ #include <stdint.h> #include "libavutil/attributes.h" +#include "avcodec.h" #include "codec.h" #include "config.h" @@ -264,8 +265,28 @@ typedef struct FFCodec { * List of supported codec_tags, terminated by FF_CODEC_TAGS_END. */ const uint32_t *codec_tags; + + /** + * Custom callback for avcodec_get_supported_config(). If absent, + * ff_default_get_supported_config() will be used. + */ + int (*get_supported_config)(const AVCodecContext *avctx, + const AVCodec *codec, + enum AVCodecConfig config, + unsigned flags, + const void **out_configs); } FFCodec; +/** + * Default implementation for avcodec_get_supported_config(). Will return the + * relevant fields from AVCodec if present, or NULL otherwise. + */ +int ff_default_get_supported_config(const AVCodecContext *avctx, + const AVCodec *codec, + enum AVCodecConfig config, + unsigned flags, + const void **out_configs); + #if CONFIG_SMALL #define CODEC_LONG_NAME(str) .p.long_name = NULL #else diff --git a/libavcodec/version.h b/libavcodec/version.h index 84a1c02ce4a..da54f878874 100644 --- a/libavcodec/version.h +++ b/libavcodec/version.h @@ -29,8 +29,8 @@ #include "version_major.h" -#define LIBAVCODEC_VERSION_MINOR 5 -#define LIBAVCODEC_VERSION_MICRO 101 +#define LIBAVCODEC_VERSION_MINOR 6 +#define LIBAVCODEC_VERSION_MICRO 100 #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \ LIBAVCODEC_VERSION_MINOR, \
From: Niklas Haas <git@haasn.dev> This replaces the myriad of existing lists in AVCodec by a unified API call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite substantially, while also making this more trivially extensible. In addition to the already covered lists, add two new entries for color space and color range, mirroring the newly added negotiable fields in libavfilter. I decided to drop the explicit length field from the API proposed by Andreas Rheinhardt, because having it in place ended up complicating both the codec side and the client side implementations, while also being strictly less flexible (it's trivial to recover a length given a terminator, but requires allocation to add a terminator given a length). Using a terminator also presents less of a porting challenge for existing users of the current API. Once the deprecation period passes for the existing public fields, the rough plan is to move the commonly used fields (such as pix_fmt/sample_fmt) into FFCodec, possibly as a union of audio and video configuration types, and then implement the rarely used fields with custom callbacks. --- doc/APIchanges | 5 ++++ libavcodec/avcodec.c | 51 +++++++++++++++++++++++++++++++++++++ libavcodec/avcodec.h | 27 ++++++++++++++++++++ libavcodec/codec.h | 19 +++++++++++--- libavcodec/codec_internal.h | 21 +++++++++++++++ libavcodec/version.h | 4 +-- 6 files changed, 121 insertions(+), 6 deletions(-)