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 supports [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel