[vlc-devel] Regarding switching to zlib-ng in contribs

[Fatih Uzunoğlu]

Hello,

I have tried to search for previous discussions regarding switching to 
zlib-ng in the mailing list and GitLab, but could not find. My 
understanding is that zlib-ng has been maintained better than the 
original zlib. It reportedly is much faster, and compresses slightly better.

This is relevant for the Qt interface a lot, because all resources 
(which includes the compiled shader bytecode "qsb" files, and all QML 
files that are not compiled by `qmlcachegen`), and possibly the QML 
bytecode too outside the resource system (when `qmlcachegen` is used) 
are compressed and all of them need to be decompressed synchronously in 
bulk during start-up. High decompression speed would make at least the 
interface start faster.

I previously attempted to introduce zstd (as Qt does not provide this 
itself) in !4791 
(https://code.videolan.org/videolan/vlc/-/merge_requests/4791), which 
became the default since Qt 6. However, I decided to not proceed with 
that because 1) the license of it does not seem too clear and 2) it 
needs to be built two times (one for host, used for compression by rcc; 
one for target (when cross compiled), used for decompression by qtbase), 
and this is not nice when zlib still needs to be built anyway for other 
contribs.

It seems that we are still not interested in using zstd. So a drop-in 
replacement for zlib that boosts the performance would be nice.

Any opinions on this? My biggest worry is regarding security, can 
zlib-ng be considered as secure as zlib? Are the maintainers well 
established and trustworthy? If this is a problem, maybe the Chromium 
fork of zlib (`zlib-chromium`) can be another alternative, which I 
assume would be secure enough. There are some notes regarding the 
Chromium fork here: https://github.com/madler/zlib/issues/346.

Alternatively, I have also read about zlib-rs, but Rust can be a 
problem. Do we even demand a Rust toolchain?

I have found some benchmarks here: 
https://github.com/zlib-ng/zlib-ng/issues/1486, 
https://trifectatech.org/blog/zlib-rs-is-faster-than-c/.

Sincerely,
Fatih Uzunoğlu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4676 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20250411/9791f25c/attachment.bin>