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

[Fatih Uzunoğlu]

Hello,

I wanted to wait a while before replying to see if more people would be 
involved. Since no one has joined the discussion, I think it is safe to 
assume that no one objects to the proposed changes here.

 > I think discussions should happen in an issue (Feature Request) as 
doing it here will probably have less visibility, but we'll see.

Since this is not an "issue", I'm not sure what is the best to do 
regarding these. GitLab does not allow me to classify as "task". In the 
past, I opened a few of these marked as "incident", but I nowadays think 
the development mailing list is better suited for non-issues. Everyone 
can participate here, but I'm aware that some people can't/don't use GitLab.

 > There's only one way to settle this: actual numbers for the time it 
takes to start between the two.

I was told that performance is the top priority, so numbers should not 
matter as long as switching does not bring additional problems.

 > IMO we should have zstd. My understanding is that it's much faster to 
compress/decompress but it doesn't compress very well. For this 
particular use case it seems to better candidate.

Are we willing to build zstd twice (for cross platform case)? And, if 
zlib is used by multiple contribs and zstd only by Qt, then we still 
would like to make zlib faster. But that does not mean that we should 
not use zstd, at least that can be used by Qt for the moment.

 > The license is pretty clear, it's BSD

If I remember correctly, the problem was re-licensing without consent. 
I'm not sure if it is okay to _knowingly_ use such programs. Of course, 
it is hard to ensure if all contribs adhere to their licenses, but if it 
is _clear_ that a program violates its license, then it may be bad faith 
to use it / continue using it.

For reference, this was the thread noticing this: 
https://code.videolan.org/videolan/vlc/-/merge_requests/4791#note_423073.

 > I'm not sure how more reliable it is to the official zlib.

It seems to be well established at this point, after 10 years of its 
introduction and considering its popularity. But, the Chromium fork may 
be better for reliability, for obvious reasons. If I had to choose 
myself, I would go with zlib-ng.

 > We do but I'm not sure C/C++ contribs should depend on a rust 
contrib. At least not a hard dependency.

OK, let's put zlib-rs off the table. It seems there are two viable 
alternatives if we want to switch, the Chromium fork, and zlib-ng.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20250429/1bfab9b9/attachment.htm>
-------------- 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/20250429/1bfab9b9/attachment.bin>