[HEVC] x265.EXE: mingw builds

[LigH.de]

With a little additional patch to enable function exports from the EXE in GCC builds too (not only MSVC), here are the first "All-In-One" x265.exe v1.7+298 which could also be linked as if they were DLLs (in theory yet, to be tested):

x265 1.7+298-523540864864 AIO (GCC 4.8.2)
x265 1.7+298-523540864864 AIO (GCC 4.9.2)

[LigH.de]

Just a test build due to fixing "full help" and zones...

[LigH.de]

Another "comprehensive" weekly build:

x265 1.7+338-8023786c5247 (GCC 4.8.2)
x265 1.7+338-8023786c5247 (GCC 4.9.2)

[x265.cc]

my buildbot is back (automated GCC 5.2.0 / YASM 1.3.0 builds):


https://encoder.pw/x265/


webfrontend will be back soon too.

As always: don't trust any foreign binaries.

need something more experimental? https://encoder.pw/daala/

[LigH.de]

^ Thank you for your comeback.
__

Eventually, new builds from me, I waited a bit longer, but it was worth it: Main12 now supports some degree of assembler optimization completely (at least up to SSE2-4 and AVX1), and just recently got a new table of "lambda" values (no clue what it means, but it seems to be important for a sane bitrate control).

x265 1.7+371-24c1ee516d13 (GCC 4.8.2)
x265 1.7+371-24c1ee516d13 (GCC 4.9.2)

And some results to compare:

8 bit | 10 bit | 12 bit (each ~6..7 MB, only default parameters except bit depth)

The video source is a 720p Y4M with 12 bit color depth, rendered with VapourSynth out of a sequence of 1440 TIFFs in RGB48, originally in 4K UHD resolution, scaled down in 16 bit-per-component YUV 4:4:4 before reducing to 12 bit-per-component YUV 4:2:0.

[LigH.de]

New builds with MinGW-w64 patch for multi-threaded stats file output:

x265 1.7+382-7c83f7755422 (GCC 4.9.2)
x265 1.7+382-7c83f7755422 (GCC 5.2.0)

[LigH.de]

GCC 5.2.0 appears to produce considerably faster executables than GCC 4.9.2 for legacy CPUs.

Here some brief statistics on an AMD Phenom-II X4 (max. used SIMD: SSE2) based on quick benchmarks (best of 3) with foreman.y4m in PAL CIF:


GCC 4.9.2: slow = 4.97 fps; slower = 1.64 fps; veryslow = 0.99 fps; placebo = 0.52 fps

GCC 5.2.0: slow = 5.45 fps; slower = 1.74 fps; veryslow = 1.07 fps; placebo = 0.55 fps

[Detmek]

Its a smaller difference on Pentium G3220 (no AVX/AVX2 instructions), 720p video, preset fast, x265_1.7.382:

GCC 5.2.0 - 12,4325 fps (average of 4 runs)

GCC 4.9.2 - 12,3975 fps (average of 4 runs)

I also did test with build 1.7.374, same video and settings:

GCC 5.2.0 - 12,315 fps (average of 4 runs)

ICC - 12,06 fps (average of 4 runs)

MSVC - 12,3075 fps (average of 4 runs).

For some reason Intel's compiler produces the slowest build for my Intel CPU?! And just for the record, last month I benchmarked Cyberfox x64 (web browser), AMD and Intel optimized builds and AMD build compiled with MSVC compiler was faster compared to Intel optimized build (ICC compiler, I think).

It seams that Intel does not like its budget CPUs. :P

[LigH.de]

The more time x265 spends in assembler optimized routines, the less obvious the differences between C compilers get. Your differences will have been smaller mostly because of the 720p dimensions, I bet.

Comparing substantially different compilers is a different issue, though. Quite probable that the ICC requires a minimum architecture to crow (e.g. assuming bigger cache sizes than physically available may make some optimizations counterproductive).

[x265.cc]

My webfrontend is back..

https://encoder.pw/ Automatic MinGW (patched, GCC 5.2 / Yasm 1.3) builds.

afaik it should offer the most up2date binaries atm.

[El Heggunte]

My webfrontend is back..

https://encoder.pw/ Automatic MinGW (patched, GCC 5.2 / Yasm 1.3) builds.

afaik it should offer the most up2date binaries atm.

Welcome back, and many thanks.

Post #1 has been updated with the link to your buildbot

[alkoon]

New builds with MinGW-w64 patch for multi-threaded stats file output:

x265 1.7+382-7c83f7755422 (GCC 4.9.2)
x265 1.7+382-7c83f7755422 (GCC 5.2.0)

Hi!

I tried this software for wind 64bit, but it's not run?! it's like unknow files!

