Le nonidi 29 floréal, an CCXXIV, Ronald S. Bultje a écrit : > It's not for us (ffmpeg.c developers), it's for people using the ffmpeg > libraries on other language platforms (e.g. python).
I think one of the cruxes of the issue is that we are (ab)using the AVOption system for two different things: introspection and uniform access to structure members for libraries and language bindings, and user interaction. For introspection to work, all public fields of all structures that have some need to be accessible. Libraries can make a few exceptions, and therefore we can get away with one "almost" in the previous sentence, but not two. We are nowhere near it and we will never achieve it. And we probably would not want it anyway. Plus, the AV_OPT_TYPE system is way too limited and the lookup is very inefficient. Michael used the AVOption system as a quick way to give access to fields that were not present in the fork without breaking ABI compatibility, but I think this was a mistake, it would have been better to just write an accessor function. Since we have dropped ABI compatibility with the fork, we can forget all this now. That leaves user interaction: the AVOption system was designed for that, and works reasonably well for it. Therefore, the relevant question should be: are there fields that need to be accessible to the user in a generic way? Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel