[FFmpeg-devel] [PATCH] [RFC] proof-of-concept minimal inflate.

[Reimar Döffinger]

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.