The VideoLAN Forums

What are the advantages of 64 bit vs 32 bit VLC player? I just noticed VLC has a 64 bit version and can't see any differences.

Along the same lines, I notice that there is NOT a 64-bit VLC available at the official site https://www.videolan.org/vlc/, at least not for Windows; there's only a single download available for 2.2.6, and it says "32" right there in the filename. So I have to assume that all the 64-bit versions available at places like http://download.cnet.com/VLC-Media-Play ... 61094.html are unofficial builds.

Right?

And if so, why aren't there any official x64 builds for Windows?

I'm asking because the x64 version I'm currently trying out seems to be lacking various features. I'd like a 64-bit VLC if possible but I want an official build.

The current version can be downloaded here at http://download.videolan.org/pub/videolan/vlc/2.2.6/
There are 32 and 64 bit versions available. The 64 bit one I have, has a digital signature by VideoLAN.

For what I do, I have not noticed any difference between the 32 and 64 bit VLCs.

Thanks for the link. Although I must say that you shouldn't have had been put to the trouble to post it here. That link should be on the main download page. What are the VLC web admins thinking?

Does anyone know the answer to this question?

There is no straight answer. In theory, the 64-bits build is faster for certain tasks that benefit from the extra bits. But then again, it is also marginally slower overall due to larger memory consumption and therefore cache overhead.

I don't see a lot of difference between the 32 bit and 64 bit. There would be a security difference if VLC enabled ASLR in their builds, but when they compile they strip .reloc information and hence ASLR won't work¹, even though the linker is set to dynamic base.

I pointed out the missing .reloc earlier and pointed to a possible solution. https://forum.videolan.org/viewtopic.php?f=14&t=138052
I checked with a VLC 3 exe and .reloc was still being stripped.

From a memory standpoint, a 64 bit VLC can access more memory. My last 32 bit VLC from much earlier in the year was not Large Memory Aware, so it is capped at 2GB. If it was large memory aware, it could access up to 4GB on a 64 bit box with sufficient memory.

For what I do, the 32 and 64 bit versions performed identically. However the 32 bit version goes through a windows emulation layer that enables the 32 bit. The 64 bit runs natively. So, my rule is, absent any difference, I run 64 bit. If there is a difference, I'll use the one that works better.

I use the EMET security mitigations, and those work better on 64 bit on a 64 bit machine. They work as good on a 32 bit VLC on a 32 bit machine. it is 32 on 64 bit where there are weaknesses in the EMET mitigations due to the WoW64 emulation layer.

¹ http://www.cs.columbia.edu/~vpappas/pap ... raid14.pdf No relo no ASLR

I don't see a lot of difference between the 32 bit and 64 bit. There would be a security difference if VLC enabled ASLR in their builds, but when they compile they strip .reloc information and hence ASLR won't work¹, even though the linker is set to dynamic base.

Using relocations to support ASLR is retarded. In fact, using relocations for anything is retarded since it slows down loading and prevents sharing of read-only pages. Any reasonable operating system uses position-independent code instead, especially on anything other than 386.

Frankly, what you describe you like Microsoft stupidity to me. If you care use a sane(r) OS.

Well, I will certainly not engage in a battle for the "last word". But, I don't want to leave a couple of things unanswered.

The first thing that occurs to me is that this is the "Windows" forum. So, Microsoft's approach is certainly material.
I sampled the files from the VLC project, and it appears that all of the VLC dlls, and all of the Microsoft dlls include the .reloc data. It is only the vlc.exe that has the .reloc stripped, one module. (That is the Mingw default. That used to be the Visual Studio default.) It is quite clear, whatever philosophy differences exist, that the Windows OS embraces ASLR and that the Windows dlls called in by VLC embrace an ASLR approach.

Where I come from, there is a saying "In Rome, do as the Romans do". Well, maybe in Microsoft land, which we are certainly in, in the VLC Windows category, ... "In Microsoft land, do as Microsoft does, especially when it only involves one module, namely vlc.exe".

The ASLR issue relates to the OP's initial issue, which is why, 64 bit versus 32 bit. I would still say, if it is a tie in the user experience, go 64 bit. But, there are things that could enhanced the argument for 64 bit, by adding to the one and only module that doesn't include the .reloc information so that ASLR operates correctly.

From what I hear, ASLR only slows loading. Once loaded, programs should operate at the same speed. Firefox, Palemoon, Chromium, etc seem to work on Windows with ASLR without an issue. PIE is linux, but ASLR is Windows. And it only requires one dummy dll declaration in one module to enable it in VLC under Mingw.

As a matter of fact, you are wrong. Shared libraries have to use either position-independent code, or by default, relocations. Relocations are much worse because they prevent sharing (increased memory consumtpion) and demand paging (worse load times). Without either PIC or relocs, there would be literaly no ways to use shared libraries at all.

This has nothing to do with ASLR, which it predates by at least a decade. Also ASLR is not Windows-specific. It was on Linux before Windows, and it was on OpenBSD before Linux.

And while it is understandable for historical reasons that Windows uses relocations on 386. It makes zero sense on x86-64, except from Microsoft being too lazy and complacent to implement and promote PIC/PIE.

An issue with 64 bit compared to 32 bit is that it doesn't name the snapshots correctly. That's why I have reverted to 32 bit.
vlcsnap-error###.png instead of vlcsnap-timestamp.png
https://forum.videolan.org/viewtopic.php?t=132703
According to this topic, the issue has still not been solved in 2.2.6

64 bit, in my memory, is for EXPERIMENTAL PURPOSES. So i always download 32 bit, still now, also on 64 bit System. Just for security. For real, both versions have perfectly same features, compiled for 32 or 64 bit cpus.