softworkz .: > >> -----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.
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 > _______________________________________________ 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".
