x265 for WinXP / XP x64 / Vista

H.265/HEVC logo

1.) Introduction

This page is a collection of my x265 releases for Windows XP/Vista 32-bit and Windows XP x64 Edition / Vista x64 as well as all newer releases of Microsoft Windows. The key feature here being the XP and Vista compatibility, which is not the default for compiling x265 on Windows. For each revision I decide to build you’ll get the 32-bit as well as the 64-bit versions.

The newer 64-bit versions are multilib builds which give you the ability to encode to 8-, 10-, and 12-bit per channel color depths by specifying the color bits with the -D option. That’s no longer supported for the 32-bit versions, so those can encode to 8-bit color depth only. The two oldest builds also come as individual binaries for each color depth.

Some of the older releases will contain headers and static libraries as well, some only have the binaries, and some newer ones up to 1.9+200 will have only the x265.exe and libx265.dll files.

Regarding licensing, see section [3], for usage section [4], for information about how to compile yourself see section [5] and to learn about limitations of this build, see section [6].

Since x265 doesn’t link against either libav or ffmpeg, it’s unusable for most typical transcoding scenarios, as it can only read raw YUV input, which is why you’ll be provided with both a 32- and 64-bit version of the avconv command line decoder compiled for XP/XP x64 as well. With it, you can decode pretty much any source video stream and pipe it into x265 directly, creating a complete H.265/HEVC video transcoding toolchain.

2.) Downloads

And here are the files, newest to oldest:

2.a.) x265 video encoder:

  1. x86_32 / 32-bit:
  2. x86_64 / 64-bit:

*[1]: These versions had to be patched to fix an ambiguous pow() function call by using explicit (double) typecasting in source\encoder\slicetype.cpp for one parameter of this overloaded function. Without it, the code will not compile in MS VS2010. The modification is to be found on line 1776 for version 2.2+22-20217c8af8ac, see the following code snippet:

expand/collapse source code
if ((lists_used >> list) & 1)
  MV *mvs = frames[b]->;lowresMvs[list][listDist[list]];
  int32_t x = mvs[cuIndex].x;
  int32_t y = mvs[cuIndex].y;
  displacement += sqrt((pow((double)abs(x), 2) + pow((double)abs(y), 2)));
} else


Please note that I can’t exactly vouch for this being the correct solution, as I can’t be 100% sure which floating point data type to use (float, double and long double would be possible [according to Microsoft]), so I just took my chances by casting double. It seems to work properly and the resulting output files look fine in my tests, so I’ll leave it at that.

*[2]: Starting with version 2.4, x265 optionally supports HDR10+ as per SMPTE 2094-40 based on code contributed by Samsung. This adds support for the ITU-R BT.2020 wide-gamut color space and the HDR10 profile. However, these parts require the compiler to satisfy parts of the C++11 standard, which Microsoft Visual Studio 2010 cannot. Since I decided to release x265 for Windows XP, XP x64 & Vista including its brand-new support for HDR10+, I had to switch to a Windows 7 build machine using the newest Visual Studio version supported by the x265 build tools, which is Visual Studio 2013.

So from now on, builds will be compiled using MSVC 18.00.21005.1 with a v120_xp platform toolset on Windows 7. Builds are first checked with [CFF Explorer] to verify the correct platform target and then tested on XP x64. The additional check is just to make sure I’m not accidentally compiling the 32-bit version for NT5.2, given 32-bit XP has an NT5.1 kernel.

Versions built like that require a later version of the Visual C++ redistributable, a link has been added below! The hack described under *[1] is no longer needed since Visual Studio 2013 can handle that part without workarounds.

*[3]: Starting with version 2.4+28, I have modified some of the build scripts to be able to compile the software with the latest Microsoft Visual Studio 2017, moving the build system from XP x64 to Windows 7 x64. The platform toolset and target has thus changed from v120_xp to v141_xp and the compiler version from 18.00.21005.1 to 19.10.25019.0. Links to the required Visual C++ 2017 redistributable have been added below.

