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

[Alexandre Janniaux]

Hi,

Actually if you want "safe", then an issue is indeed the correct way. 
Issues are discussion about task. You can use the same way we did for 
workshops summaries and design discussion.

Even though some people don't have a gitlab account and cannot 
participate, the developers on VLC are the ones that are involved here, 
and they have a gitlab account.

This is also handy to reference the discussion in the commit later.

Regards,
--
Alexandre Janniaux
Videolabs


On 29/04/2025 17:21, Fatih Uzunoğlu wrote:
> 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.
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel