[Ffmpeg-devel] Native zlib decoder

[Måns Rullgård]

Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:

> Hi
>
> Kostya wrote:
>> On Mon, Mar 19, 2007 at 04:41:06PM -0000, M?ns Rullg?rd wrote:
>>> As you may have gathered, I started working on a native zlib
>>> decoder for lavc.
>>>
>>> I have the basics working, i.e. I can decode a single deflate block
>>> coded with any of the coding methods (uncompressed, fixed Huffman
>>> tables, dynamic Huffman tables).
>>>
>>> Before I go further, I'd like some opinions on what kind of API
>>> would be most useful within lavc.  If I hear nothing, I'll examine
>>> the existing usage of zlib and try to make something suitable for
>>> all the cases.
>>>
>>> My main concern is output buffer management.  The decoder needs
>>> access to the last 32k of output, and I'd prefer not to copy data
>>> when it can be avoided.
>>>
>>> The PNG decoder, for instance, is easy to handle.  The output data
>>> size is known in advance, and the entire compressed input is
>>> available at once.  I'd like to also cope with arbitrarily long
>>> inputs and outputs without adversely affecting the simple cases.
>> As an author of about half of those decoders using ZLib I'd say that
>> in most cases simple uncompress() would satisfy all the needs. IIRC
>> only ZMBV codec requires context to decode.
>> 
>> So my proposition is to have ff_zlib_uncompress(dst, &dst_size, src,
>> src_size) and ZMBV can be workarounded later.

That seems reasonable for the simple cases.  For longer streams we
could have another function using a context.

>> BTW, MOV demuxer is also the place where zlib decoder is needed.
>
> Yes, speaking of that, it would be nice to have something like a
> ByteIOStream with underlying zlib decompression, dunno if that is
> feasible though.

Anything is possible.  The question is whether it's worth the trouble.

-- 
M?ns Rullg?rd
mans at mansr.com