Re: [FFmpeg-devel] [PATCH 01/11] avcodec: add avcodec_get_supported_config()

[Niklas Haas <ffmpeg@haasn.xyz>]

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?
_______________________________________________
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".