On Sun, Mar 06, 2016 at 08:43:15AM -0500, Ronald S. Bultje wrote: > We have a lot of infrastructure for it already available > > though, like VLC code reading (though only in libavcodec, > > not libavutil). > > This is a hackish quick-and-dirty version. > > It certainly is not optimized, and I would want it to > > be mostly small/simple, not necessarily fast anyway > > as it would at most be a fallback. > > Is there interest in me cleaning up the code and > > integrating it as fallback, or are you all happy > > with zlib and I should drop it? > > Well, you skim over performance, it'd be nice to get some figures of how > much faster/slower it is. Binary size may also be a factor in some > situations (if zlib is included static).
Problem with performance is that to be honest gzip is so simple it's not trivial to measure. When I tried I got about 160 MB/s (compressed side). Which probably is like 1/4th of the speed of zlib. But it will very strongly depend on content. It could be optimized by using the GET_VLC macro instead of get_vlc2, which is quite inefficient for long stretches of purely Huffman coded symbols. It's not so slow it should cause actual problems though IMO... As to size, it is 6 to 9 kB (depends on -Os vs. -O3), but as said depends on the FFmpeg bitstream infrastructure. For zlib, the absolute minimum would be inflate.o (18kB) and probably a few others like inftrees.o (4 kB). Might be up to 40 kB, expect I'd have to actually write a test program to be sure what is needed or not. > How often is zlib not available? I mean, afaik, it's even present on MSVC > builds or iPhone/Android builds. I think we sort of have to quantify how > much of an issue this really is. What do you mean by "present"? Yes, you can compile zlib for almost anything. It's not a real issue in that way. It doesn't follow along with MSVC though, but is part of Android NDK. For me it's mostly a pain when cross-compiling for qemu-user, whether ARM (not Android), PPC, ... when I have to either compile and munge in zlib or I can't even run the png FATE tests (and surprisingly many others)... While it's only a fallback it won't help for that, but I am also every time annoyed by zlib's lack of const-correctness and simple API (it only has the stream based thing, and needs at least 3 calls to decompress anything, and don't ask me about that alloc/free interface magic we are doing in our png decoder, I could not find documentation why we're doing that). Then there is also the academic interest in writing inflate in terms compatible with FFmpeg's bitstream primitives. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
