The VideoLAN Forums

it may be some time before 64 bit computing is mainstream, but it would be awsome to have a version of VLC that runs in the 64 bit environment. I am happy that it supports the 32bit emulator on winXP x64, but transcoding could go faster with full x64 support. same with threading.

im sure its on the todo list. but thought i would mention it.

64 bits are mostly marketting gimmick when talking about x64 hardware. Only good thing is that it supports over 4 gigs of memory.
And compiling,
http://cygwin.com/faq/faq.html#faq.what.supported
cygwin doesn't seem to support real 64 bit code for Windows. There might be other limitations also in some video decoders/encoders.

Multi-threading is also enabled and supported by few codecs. And this makes a difference.

once some people decided to make a 64 bit version of mingw (the compiler we use to build the windows versions), we'll be glad to make a 64 bit windows version of VLC. In the meanwhile, we can't since we don't have any compiler to compile VLC with

Just one question: Any information about how to compile VLC with M$-Visual (for 32bit)?

I can try to compile a 64bit version with M$ developer tools with help!

It is very difficult -or impossible- to have a full VLC with MS visual.
The reason for this is that vlc depends on a lot of 3rd party libraries and building them in MSVC is not convenient and sometimes even impossible.

Sorry

You could still give it a try. i don't know if ffmpeg will compile (but it shouldn't be too difficult to make it compile if it doesn't). latest wxWidgets should compile with MS compilers on 64 bit cpus. Other libs i don't have a clue
Info you might need is available on http://developers.videolan.org/vlc/ and in the wiki ( http://wiki.videolan.org ). Feel free to post progress reports here (or in vlc-devel@videolan.org )

64 bits are mostly marketting gimmick when talking about x64 hardware. Only good thing is that it supports over 4 gigs of memory.

x64 has triple the number of registers you can use for general purpose - that makes a big difference for code that can benefit from it. I imagine codecs would fall into that category.


Needless to say, DirectX Hardware access is disabled on Wow64. So having a native 64-bit VLC would be really nice.

Registers are doubled (normal and xmm), but I doubt seeing any real increase by more registers. Also because all x64 can use SSE and SSE2 they will give more boost, but SSE and SSE2 aren't anything new.

Yes, but the effective number of registers is almost tripled. On x86 you always have at least 2-3 registers used for something you cannot touch (stack, frame pointer, etc). Hence the effective number is tripled, while the actual number is doubled.

Errr... just thought I'd like to add my desire for this "feature".

I have seen significant increases in the speed (or rather, decreases in the time taken) using x64 builds of ffmpg and XviD builds on Vista Home Premium x64.

I have to admit, I was supprised to see it, but there it is. Postprocessing (deblocking and deringing) shows up the improvement most... where the 32-bit version offten had to reduce the levels due to CPU time shortage, in x64 full deblock and dering goes on smooth as a babies bottom.

Also HD material, 1280x720x60FPS, never stutters in Vista 64 with ffdshow 64, where in Vista 32 and ffdshow 32 frame drops could be seen... Okay, so my less pedantic friends never noticed, and it's not a *huge* problem to drop 1 in 120 frames at 60FPS but you can see it, and when you notice it, it is annoying. (for me at least)

One other thing I do notice, Media playback is not so good on my DualCore 2.2Ghz processor in 32bit as it was on my 3Ghz single core P4. But in 64bit mode with 64bit OS it is better. Now that is probably not because it's dual core, but rather that the 64bit speed (memory management / registers / whatever) makes up for the fact that video files are largly a sequential affair, and multiple cores (at slower rates) don't actually help very much.

The only suggestion I could give there is... of course, the audio streaming and rendering, video streaming and rendering and any subtitle stream rendering should each be seperate threads in the system. But I imagine that is already done, however, throse threads would have to be controled by another master thread, which handles demuxing.

In any event. I accept that MingW MSYS 64bit support is still very imature... and even getting stable Mozilla builds out of it is fraught with pitfalls. But I felt I should back this petition, unless you guys know that there is demand you wouldn't see the point.

I hope I have made some dent in the theory that performance improvement isn't going to be achieved too. I don't understand why... the x64 builds I have used are beta, and some features have "issues" but those that work, do work faster. I might even suggest, comparing with my old P4, that the improvement is more to do with not having to emulate a 32bit processor when you are actually using a 64bit one. I remember early 8bit emulators on 16bit machines where painfully slow till we we nearly at the 32bit CPU stage. Having the emulator on the CPU can't really make all that much difference. As almost all CPUs sold are 64bit, and most (present version) OS recommend 2-6Gig of RAM, it's a sure fire thing that the trend is there in the industry, wether people want it / need it or not.

As long as I don't have a working MINGW64 environment, let's forget about it.

This (From Mozilla for Windows x64 platform) may help:-

Understanding Win64 developement environment

Since Sun's developer doesn't seem to know Win64 development environment by Bugzilla #227049, I explain it

There is 2 CPU arch for Win64

* IA64 (aka Itanium)
* x64 (aka AMD64, x86_64)

Win64 tools such as complier and assember are included in the following products.