2.b.) avconv video decoder (includes some CygWin libraries, necessary for video input other than raw YUV/Y4M):

  1. x86_32 / 32-bit:
    • [avconv 11.7(GCC 4.3.4 + yasm 1.3.0, x86_32 / 32-bit)
  2. x86_64 / 64-bit:
    • [avconv 12.0(2016-11-28, GCC 4.9.2 + yasm 1.3.0, x86_64 / 64-bit)
    • [avconv 11.7] (GCC 4.9.2 + yasm 1.3.0, x86_64 / 64-bit)

2.c.) Microsoft Visual C++ 2010 runtime (external links, required to run x265):

  1. [Visual C++ 2010 runtime] (x86_32 / 32-bit)
  2. [Visual C++ 2010 runtime] (x86_64 / 64-bit)
  3. [Visual C++ 2013 runtime] (required starting with version 2.4+2 due to updated build environment)
  4. Visual C++ 2017 runtimes (required starting with version 2.4+28 due to updated build environment)

All x265 releases on this page have been compiled/assembled with Microsoft Visual Studio 2010 SP1 plus yasm 1.3.0 on Windows XP Professional x64 Edition SP2. The supplementary avconv release has been compiled with GCC 4.3.4 for 32-bit as well as GCC 4.9.3 for 64-bit versions plus yasm 1.3.0 using CygWin on the same host operating system.

*[4]: Some 64-bit releases before this one might be lacking proper HDR10+ support due to a misconfiguration of the build scripts. I do not care for checking all of them individually, so if you need an older x86_64 release with HDR10+ enabled, let me know in the comments. Otherwise, please just use 2.5+9-fdf39a97ecb8 or newer!

*[5]: MSVC 2017 compiler version updated from 19.10.25019.0 to 19.11.25547.0.

All releases have been sent through a simple testing system which transcodes a sample video for 8-bit per channel color depth using the 32-bit binary and to 10- & 12-bit color depths per channel using the 64-bit binary on Windows XP Professional x64 Edition SP2. Sometimes, tests are also being done on Windows 10 Pro x64 and Windows XP 32-bit to check whether everything is truly still “in order”. The resulting videos are evaluated manually by myself, usually on CentOS 6.7 Linux using mplayer.

Previously, releases have been done via individual weblog posts. If you want to read them, here are the links, from newest to oldest:

  1. [x265 1.9+200 build for Windows XP/XP x64+]
  2. [Another new x265 WinXP build, v1.9+141]
  3. [A new x265 build for XP / XP x64 (also: How to build a multilib binary)]
  4. [An x265 build for Windows XP / XP x64]

3.) Licensing

All components of those releases are free software with varying degrees of freedom. Optional non-free components have been excluded from them to ensure legal redistributability.

  1. x265 itself is licensed under the [GNU General Public License version 2]. The source code can be obtained from [here]. x265 is being developed by [Multicoreware Inc].
  2. avconv from the [libav] project is cross-licensed under the [GNU Lesser General Public License version 3] as well as the [GNU General public license version 3]. The source code can be obtained from [here].
  3. [CygWin] libraries (“DLLs”) bundled with avconv are licensed under the [GNU General Public License version 3]. The source code can be obtained from [here].

4.) Usage

Example 1: Transcoding an MKV file to H.265/HEVC, excluding audio and subtitle inputs. For this example, we’re using the 64-bit versions of avconv.exe and x265.exe in our search path, transcoding to 10-bit color per channel. The resulting file is a Main10 H.265/HEVC elementary stream which can then be multiplexed e.g. into another MKV file. Settings are relatively simple:

avconv -r 24000/1001 -i video-input.mkv -f yuv4mpegpipe -pix_fmt yuv420p -an -sn^
 - 2>NUL | x265 - --wpp --y4m -D 10 -p slower --bframes 16 --crf 18 --sar 1^
 --range full -o video-output.h265

Example 2: Transcoding an elementary H.264/AVC video stream to H.265/HEVC. Here it would be 32-bit versions, option -D is omitted, because the only color depth supported by x265 on 32-bit is 8-bit anyway:

avconv -r 24000/1001 -i video-input.h264 -f yuv4mpegpipe -pix_fmt yuv420p - 2>NUL |^
 x265 - --wpp --y4m -p slower --bframes 16 --crf 18 --sar 1 --range full^
 -o video-output.h265

If you need to know more about available options of x265 or avconv, refer to their help by running x265 --log-level full --help 1>x265-fullhelp.txt 2>&1 and/or avconv --help full 1>avconv-fullhelp.txt 2>&1 and reading the resulting text files.

5.) How to compile yourself

This has been explained in two of the four blog posts linked to in section 2, here they are again:

  1. [A new x265 build for XP / XP x64 (also: How to build a multilib binary)]
  2. [An x265 build for Windows XP / XP x64]

You may wish to read the second (=older) one first. This will describe how to get your own build system on Windows XP in enough detail. Please note that you may need to change your settings regarding the platform SDK to be used if you wish to build XP compliant binaries on newer operating systems with newer versions of Microsoft visual studio, [as mentioned by Azarien].

6.) Limitations

6.a.) General performance

Some users may find the XP/Vista-compatible build to run a bit slower than the modern one even on identical hardware, and even when run on the same (modern, in that case) operating system, especially on systems with low core counts. This is expected however, see the [documentation] (p. 41).

6.b.) Multiprocessor & -socket limitations

Update: One additional implication of what can be read below is that the total number of logical CPUs supported by my XP, XP x64 & Vista releases for x265 is 64. Since CPUs are addressed using a 64-bit bit vector, this is a hard limit that cannot be circumvented. Also, since x265 doesn’t support Vistas’ limited NUMA implementation, you need to use a modern x265 build as well as Windows 7 or newer if you wish to use more than 64 CPUs! For Windows to address more CPUs, NUMA is absolutely required (so multiple NUMA thread pools / processor groups can be created, of which each single one is again limited to 64 CPUs). Please keep this detail in mind as well.

So, x265 does not support the older NUMA functionality present in the Kernel32 API on Windows Vista, Windows Server 2003 and Windows XP x64 Edition (regular Windows XP doesn’t have support for it at all), hence NUMA awareness had to be disabled to ensure compatibility to those older operating systems. NUMA – Non-uniform memory architectures – exist since memory controllers went from the chipsets into the CPUs (AMD Athlon64 / Opteron, Intel Core i7). Because of that, each CPU has a local memory pool that is connected to other CPUs via high speed links like Intel QPI or AMD HyperTransport. See the following picture to understand it a little better:

NUMA architecture

A 2-socket NUMA system. Blue = CPU core, violet = memory controller, green = memory, red = system bus. Each blue+violet+green block represents one CPU. Source: [Wikipedia]. Image is © Moop2000.

Despite todays’ high speed bus systems, accessing its local memory is still faster for a CPU than traversing the system bus would be. Because of that, certain “NUMA aware” applications can group threads together with their memory pools on each NUMA node (typically a CPU/CPU socket with adjacent memory DIMM slots and modules) to minimize cross-bus memory accesses.

Non-NUMA-aware, multithreaded applications like this x265 build will still scale up on multisocket NUMA systems, but not optimally. Thus, if you are running an older version of Windows on such a system and that’s why you’re using this x265 build, please be aware that it might be slightly slower than on Windows 7 / Windows Server 2012 and higher or on Linux / UNIX with libnuma and a regular x265 build.

According to my tests, you won’t have to expect a big impact, but you should still be aware of that.

Single socket/CPU systems are unaffected by this. Multi socket systems using UMA (like those based on Intels Front Side Bus) are also unaffected.

6.c.) No deep color support with 32-bit x265

32-bit (x86_32) versions of x265 do no longer support deep color modes, so no 10 bits or 12 bits per color channel and no internal high precision 16-bit arithmetic on regular MS Windows XP or any other 32-bit version of Windows. This is not a limitation imposed by my builds, but a limitation of x265 itself. The 32-bit builds can only use regular 8-bit arithmetic and 8 bits per color channel. This can be circumvented by hacking up the source code, but I will not do that. Also, the remaining code in the 32-bit branch is known to be highly unoptimized because of missing assembly code.

So if you need/want deep color and higher precision arithmetic, you need a 64-bit system. The oldest versions of Windows to make this possible are Windows XP Professional x64 Edition and Windows Server 2003 x64.

CC BY-NC-SA 4.0 x265 for WinXP / XP x64 / Vista by The GAT at XIN.at is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.