> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Andreas Rheinhardt > Sent: Monday, June 16, 2025 8:52 PM > To: ffmpeg-devel@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-boun...@ffmpeg.org> On Behalf Of > >> Andreas Rheinhardt > >> Sent: Dienstag, 3. Juni 2025 16:34 > >> To: ffmpeg-devel@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
