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

[Andreas Rheinhardt]

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

zlib availability is not an onerous requirement (and in our case not
even a hard requirement); several components already have such a
depedency (e.g. Matroska allows zlib compression and files using it are
common, png (both decoder and encoder) requires zlib, the http(s)
protocol requires it for zlib handling).
If we include the decompression code, then this code exists in every
tool (and in libavfilter). If said code also performs worse
(compression-wise) than zlib/brotli, then this is a big no for me.

- Andreas