[FFmpeg-devel] [PATCH] avcodec: Add AVClass to AVCodecParameters

[Ronald S. Bultje]

Hi,

On Tue, May 17, 2016 at 10:04 AM, Michael Niedermayer <
michael at niedermayer.cc> wrote:

> On Tue, May 17, 2016 at 06:49:44AM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Tue, May 17, 2016 at 6:07 AM, Michael Niedermayer
> <michael at niedermayer.cc
> > > wrote:
> >
> > > Most of the major public structures contain an AVClass.
> >
> >
> > What are you hoping to accomplish with this struct that can currently not
> > be done because it doesn't have an AVClass on top? I haven't seen this
> > question answered anywhere yet, I think.
>
> Its primarely for consistency and cleanup
> presenting a consistent API to the end user and not one thats
> different for each struct
>
> What iam missing is a discussion about
> 1. should all public structs have a AVClass, should some, should none
> 2. should all public structs be accessible through AVOptions, should
>    some, should none
>
> and then the resulting consens to be applied everywhere consistently
>
> what we have is that sometimes things get done one way and the next
> time they get done the opposit way.
> AVClass is one example, we for example use it for nearly all of the
> many codecs private contexts, its used for most public structs
> but here with AVCodecParameters theres a wall of people who seem
> against it.


I think we have to move away (for just one second) from "how it works" to
"why does it work that way". Let me give an example:

Question: why do (some) private codec contexts have AVClass?
Answer: private codec options!

OK, that was really simple. So now, we can answer the inverse question:

Question: which private codec contexts should have an AVClass?
Answer: those that use private codec options!

Note that this might not be the only reason private codec contexts use
AVClass. There may be other reasons, and as we extend the "why" cases, the
"which" Q&A needs to be updated accordingly.

So, to answer the question of whether AVCodecParameter should have an
AVClass associated with it, I believe we should answer the question why it
should have one. Consistency might be a reason, but is a weak one, since
we're entirely inconsistent anyway. Consistency can only be applied
globally, not to this one specific case, because then by definition, it is
not actually any more consistent.

So, again my question: why do you want AVCodecParameter to have an AVClass?

Ronald