[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 9:24 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: 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.
> 
> I'll try your tiny compression libaries as well as zlib and brotli and report back.

Awesome!

> >> 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
> 
> I do not intend to remove these options; in fact, we will always have to keep
> the codepath for creating uncompressed objects (because otherwise we
> would make zlib a hard requirement on the target system).

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.

Thanks,
sw