> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
> Andreas Rheinhardt
> Sent: Monday, June 16, 2025 9:24 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: 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.
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
_______________________________________________
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".
