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. 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. Therefore, I am rather strongly against adding AVClass fields to new structures. I will not object in this instance if that fits the current normal use of AVOption: if a patch series can make it so that dash-option on the ffmpeg command-line reaches AVCodecParameters and does something useful, then ok. But adding it just in case, no. Note that I am easily convinced this is actually useful: if an option of AVCodecParameters parameter could replace all the "video_size", "framerate", etc., private options of rawvideodec, image2dec, etc., then adding the fields is certainly a good idea. Still, there probably was a reason to make these private options instead of accessing the codec fields directly like it used to work. I do not remember what this reason was, and I have not yet looked closely enough at AVCodecParameters to know if it can work that way. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
