On Sun, Feb 18, 2018 at 05:58:16PM +0000, Josh de Kock wrote: > This should be the last of the major API changes. I'm not entirely > sure if I missed anything.
Moving from a register based system where a user app can register any subset to a system which registers all via an array will increase the size of statically linked binaries for users only using a subset. An example of this effect for codecs is tools/target_dec_fuzzer.c This effect results because when the linker collects all objects of all static libs with a user application it can remove all symbols which are not referenced. If there is a single array that references all codecs, filters, formats and this array is referenced by a function which must be used then nothing can be removed at the link stage OTOH with a register function a register all which refernces all a user application can simply not use the reference all code and register the specific subset it needs with individual register calls. In this case the linker can ommit the register all and all codecs, formats and filters teh user application does not explicitly refer too. In the case where this applies this results in significantly smaller files I also expect they link faster and load faster but i forgot to benchmark this when i realized this issue exists and tested ... I am thus in favor of a system that does not unconditionally reference every codec/format/filter There can also be an advantage security wise if unneeded parts are never "registered" [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
