Michael Niedermayer (12024-10-15): > The question: Should anyone be able to write a filter (which > other people can use) ? > Or should only we be able to add filters ?
There are two sides to the issue: making the filter work and registering it. To make the filter work, it needs to access APIs that are not public. Some of these APIs are quite convoluted and will evolve, especially everything related to negotiation. Making them public would make the development a lot more cumbersome and slow it down dramatically. There are solution though. As you pointed out, somebody can build using our source tree instead of installed headers, and clearly document that their program works only with a limited range of versions. There is nothing for us to do to support that kind process. But we could offer some support to ease the version check. Another solution would be to offer a more limited and less efficient API for external filters. More limited and less efficient but stable, so that it can be public. The problem with this solution is that this API would need to be designed properly. That is not a small amount of work. And right now there is nobody capable and willing to do it. Just making the filter work makes it possible to use it in a program, passing its AVFilter * to avfilter_graph_create_filter(). But it will not make the filter available by name. So no chance to inject it into existing programs (LD_PRELOAD), into ffmpeg (new command line option) or just in the same application through a user-provided graph description. For that, we would have to bring back the dynamic registering of components. We should anyway, because the whitelist mechanism is bullshit. In terms of security, you do not add access restriction by adding checks everywhere: you will forget places and it will make the restrictions void. For efficacious restrictions, all the code must see only the enabled components. This is the way to make it work: have AVFilterLibraryInstance (and AVCodecLibraryInstance and… connected to each other), in which the components are dynamically registered. Calls that require access to the list of components get a pointer to an instance of that structure; most of them get it through a context. For compatibility with functions that get no context, allocate one global instance. Also, the instances must be refcounted, and not with an extra indirection (so AVBufferRef → 🗑️). Eventually, these AVWhateverLibraryInstance take charge of all global mutable state: log callback, threads manager, overridden memory allocation functions, etc. I have had all this designed for quite some time. Regards, -- Nicolas George _______________________________________________ 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".
