[FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

Stefano Sabatini stefasab at gmail.com
Tue Apr 23 23:27:22 EEST 2024


Il mar 23 apr 2024, 13:18 Michael Niedermayer <michael at niedermayer.cc> ha
scritto:

> On Tue, Apr 23, 2024 at 01:15:52PM +0200, Michael Niedermayer wrote:
> > On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> > > On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > > > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > > > lavu/opt: Clarify that AVOptions is not indended for general
> use
> > > > > >
> > > > > > They _are_ intended for general use though.
> > > > >
> > > > > In that case I'm confused...
> > > > >
> [...]
> > still you certainly can handle binary data (like a bitmap picture)
> through
> > AVOption
>
> And if you disagree, which you probably do :)
> send a patch to improve AVOption to cover more general use
>

I think the real point is not that AVOptions/AVClass cannot be used in a
generic application, but that using them is not the point of employing
libav* libraries. In fact, if only part of your application is about
multimedia, probably you will be using the encoding or muxing or filtering
API but it's unlikely you will use AVOptions for generic non-multimedia
code, and you will be already using some other generic toolkit for handling
struct properties. This entails that practically AVOptions/AVClass is
mostly used to develop FFmpeg internals.

So even if the AVOptions API is generic, its use is not really the selling
point of the FFmpeg libraries, and therefore the user is not really
*expected* to use directly them to extend his generic structs, even if that
might be possible.

>


More information about the ffmpeg-devel mailing list