Re: [FFmpeg-devel] [PATCH 01/11] avcodec: add avcodec_get_supported_config()
On Thu, 11 Apr 2024 00:09:05 +0200 Michael Niedermayer 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 > > wrote: > > > On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > > > > From: Niklas Haas > > > > > > > > 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? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/11] avcodec: add avcodec_get_supported_config()
On Mon, Apr 08, 2024 at 11:55:02PM +0200, Niklas Haas wrote: > On Mon, 08 Apr 2024 22:18:33 +0200 Michael Niedermayer > wrote: > > On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > > > From: Niklas Haas > > > > > > 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/11] avcodec: add avcodec_get_supported_config()
On Mon, 08 Apr 2024 22:18:33 +0200 Michael Niedermayer wrote: > On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > > From: Niklas Haas > > > > 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-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/11] avcodec: add avcodec_get_supported_config()
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 > > > > 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/11] avcodec: add avcodec_get_supported_config()
On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > From: Niklas Haas > > 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/11] avcodec: add avcodec_get_supported_config()
On Sun, 07 Apr 2024 01:16:39 +0200 Michael Niedermayer wrote: > On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > > From: Niklas Haas > > > > 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-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/11] avcodec: add avcodec_get_supported_config()
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 > > > > 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. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/11] avcodec: add avcodec_get_supported_config()
On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > From: Niklas Haas > > 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 [...] -- 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 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/11] avcodec: add avcodec_get_supported_config()
On Fri, 05 Apr 2024 20:57:11 +0200 Niklas Haas wrote: > From: Niklas Haas > 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 01/11] avcodec: add avcodec_get_supported_config()
From: Niklas Haas
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(-)
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 - xx - 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 - xx - 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,
