On 08/04/15 4:29 PM, Ronald S. Bultje wrote: > Yeah I didn't test it. Anyway, the goal is indeed to remove 200 bytes. I > don't care about the 200 bytes. I care that a vp9-decoder-only build has > about 100 source files, most of which are obviously not needed. I care > about the sum of the parts, not any part alone. Some examples of what code
Ah, in that case it's certainly a good idea. > my beautifully small libav* was compiling: > > libavformat: id3v1.o, id3v2.o, sdp.o, riff.o, mux.o > libavcodec: vorbis_parser.o, xiph.o, avdct.o, audioconvert.o, bswapdsp.o, Odd, bswapdsp shouldn't be built if it's a vp9 decoder only build. configure supposedly enables it only with some specific decoders and encoders, and vp9 is not one of them. > dv_profile.o, imgconvert.o, qsv_api.o, resample.o, resample2.o > libavutil: EVERYTHING True, libavutil pretty much compiles everything unconditionally. There were talks about making it modularized like the other libs, but it never went anywhere. A vp9-decoder-only certainly doesn't need all the crypto stuff beyond crc or md5. Right now i think only pixelutils (needed by some lavfi filters) can be disabled with configure. > external libs linked: xlib, zlib, vda, xcb, iconv, bzlib, lzma Afaik those are considered "system" libs, so they are enabled by default unlike external decoder/encoder libraries. It could certainly be changed so they are not linked if no module requires them, like bzlib which is needed only by matroska demuxer, or lzma by the tiff decoder. You can nonetheless disable them all with --disable-whatever with configure for now. > > I'm happy to do some work on each of the above and make it easier to create > minimal libav* builds; the emms is obviously insignificant in and by > itself, but we can certainly do better than this and the overall effect > would be useful. Agree. libavutil shouldn't be hard since every module is pretty much standalone. What needs to be decided is if we do like pixelutils (install the header unconditionally, but error out when the API is used and the library was compiled without the functionality), or not install/compile anything at all. It probably comes down to what will create the least amount of havoc downstream. > > Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
