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

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

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