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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Andreas Rheinhardt
> Sent: Monday, June 16, 2025 8:52 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH WIP 01/10] ffbuild/bin2c: Use zlib
> directly instead of gzip
> 
> softworkz .:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: Dienstag, 3. Juni 2025 16:34
> >> To: ffmpeg-devel at ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH WIP 01/10] ffbuild/bin2c: Use zlib
> >> directly instead of gzip
> >>
> >
> > Hi Andreas,
> >
> > thinking about the direction of this patchset, I came to this idea:
> >
> > How about ditching zlib altogether for this and replace it with some
> > compact compression code right away?
> >
> > Something like these might be suitable:
> >
> > https://github.com/ariya/FastLZ/blob/master/fastlz.c
> > https://github.com/richgel999/miniz/blob/master/miniz.c
> > (licenses should be compatible for including the code)
> >
> >
> > This would solve both problems:
> >
> > - zlib detection during build
> > - zlib being unavailable at runtime when linked dynamically
> >
> >
> > How do you think about this?
> >
> > I think it wouldn't matter when the compression is slightly less effective..
> >

Hi Andreas,

> The compressed objects will be included in many binaries (and I guess that
> most users will never ever use them...). They should therefore be as small as
> possible.

What I meant is that when it would be like 5 or 10% less in compression ratio,
the benefits would still outweigh. But I suppose you'll get pretty close to zlib
anyway.

> But the approach of simply including the code for compression is a good one.
> It solves the zlib-detection-during-build problem and the .text size of the
> encoding code does not matter given that bin2c only exists on the dev
> machine. I'll implement this.

And - as I just realized after suggesting it - there are even more benefits:

- the dual code paths for handling compressed/non-compressed resources
  Will become obsolete
- same for the conditional pattern rules in common.mak
- and finally, the configure parameters --disable-ptx-compression and 
  --disable-resource-compression can be dropped as well

All in all it will be a big win on several sides. Sounds like a good plan 😊 

Thanks,
sw