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

Michael Niedermayer michael at niedermayer.cc
Thu May 19 14:14:08 CEST 2016

On Thu, May 19, 2016 at 12:08:25PM +0200, Nicolas George wrote:
> Le nonidi 29 floréal, an CCXXIV, Michael Niedermayer a écrit :
> > there where and are accessor functions:
> > git grep MAKE_ACCESSORS
> Yes, and they should have been the only way of avoiding ABI compatibility
> issues.

applications which supported both libav and ffmpeg cannot use symbols
that exist in only one of the forks as it would break linking.

the same AVOption based code works with both forks though

using accessors 2 different pieces of code would be needed and thus
also different binaries

Also with just accessors and no entry in AVOption
ffmpeg.c, ffplay.c and ffprobe.c would have needed explicit support
for each individual parameter instead of just generically exposing
the whole set of options

> Another point against AVClass: FFmpeg is mostly in C, C has static typing
> and static typing is good.
> That means that almost everywhere where AVClass is used, we know the type of
> the structure we are handling, and therefore we know what AVClass we should
> use. It could be an explicit parameter instead of an implicit parameter
> hidden in the first field of the structure. The only case where we need it
> is for private context for dynamic typing.

Theres the case ronald raised, that is the huge mess of options in
AVCodecContext and AVFormatContext
the type of these structures is known generally but not which of
the options apply to the codec at hand

A user application and the user want to know what options are relevant
to the codec at hand
is thebit_rate_tolerance going to be honored, is the gop_size,
the max_b_frames, the intra_matrix or the block align value ?

an AVClass in the first element of AVCodecContext with its AVOption
list can give an application this precisse list of
which of the options work on the actual used codec

C tells you about the fields that where listed at build time in the
included header, that are all fields that any codec could use from
AVCodecContext. Like ronald said that is a mess from the user
applications point of view
AVClass&AVOption could provide your application with a list of what
the actually linked lib at runtime with the actually selected codec


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- 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/20160519/4b92fdc9/attachment.sig>

More information about the ffmpeg-devel mailing list