[FFmpeg-devel] [PATCH] avcodec: Add AVClass to AVCodecParameters
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
> 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
> 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
Still the same confusion. AVOption for user interaction is fine.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the ffmpeg-devel