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

[Fatih Uzunoğlu]

Hello,

OK, I have opened https://code.videolan.org/videolan/vlc/-/issues/29141 
and https://code.videolan.org/videolan/vlc/-/issues/29142.

On 4/29/25 18:28, Alexandre Janniaux wrote:
> 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
>
-------------- 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/f13b3fe7/attachment.bin>