[Ffmpeg-devel] Native zlib decoder

[Baptiste Coudurier]

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.
> 
> 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.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312