[FFmpeg-devel] [PATCH v6 2/4] lavu: Clarify relationship between AVClass, AVOption and context

Andrew Sayers ffmpeg-devel at pileofstuff.org
Wed Jun 5 15:46:15 EEST 2024


On Wed, Jun 05, 2024 at 12:34:48PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2024-06-04 15:47:22 +0100, Andrew Sayers wrote:
<snip - language choices we can talk about in future>
> > + * Structs that only use logging facilities are often referred to as
> > + * "AVClass context structures", while those that provide configuration
> > + * options are called "AVOptions-enabled structs".
> 
> A struct with an AVClass as its first member can be used for both
> logging and options management, there is no difference between the
> two. My take:
> |Structs that use AVClass might be referred to as AVClass
> |contexts/structures, those that in addition define options might be
> |called AVOptions contexts/structures.

I think you were away when this came up, and anyway this thread is getting
quite unwieldy.  See [1] and [2] for the full version, but in short, defining
AVClass by layout leads to conclusions that are at best unintuitive.

<snip - AVOptions text>
> > + * Note that AVOptions is not reentrant, and that many FFmpeg functions access
> 
> ... AVOptions access is not reeentrant ...
> 
> > + * options from separate threads.  Unless otherwise indicated, it is best to
> > + * avoid modifying options once a struct has been initialized.
> 
> But this note is not relevant to the change, and should probably be
> discussed separately

Short version: I'll make a separate patch now, let's come back to this after

Long version...

If you assume options can be set at any time, they broadly resemble a reflection
mechanism.  If you assume they can only be set during the configuration stage,
they broadly resemble an OOP constructor.  The document needs to address the one
they resemble (even if just to say "this is why they're different"), and needs
to steer clear of any possible comparison with the one they don't resemble.
So it would be too risky to bump this to the upcoming omnibus patchset,
but it's fine to apply this *before* the context document.

[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2024-May/328058.html
[2] https://ffmpeg.org/pipermail/ffmpeg-devel/2024-May/328087.html


More information about the ffmpeg-devel mailing list