[FFmpeg-devel] [PATCH WIP 01/10] ffbuild/bin2c: Use zlib directly instead of gzip

softworkz . softworkz at hotmail.com
Tue Jun 17 16:23:30 EEST 2025



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Tuesday, June 17, 2025 11:30 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH WIP 01/10] ffbuild/bin2c: Use zlib
> directly instead of gzip
> 
> 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.

It's not about replacing zlib in general. The scope is having our own compression
code for ptx and resource compression only. I gave a number of examples for 
how this could possibly be achieved with a small amount of code - which of 
course would need to be adapted to match our style and procedures.

The compression side would be in bin2c and only the decompression code
would ship (e.g. in avutil). Only if that part would be really small, the benefits
would weigh out the size added by the decomp code.

As long as we don't know the compression ratios achievable with such low-code
compression routines, this is merely an idea which might not work out at all
but at least worth exploring IMO.

Anyway, I'm not surprised. Making wrong assumptions and then ranting about,
is one of your most typical patterns.

Best regards,
sw



More information about the ffmpeg-devel mailing list