[HEVC] x265.EXE: mingw builds

[LigH.de]

Me too; nothing special, as usual a simple GCC 4.8.2 build: x265 1.4+5-eebb372eec89

[El Heggunte]

Yes, my releases do not include the "High Bit-Depth" builds, BUT

fortunately LigH is not as lazy as I am

[LigH.de]

I am lazy, I let shell scripts do the job...

[vhelp]

dumb question.. does the x265 encoder include the build version ? i am hex'ing around now in it but don't see it.

you see, i d/l'ed one of the builds from here http://builds.x265.eu/

this build "32Bit-8bit-(8720b56443777057167753081f2daa79)"

but it does not work in xp home 32bit. that site does not mention the build versions for any of them unless its hidden in the above string. since i can't run the .exe to find out, hexing it might be a way. thank you.

[Selur]

The above string is probably some hash from a git checkout.
normally "x265 --version" should output something like:

x265 [info]: HEVC encoder version 1.4+31-f2130a4dc876
x265 [info]: build info [Windows][GCC 4.9.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZ CNT BMI2

assuming it's compiled properly.
-> my guess is that the hash shown there doesn't match the hash of the normal git repository, so if you want a mapping to the normal git hashes best ask the one who set up that site.

[El Heggunte]

dumb question.. does the x265 encoder include the build version ?

Yes, it does.

[El Heggunte]

edit Edit EDIT

[El Heggunte]

build 1.4+58-98fb658f3229

[Gravitator]

How much will give AVX2 acceleration?

[LigH.de]

I am curious about that as well, although I only have CPUs without AVX2 support available. But comparing the speed reports of other people with the experiences from the AMD Phenom-II X4 or X6 I could use, it will probably be a remarkable speedup.

Someone with a CPU supporting AVX2 could compare using the --asm parameter; a Phenom-II would be simulated as:

--asm MMX2,SSE,SSE2

The string for an FX class CPU would be lengthy, so maybe someone can give the integer equivalent for "anything less powerful than AVX2".
__

And now for something completely different... but probably interesting for cross-platform developers using CMake in general:

I just renewed my building environment and got some warning from CMake v3.1.0-rc1. Note: CMake is going to disallow uncommon characters in identifiers.

This belongs to a detection in source/cmake/FindVLD.cmake which searches several locations for the installation of the "Visual Leak Detector". It also uses the environment variable in a 64-bit Windows which points at the common installation path of 32-bit applications: %ProgramFiles(x86)%

If such a string is included in a double-quoted string in a CMake script, it may be used as literal, but not as identifier; unfortunately, the function $ENV{} which evaluates its parameter as environment variable uses this rather as identifier than as literal, and you can neither escape the parentheses nor "in-string-quote" it.

The current solution is to create CMake script variables with the name of the environment variable as literals, and nest evaluation functions.

I provided a snippet which should become available as patch soon. In the meantime, CMake up to v3.0.2 won't complain (but possibly not find a VLD installation by searching the x86 path).

[easyfab]

I try at office with a AVX2 cpu. It don't give over 10% vs SSE4.2 . The big boost is SSE2 vs SSE4.2

--asm SSE2 : 3.5 fps
--asm SSE4.2 : 8.1 fps
--asm AVX : 8.5 fps
native ( AVX2) : 8.8 fps

[El Heggunte]

@LigH, and regarding the issue of the latest Cmake with the (IMHO useless) VLD.......

I always remove the references to VLD in the main "CMakeLists.txt".

Why Steve Borho insists on the VLD thing is beyond me.

VLD was not used at all in the detection of that serious memory leak,
reported in the beginning of this thread:

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2261633&v...=1#post2261633

As I suggested before, ONLY the x265 developers themselves should use VLD

[El Heggunte]

build 1.4+69-ed2ba7a90567

[LigH.de]

Another "weekly" build: x265 1.4+70-27d36c4b4a27; probably interesting: tuned VBV predictor factors.

[Brazil]

Thanks a lot to both of you, and keep it up!

[LigH.de]

Thanks, I'll try.

Probably important to know: To get the complete help output, you have to use the following combination now:

--log-level full --help

[El Heggunte]

FWIW... build 1.4+116-3c6f703f94ea

[Brazil]

Probably important to know: To get the complete help output, you have to use the following combination now:

--log-level full --help

Yep, why keeping things simple when you can make them complicated
Not to mention almost all other programs are using the standard -h and/or --help, so this change looks like a clever and useful move.

Anyway, thanks for the tip

[LigH.de]

Well, there are indeed other tools with several levels of help output, even specific parameters (--longhelp, --fullhelp); in brief: "design decision".
__

x265 1.4+116-3c6f703f94ea too.

[LigH.de]

Weekly: x265 1.4+151-5ee693e4b5fa

Has a new "cbr" tuning.

[El Heggunte]

{deleted}

[El Heggunte]

build 1.4+174-35d086074bb5

CHANGES SINCE COMMIT 511dde5:

nandaku2 ec06f58 noiseReduction: allow separate strengths to be specified for intra and inter CUs

nandaku2 1d2a11f analysis: add chroma distortion to rdLevels 3 and 4

Steve Borho cc327e8 analysis: cache m_bChromaSa8d and reduce redundant work

????? 23e6370 asm: chroma_vpp[4x4] for colorspace i420 in avx2: improve 228c->184c

Steve Borho c9fd35f cmake: disable idiotic uninitialized local variable warnings from VC

????? 42df5c8 fix chroma distortion for 4:2:2

nandaku2 4ae9691 analysis: comments

Aarthi Thirumalai a1e7646 rc: fix chroma qp and chroma lambda derivations

Aarthi Thirumalai 1458ad3 rc : fix bug in deciding qp for first frame in CRF

Steve Borho 35d0860 cmake: do not use a cache string for version found in hg_archive.txt (refs #84)

[LigH.de]

Same from me.

[Marchand]

x265 Builds for Windows Cross Compiled with MinGW by snowfag

x265_1.4+179 - Built 2014-12-09:

x265-64bit-8bit-2014-12-09.exe
x265-32bit-8bit-2014-12-09.exe
x265-64bit-10bit-2014-12-09.exe
x265-32bit-10bit-2014-12-09.exe

[El Heggunte]

x265-1.4.179-highbitdepth-icl14.0-64.7z
x265-1.4.179-highbitdepth-msvc2012-64.7z
x265-1.4.179-icl14.0-64.7z
x265-1.4.179-msvc2012-64.7z

Great, 4 non-existent URLs Seriously, man, you need some tons of

[Marchand]

Great, 4 non-existent URLs Seriously, man, you need some tons of

OPS...HEHEHEHE..I fixed

[El Heggunte]

^ F.Y.I., this topic is named «x265.exe: MinGW builds»

FWIW, post #1 already contain links to non-GCC builds

P.S.:

<Portuguese>

Que tal você arranjar uma coisa mais útil pra fazer?
Tipo, bolar um jeito infalível de mandar as ratazanas petralhas pra cadeia,
ou melhor ainda, para um cemitério ou para um fôrno crematório.

http://veja.abril.com.br/multimidia/videos-todos/?rotulos_controlados_agrupados=TVEJA%3A%3A

</Portuguese>

[gonca]

^ F.Y.I., this topic is named «x265.exe: MinGW builds»

FWIW, post #1 already contain links to non-GCC builds

P.S.:

<Portuguese>

Que tal você arranjar uma coisa mais útil pra fazer?
Tipo, bolar um jeito infalível de mandar as ratazanas petralhas pra cadeia,
ou melhor ainda, para um cemitério ou para um fôrno crematório.

http://veja.abril.com.br/multimidia/videos-todos/?rotulos_controlados_agrupados=TVEJA%3A%3A

</Portuguese>

Well said

[Marchand]

El Heggunte

Do not be surly. It was a small error build...



x265 Builds for Windows Cross Compiled with MinGW by snowfag

x265_1.4+179 - Built 2014-12-09:

x265-64bit-8bit-2014-12-09.exe
x265-32bit-8bit-2014-12-09.exe
x265-64bit-10bit-2014-12-09.exe
x265-32bit-10bit-2014-12-09.exe

x265 Builds for Windows Cross Compiled with MinGW by snowfag

x265_1.4+189 - Built 2014-12-10:

[Marchand]

x265 Builds for Windows Cross Compiled with MinGW by snowfag

x265_1.4+199.667 - Built 2014-12-11: