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

Nicolas George george at nsup.org
Thu May 19 23:05:11 CEST 2016


Le primidi 1er prairial, an CCXXIV, Michael Niedermayer a écrit :
> 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

Note: since we stopped ABI compatibility, this point is now moot. But I want
to make things clears.

It was not clear at the time that achieving this was your goal. If so, I
think I would have objected: it was not our task to help people use the
extra features of FFmpeg while still staying with libav.

> 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

Once again, you confuse everything. Accessors are for applications, AVOption
are for users. If you add an AVOption for something that the user needs to
set, that is perfectly fine. I was referring to a case you added an AVOption
for something completely inaccessible to the user; I do not remember the
specifics.

> 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

Please keep focused on the question at hand, or at least try to be aware and
explicit when you take a tangent. We do not have a differentiated set of
AVOption for AVCodecContext / AVFormatContext depending on the codec or
muxer or whatever, and therefore it does not give any information not
carried by the C structure and its documentation.

> 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 ?

Well, they can not know that with the current API, but it is an unrelated
question.

> 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

It could, but it does not, and nobody proposed that. IMHO, this is not a
good approach. If some codecs use gop_size and some don't, then it should
just be a private option.

> 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
> supports

Still the same confusion. AVOption for user interaction is fine.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160519/cf98c6da/attachment.sig>


More information about the ffmpeg-devel mailing list