[LigH.de]

http://www.7-zip.org
http://sourceforge.net/projects/sevenzip

[Macadamia]

My webfrontend is back..

https://encoder.pw/ Automatic MinGW (patched, GCC 5.2 / Yasm 1.3) builds.

afaik it should offer the most up2date binaries atm.

Any hope of having it include the 10 bit version ?

Many thanks !

[LigH.de]

It may be more elaborate, but you may want to build the multilib executables to combine 8 + 10 + 12 bit encoder routines into one EXE. Don't forget to strip, that saves a few MB. And 7-zip will compress such large 3-in-1 files a lot more efficiently than ZIP with its small LZ window (only 32 or 64 KB, I believe).

[alkoon]

I already have 7.zip


check this link : http://im85.gulfup.com/f6seFJ.png

as I said I can't run and it's like unknow software!

and I have another question, How did you use H265 to encode MP4 format, did you used MKVTool to convert .HEVC to MP4 ?

[LigH.de]

These are not my builds. I never distributed a file "x265[gcc]_1.7+374_64-8bit.zip", neither an "x265_64-8.exe"; blame those who made them... Furthermore, if there is any error message, please quote it as exactly as possible. Help us to help you, tell us facts, don't let us guess and assume.

MP4 files are multiplexed using MP4Box.

[alkoon]

These are not my builds. I never distributed a file "x265[gcc]_1.7+374_64-8bit.zip", neither an "x265_64-8.exe"; blame those who made them... Furthermore, if there is any error message, please quote it as exactly as possible. Help us to help you, tell us facts, don't let us guess and assume.

MP4 files are multiplexed using MP4Box.

Yeah I know it's not yours builds. I give an example, this is a same thing that I got when I tried to use your bulids, unknow softwar and I can't run!

thank you very much.

[Macadamia]

check this link : http://im85.gulfup.com/f6seFJ.png

as I said I can't run and it's like unknow software!

What do you mean unknowned software?
It's a command-line driven program with no interface, you need a GUI (i use Hybrid with latest builds but there are plenty of others described in the software section).
You could also use a command prompt, but you'd really need to be familiar with the encoder's options and requirements.

[x265.cc]

These are not my builds. I never distributed a file "x265[gcc]_1.7+374_64-8bit.zip", neither an "x265_64-8.exe"; blame those who made them... Furthermore, if there is any error message, please quote it as exactly as possible. Help us to help you, tell us facts, don't let us guess and assume.

MP4 files are multiplexed using MP4Box.

Yeah I know it's not yours builds. I give an example, this is a same thing that I got when I tried to use your bulids, unknow softwar and I can't run!

thank you very much.

a) tell us what and how you tried to use the pe file (.exe)
b) make a screenshot of the error message and post it.
c) your current screenshots nor your description is useful to nelp

btw. i think his builds are from x265.ru

[LigH.de]

Due to a merge to prepare the coming v1.8 milestone:

x265 1.7+399-cbdefdfca877 (GCC 4.9.2)
x265 1.7+399-cbdefdfca877 (GCC 5.2.0)

[alkoon]

Everything is ok now, thank everyone

Regards.

[LigH.de]

Another "merge with stable":

x265 1.7+424-996ebce8c874 (GCC 4.9.2)
x265 1.7+424-996ebce8c874 (GCC 5.2.0)

[-Habanero-]

Is there a version history/changelog of x265 anywhere sorted by revision number? There is one of x264 since the very beginning.

[LigH.de]

https://bitbucket.org/multicoreware/x265/commits/all

Also available inside the Hg Workbench of TortoiseHG (Mercurial as context menu extension for the Windows Explorer).

[-Habanero-]

That doesn't display the version numbers.

I meant something like x265 1.7.420 421 422 423 etc. like the x264 changelog http://x264.nl/x264/changelog.txt

[LigH.de]

Calculating the version+patch format is a bit elaborate if you don't use hg to manage the version dependencies; there are milestone builds from which each commit increases the patch number. I don't know any other site which keeps track of "patch number related to hash".

[LigH.de]

Weekly build, "merge with stable".

x265 1.7+433-60f30d2ead26 (GCC 4.9.2)
x265 1.7+433-60f30d2ead26 (GCC 5.2.0)

[LigH.de]

Another "merge with stable", including several bug fixes and some even faster AVX2 routines.

x265 1.7+470-86e9bd7dd192 (GCC 4.9.2)
x265 1.7+470-86e9bd7dd192 (GCC 5.2.0)

[poisondeathray]

Another "merge with stable", including several bug fixes and some even faster AVX2 routines.

Thanks, any quantification/benchmarks/more info on "faster" AVX2 routines ?