softworkz . (HE12025-06-16): > But why that? If we include the decompression code (that's why I've been > searching for the most compact implementations available with compatible > licenses), then we won't have any zlib dependency anymore - neither at build- > nor at run-time.
Wait. What you want to do is not offer the option to link with a different implementation of decompression feature but import the code of a certain library into our source tree? We do not do that. If somebody would write an implementation of zlib specifically for ffmpeg, using av_malloc() and av_log() and all our utility API, and if that implementation had some kind of benefit over any existing implementation, then we would be happy to adopt it. But dumping somebody else's code into our source tree, increasing our maintenance burden, just to avoid linking with system zlib… WTF? Only somebody who does not understand what FFmpeg stands for would suggest that. -- 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".
