Jean-Baptiste Kempf (12020-07-05): > Also in this example, noone is telling them to fork, just to use the > API to register their custom protocol.
About this, I think there are two separate issues. One is that recent effort to get rid of mutable global state. Registering custom protocols involves modifying global state, and therefore has been made impossible by efforts to be able to add "const" whenever possible. This issue is actually easy to solve. The patch about avrefcount_template.h was actually the first step towards my solution to it: to have potentially multiple mutable states, with protocols, formats, codecs, filters lists. That way, we can bring back the dynamic lists of components without the drawbacks we wanted to eliminate. And there are a few extra benefits: no interference if different parts of a huge application register different components; a more reliable way of enabling only a few selected components (the systems of whitelist used now is an afterthought, afterthoughts are terrible for security; and we will have to rename them anyway). It is a bit tricky, because it spans several libraries (this always makes things harder), but I have solutions. If I can explain these solutions to somebody in charge and have them pre-approved in general principle, I can work on the code rather quickly. But if I code with the risk of it getting bikeshedded to death immediately, it is debilitating. So again: not a very hard issue, but requires something at the helm, to decide the orientation of the project. The other issue is much more burdensome. If you remember, at the beginning of libavfilter, applications could register custom filters. We ended up making it private to be able to evolve it. The problem is API stability. Changing an internal API is easy: just change it, and fix all the build failure, or grep for all uses of the function. Changing a public API is much more trouble. Anton could probably never have achieved the change from AVBufferRef to AVFrame in libavfilter if all the internal filtering APIs had been public and required careful compatibility. Same for me reworking the scheduling to make it by message instead of recursive. There are partial solutions yet: - The internal API have somewhat stabilized. Things that seemed a good idea at the time but were too complex have been eliminated. That will help. - We can make the public API less powerful than the internal API. No direct rendering or other extra optimizations to avoid data copy. No fancy format negotiation. No access to ultra-optimized computation building blocks. - We can make the public API less stable. I am serious, it is an entirely acceptable solution. These are just applications, not life-and-death situations, "do it at your own risk" is not worse than "don't do it". We can have headers that clearly indicate "if you use something from this header, we do not guarantee it will keep working, you will have to check if it still works after each update. And if people are not happy about lack of stability, they can come and help. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
