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

Michael Niedermayer michael at niedermayer.cc
Tue May 17 16:04:42 CEST 2016

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.
FFmpeg will move the way the people working on it want it, so of
course if people are against it it wont be done but are people
against consistency too because this is not consistent

another example of such inconsistency is side data
some of the side data structs are defined as a bytestream and some
as C structures. The first can be stored in files and passed over
teh network as is but needs extra code to move into a struct
the 2nd is a struct (if its aligned) but needs extra code to move
over the network or into files

for the side data too i think the ffmpeg community should decide and
stick to the choice for all cases

"another issue that iam hoping to accomplish with this struct that can
currently not  be done because it doesn't have an AVClass on top"
is to avoid the pain of adding one after the next release when that
would break ABI
we hit a similar thing with AVFrame previously ...
the troubble from adding one and not needing it is small the opposit
of not adding it and then needing it is big as the ABI would need
to be broken to add it later

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160517/4fe3e917/attachment.sig>

More information about the ffmpeg-devel mailing list