[FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs
mfcc64 at gmail.com
Wed Feb 21 11:04:15 EET 2018
On Tue, Feb 20, 2018 at 2:30 AM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> 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
Just an idea.
Is it possible to generate just one executable to fuzz all decoders?
The target decoder can be added as an argument or environment variable.
e.g: ./fuzzer --target aac
or FUZZER_TARGET=aac ./fuzzer
With this approach, we can save lot of disk space.
> 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
> There can also be an advantage security wise if unneeded parts are never
> 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.
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel