How to download x265?

[knightplex]

Today VideoHelp posted a new website to download x265 - http://msystem.waw.pl/x265/

I can't figure out which one should I download. The latest stable version comes in 8 different versions.

[pandy]

Depends on your CPU capabilities and compiler preferences (VCC is Microsoft C compiler, GCC is GNU C compiler, one of most popular but not listed on site is ICC - Intel C compiler and ICC usually provide especially for Intel CPU's best speed), GCC seem to be most safe and slowest choice (this may be true when GCC compared to ICC, it may be not true when compared to VCC).
Check instructions supported by your CPU - (use CPU-Z for example) - if AVX or AVX2 supported then go for it. VCC2017 may require Windows 10 (not sure, i don't care about stupid and artificial MS limitations).

http://www.cpuid.com/softwares/cpu-z.html

[KarMa]

deleted

[LigH.de]

The differences between binaries build for different minimum architectures and with different C compilers should be relatively small, because most core routines in the encoder are optimized in assembler. Even a binary without a special optimization for the rest of the C routines still contains AVX optimized code for the encoder core, for the case that your CPU supports AVX instructions. And it better does.

Check instructions supported by your CPU - (use CPU-Z for example)

Yes. Know your limits (or those of your PC).

An alternative to CPU-Z would be HWiNFO.

[knightplex]

So the best version is VS 2017 AVX2? Yes my system supports AVX2. Usually I download the latest nightly build version 64bit from here https://builds.x265.eu/

While encoding it shows AVX2 in cpu capabilities.

So I guess my laptop already supports everything latest. So the best version is VS 2017 AVX2?

And ICC builds are given here - http://x265.ru/en/builds/

So If my cpu supports everything, which one should I download?

[LigH.de]

There is no "best version for everyone".

Whether the "VS 2017 AVX2" build is the "best version for you" ... try it, compare against the others, and report your results to us.

[knightplex]

Okay. Which one is the builds available in the nightly versions? https://builds.x265.eu/
Is it VS 2017 AVX2?

[LigH.de]

It is a MinGW build, so it will probably use one of the GCC versions.

>x265-64bit-8bit-latest.exe -V
x265 [info]: HEVC encoder version 2.2+23-58dddcf01b7d
x265 [info]: build info [Windows][GCC 5.3.1][64 bit] 8bit

Oh, GCC 5.3.1 ... that's rather old. GCC 6.2 or 6.3 are common now. And it is certainly not optimized to require AVX to even start.

[pandy]

If your CPU is Intel then i would always recommend ICC builds - Intel compiler usually provide fastest binary...

[LigH.de]

And how much faster is an ICC build, compared to e.g. a generic GCC 6.2.0 build ... when the encoder core is in assembler? The larger the frames, the less you will notice the difference in the remaining C code.

[pandy]

And how much faster is an ICC build, compared to e.g. a generic GCC 6.2.0 build ... when the encoder core is in assembler? The larger the frames, the less you will notice the difference in the remaining C code.

Even small fractions multiplied by millions count...
https://forum.doom9.org/showthread.php?t=173404
https://forum.doom9.org/showthread.php?t=168814&page=135
High bitdepths are more sensitive as usually asm is not implemented same quality as 8 bit.

Don't get me wrong - from my perspective choice is quite simple and i will prefer fastest available binary even if this improve overall speed marginally - simply less energy wasted.

[LigH.de]

Regarding the old but verbose test: The available CPU architecture is obviously an important factor. If I have only an outdated CPU (pre-AVX era), a VS2015 build is possibly over-optimized and thus slower than GCC by 15-25%, that's certainly noticeable. On the other hand, on a well supported architecture, different builds only spread by less than 1%.

So I keep recommending to knightplex: Download several builds, test them on your machine with the same command line parameters and the same video material, and tell us how different your results are. Practical experience is the best advice here.

[sophisticles]

I don't understand this discussion at all, which one is the official build? I would think the gcc one since x265 is open source and runs on 'nix as well as Windows.

Regarding compiler optimizations, since x265, and most encoders, use hand optimized assembler, especially with regard to SIMD, the proper way to compile them with is the generic flags and here's why:

Compilers take the code and translate it into something the cpu understands and can execute. All modern compilers are so-called "optimizing" compilers that are capable of taking generic code and rearranging it to take advantage of a specific cpu family's architecture for presumably faster execution.

But with hand optimized assembler, the developer of that program has already done the optimizing, by hand. If you were to try and compile a hand optimized program with aggressive optimization flags one of three things would happen:

1) Maybe the people that coded the compiler were incredibly smart and were able to create a compiler that could, with any given program, extract even more optimization out of it. I highly doubt that.

2) The compiler would analyze the code and conclude that no changes where made and do a straight forward conversion to binary. I doubt that as well.

3) The compiler would analyze the code, see that it's structured differently that what it's algorithms would do and proceed to rearrange it to what it thinks it should look like. I think this is the most likely scenario, it's impossible to write a compiler that can take any code input and optimize it more than a skilled developer working on just his code can optimize said code.

If the OP is adventurous he can download the latest x265 git, and compile it with gcc a number of different times, each time using more and more aggressive flags and then test the resulting binaries. My guess is that the one with generic flags will be the fastest.

[LigH.de]

"Official" is only the source code. Many people are able to build it to executables, using different building environments and different possible additional options.

A large part of the x265 (especially these basic routines which are called most often during an encoding job) is already optimized in assembler routines for different instruction set extensions. No C compiler will try to optimize these assembler source parts further. C compilers can only try to optimize the compilation of the rest of the source which is still available as C sources, but they are mostly "higher level" routines which are not executed very often. I doubt you will notice any speedup when a C compiler optimizes the command line interpretation for SSE# instructions...

[pandy]

Not all parts are converted manually to assembler... for example some parts of high bit depth are still in high level - i agree not many people encode 12 bit but once again - if you have speed gain for free why select slower binary?

[LigH.de]

So test all available binaries and discover for yourself which is the fastest on your PC and for your main usage. Other people can only tell you guidelines which builds may probably be quite fast for your CPU class, but certainty comes only from your own experience.

[Jamaika]

With the current situation in the world, it is difficult to say whether the programs posted from the Russian side are without viruses.
Old topic but there's a lot of lying in the page header about C++ in gcc.

x265 binaries for Windows (VS 2015/VS 2019/GCC 11.2)

Amateur downloads and it turns out that gcc is native linux. And what now when libraries under widows <thread> and <mutex> for the latest video codec processors don't work.
In order for gcc to be native windows, you must compile all gcc yourself. Adding the _GLIBCXX_HAS_GTHREADS function to the config won't help. The entire GCC needs to be processed. If you can't do it, you have a problem and you certainly won't be able to create the latest codecs in C++17 and above.