* Platform SDK for Windows Server 2003
* Visual Studio 2005 Standard Edition or highr edition

Visual Studio 2005 Express Edition doesn't have Win64 complier and linker. If you want to get Win64 build environment by non-fee, you have to use Platfrom SDK for Windows Server 2003. Platform SDK has version 14.x of CL.EXE (as same as major version of Visual Studio 2005).

Also, how about Platform SDK for Windows Vista? It is not good chooise. Becasue, it doesn't include assember such as ML64.EXE. Although I don't know why Microsoft decides it has no assember command, we must buy VS2005 STD/PRO if you need latest compiler and assember.

They have some additional x64 based MSYS build tools on their download page.

Latest Mozilla build system uses MSYS. But current stable version of MSYS doesn't work on Vista x64. Since latest Mozilla build system package uses stable version, it doesn't work well.

This issue is a famous issue. Because this is compatibility issue of Vista's WOW6432. To fork thread/process on Cygwin/MSYS, it uses CreateProcess() API and STARTUPINFO parameter. Due to a lack of Vista WOW6432 compatibility, it cannot pass fork information to waiting funtion. So sicne The wait object become invalid, fork always failed.

This issue already fix on latest code (version "1.0.11"). But it isn't released as stabled package. So you have to replace MSYS-1.0.DLL into \mozilla-build\msys\bin with 1.0.11 binaries. MSYS team has released 1.0.11 version DLL as MSYS-1.0.11-20071204.tar.bz2. After installing Mozilla build system, you extract it and have to replace DLLs.

Another point I might make, is that Adobe don't yet make (and have no plans within version 9 to make) a Flash plug-in for any 64bit platform, so watching flash videos on streaming / VOD sites (you know the ones) is presently restricted to the 32bit versions of browsers in windows... and I haven't seen a binary release of GNASH, so I'm guessing you'd have to build that yourself on 64bit Linux. Apple don't produce x64 Quicktime, and RealMedia seems to be a wasted technology strangled by it's own commercialism. 64bit demuxers exist for DirectShow which allow you to view RealMedia in x64 browser without RealPlayer.

A win64 VLC browser plug-in would therefor be quite an awesome step forward and "stick it to the competition".

(Do you like how I work on the ego there? If there is nothing else to be gained, there is always pride.)

I accept that this is still early days, even for the MSYS / MinGW teams. This is a horizon thats approaching but has not quite engulfed us all yet. You can prepare for it by checking dependencies on datatype overflows, (ints and words) stack, and data alignment etc. And I think it is (may be) possible to attempt beta x64 builds... making clear (as Mozilla do) that they are not main stream, and will contain more flaws than the base project, which should always be preferred for general use.

Let me assure you, I'm not pressing for release "Now now now now now". VLC is a fantastic program as is. (points I particularly like include the fact that it transcodes, it's cross platform, and it's defiantly the most versatile media player on Mac OS X) I'm just asking that the prospect be given serious consideration, and be earmarked for revision as things progress.

P.S. I could offer you the hardware / OS as a test environment, but I know nothing about MSYS building. I code in Borland C++ Builder (for preference) and Visual C++... Over the years I've used a number of different C / C++ compilers, but the last time I attempted an MSYS I got very confused over the different packages.

Once more my statement is:

"As soon as we have a mingw64 compiler for windows on linux or on cygwin, I will work on it"

I don't care about MSVC, MSYS or anything else.

Best

Should be done soon

If anyone is interested (or wants to help):
http://mingw-w64.sf.net/

how is this going

"As soon as we have a mingw64 compiler for windows on linux or on cygwin, I will work on it"
I don't care about MSVC, MSYS or anything else.

Hello Jb,

Any news on x64 version? Lots of people are seemingly expecting it. And also it seems that mingw64 compiler is already available, both on linux and windows, both as native and as a cross-compiler - see https://sourceforge.net/project/showfil ... _id=202880. Have you already tried it? any issues with it? what else is blocking a VLC/x64 release? Please elaborate this for us poor impatient users, so that we know what to wait for.

We are working with mingw64 guys, but this is long and complex.

I don't have much time and need to work to get some food... :'(

Hi is there any update or possible way to have this working for XP64? I think also there is a lot of people that would like this to work with XP64 as well.

any news or updates?
rgds

I vote for 64 native build!
32 build working not so good on vista x64-unstable and often crashing
look at
Media Player Classic HomeCinema
it compiled with MinGW GCC 4.4.0 x86_64 and exist in
MPC HomeCinema (x86)
MPC HomeCinema (x64)

32 build working not so good on vista x64-unstable and often crashing

I don't think 32vs64 bit has anything to do with this. Vista 64 has the best Win32 software emulation in Windows universe. And if you find a way to crash VLC that you can easily repeat, please report it.

32 build working not so good on vista x64-unstable and often crashing

I don't think 32vs64 bit has anything to do with this. Vista 64 has the best Win32 software emulation in Windows universe. And if you find a way to crash VLC that you can easily repeat, please report it.

i report it already

From the Changelog:

Port to Android, iOS, OS/2 and Win64.

...but where are the official Win64 builds ?

They will come in the next days.

Great news, thanks in advice !