x265 HEVC Encoder

[jpsdr]

For now, i've been able in my mcf version, to "re-install" cmake, after compare the dependencies with the list of installed packages in mcf version, and after a dozen of missing dll and a dozen of more packages, to have the whole list of things to install... And build success with mcf.

[StvG]

Originally Posted by jpsdr

I have several mingw64 directories in my msys directory for switching gcc versions. By default, my mingw64 directory is the one provided by gcc. I have two others: mingw64_win32 (the www.msystem.waw.pl/x265 version) and another mingw64_mcf, le LH Mouse version. To switch, i just rename, for exemple: "mingw64 -> mingw64_posix" and "mingw64_win32 -> mingw64", and then, i start the "MSYS2 MinGW 64-bit" icon of MSYS2 and check with a "gcc -v". This works perfectly fine for doing my several x264 builds.
And when there is a new release of the Win32/MCF version, i delete the mingw64_xx directory and extract/replace by the new version.
So, i just tried to do the same thing for x265, and... It didn't work, the script told me "cmake: command unknow"...
It seems that the mcf, and "worse", the one provided by www.msystem.waw.pl/x265 don't have cmake.
I didn't try yet to "re-install" cmake on the renamed directory, is it the only way ?

You can download cmake. Then you can use the absolute path. For example /d/cmake/bin/cmake.exe -G Ninja ... Or you can add it PATH.

[jpsdr]

Thanks.

Any idea why this works:

mkdir -p 10bit

cd 10bit
cmake -G "MSYS Makefiles" ../../../source -DENABLE_SHARED=OFF -DHIGH_BIT_DEPTH=ON -DENABLE_CLI=ON -DSTATIC_LINK_CRT=ON -DCMAKE_CXX_FLAGS_RELEASE="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}

and this doesn't:

mkdir -p 8bit_x64 10bit_x64 12bit_x64

cd 12bit_x64
cmake -G "MSYS Makefiles" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON -DCMAKE_CXX_FLAGS_RELEASE="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}
cp libx265.a ../8bit_x64/libx265_main12.a

cd ../10bit_x64
cmake -G "MSYS Makefiles" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DCMAKE_CXX_FLAGS_RELEASE="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}
cp libx265.a ../8bit_x64/libx265_main10.a

cd ../8bit_x64
cmake -G "MSYS Makefiles" ../../../source -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DENABLE_CLI=ON -DENABLE_SHARED=OFF -DLINKED_10BIT=ON -DLINKED_12BIT=ON -DSTATIC_LINK_CRT=ON -DCMAKE_CXX_FLAGS_RELEASE="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}

# rename the 8bit library, then combine all three into libx265.a using GNU ar
mv libx265.a libx265_main.a

ar -M <<EOF
CREATE libx265.a
ADDLIB libx265_main.a
ADDLIB libx265_main10.a
ADDLIB libx265_main12.a
SAVE
END
EOF

With LH Mouse mcf gcc version, the multilib version is asking for libmcfgthread-1.dll but the just 10bit is not...

Edit:
Didn't check yet (lack of time, ended things at 1am) with msys2 gcc version instead of mcf.

[LeXXuz]

Originally Posted by jpsdr

@LeXXuz
I don't know how Mediainfo get his information, neither how x265 stores them. As in auto-aq the aq-mode changes on the fly, according how/when x265 stores the informations retrievied by Mediainfo, it would not be surprising to see differents values. But... for the same file with the exact same parameters, you should always have the same result.

Thanks for that explanation. I was just wondering because sometimes it shows aq-mode=5 which would be correct and sometimes all the others.

Guess I had the wrong understanding of mode 5. I thought it is a mode of its own which behaves like one of the other modes depending on scenery, therefore constantly flagged as mode 5 throughout the entire stream.

So it is more like a 'fictitious' mode which switches through the other modes depending on scenery and changing the mode flags accordingly? That still confuses me a little. Because in that case Mediainfo should never display aq-mode=5 for some files, no?

[jpsdr]

@LeXXuz
No, mode 5 is like the others, always flagged at 5, it's the aq-auto which changes the mode flags according scenery. When using aq-auto, the mode set in aq-mode became irrelevant.

Otherwise, about building x265. Just tested with standard msys2 gcc, it seems that in multilib, despite the -DCMAKE_CXX_FLAGS_RELEASE, the library are not linked...
I'll try to add -DCMAKE_EXE_LINKER_FLAGS at the last step, if it doesn't work, don't know what to try...

Edit:
Failed...
Even when adding -DCMAKE_EXE_LINKER_FLAGS at the last step, the multilib build is not static.
I take any advice...

[Boulder]

Originally Posted by LeXXuz

Thanks for that explanation. I was just wondering because sometimes it shows aq-mode=5 which would be correct and sometimes all the others.

Guess I had the wrong understanding of mode 5. I thought it is a mode of its own which behaves like one of the other modes depending on scenery, therefore constantly flagged as mode 5 throughout the entire stream.

So it is more like a 'fictitious' mode which switches through the other modes depending on scenery and changing the mode flags accordingly? That still confuses me a little. Because in that case Mediainfo should never display aq-mode=5 for some files, no?

If you want to use only aq-mode 5, do not set --aq-auto at all. If you want to use --aq-auto, with SDR the optimal setting is --aq-auto 10, and no need to specify --aq-mode 5 because that mode is then already enabled. The encoder will decide frame-by-frame which mode out of 2-5 it will use.

[jpsdr]

So, the results of my strugles are :
The gcc version provided on www.msystem.waw.pl/x265 is a static build, thanks StvG tips using external cmake, i've been able to make a multilib build, and no needs to add static flags.
This is the only gcc version i've been able to make a static multilib with.
With the others gcc, i'm able to make a static build only on a single lib build. I took any tips to be able to make multilib with them two (the only i'm realy interested in is the mcf).

[LeXXuz]

Originally Posted by Boulder

If you want to use only aq-mode 5, do not set --aq-auto at all. If you want to use --aq-auto, with SDR the optimal setting is --aq-auto 10, and no need to specify --aq-mode 5 because that mode is then already enabled. The encoder will decide frame-by-frame which mode out of 2-5 it will use.

Ah. Now I get it. I thought the --aq-auto 10 mode just replaces the old "--sbrc --sbrc-aq5 --sbrc-hyst" parameters. I didn't know it also switches aq-modes depending on scenery.

[Boulder]

Originally Posted by LeXXuz

Ah. Now I get it. I thought the --aq-auto 10 mode just replaces the old "--sbrc --sbrc-aq5 --sbrc-hyst" parameters. I didn't know it also switches aq-modes depending on scenery.

--sbrc used to be like --aq-auto is now. The x265 devs just accidentally pushed incorrect code as SBRC, which is a very different feature in the fixed code now available.

[tormento]

It's a bit I've been here so tl;dr

Is there a "table" with all the new switches? Where can I find an updated version, compatible with Staxrip reformatting?

[jpsdr]

Yeah... The clang build is twice faster than my gcc builds !
It seems that even if the default setting is "Release", i suspect the compiler options being... poor. It's not possible that this speed difference comes only because of the compiler...

[Boulder]

Originally Posted by jpsdr

Yeah... The clang build is twice faster than my gcc builds !
It seems that even if the default setting is "Release", i suspect the compiler options being... poor. It's not possible that this speed difference comes only because of the compiler...

Assembly not in use?

[jpsdr]

No, it's not that...
I spend a lot of time reading the gcc optimize options, and i'll try rebuild adding a bunch of option...
If it doesn't help, i'll stop wasting time and just provide clang_AVX2 build, period.

[StvG]

Originally Posted by jpsdr

Thanks.

Any idea why this works:
...
and this doesn't:

mkdir -p 8bit_x64 10bit_x64 12bit_x64

cd 12bit_x64
cmake -G "MSYS Makefiles" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON -DCMAKE_CXX_FLAGS_RELEASE="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}
cp libx265.a ../8bit_x64/libx265_main12.a

cd ../10bit_x64
cmake -G "MSYS Makefiles" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DCMAKE_CXX_FLAGS_RELEASE="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}
cp libx265.a ../8bit_x64/libx265_main10.a

cd ../8bit_x64
cmake -G "MSYS Makefiles" ../../../source -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DENABLE_CLI=ON -DENABLE_SHARED=OFF -DLINKED_10BIT=ON -DLINKED_12BIT=ON -DSTATIC_LINK_CRT=ON -DCMAKE_CXX_FLAGS_RELEASE="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}

# rename the 8bit library, then combine all three into libx265.a using GNU ar
mv libx265.a libx265_main.a

ar -M <<EOF
CREATE libx265.a
ADDLIB libx265_main.a
ADDLIB libx265_main10.a
ADDLIB libx265_main12.a
SAVE
END
EOF

For both default gcc from msys and mcf gcc after you run the script go to 8bit_x64/CMakeFiles/cli.dir and open build.make. Go to the line starting with msys64/mingw64/bin/c++.exe and delete -Wl,-Bdynamic. Go to 8bit_x64 and run make ${MAKEFLAGS} to rebuild the exe file.

[jpsdr]

@StvG
Again, you save the day !


Otherwise, as i've said, after searching/reading docs on optimize command for gcc, i've added twice a dozen of options, rebuild with them, and finaly got a .exe that's as fast (almost, at less than 1%... ) than the clang build.

Edit:
Finaly, it didn't work, there is a loooot of lines begining with msys64/mingw64/bin/c++.exe, there is no -Bdynamic in it, and just one line with several -Wl.
I've removed them, but when running make ${MAKEFLAGS} it fails with errors.
The win32 thread version is working fine, i've been able to figure out the commands line to add to build a not slow exe, i'll stop here with gcc, as i have a working process.
I'm now trying to find a process allowing me to make multilib with Visual Studio + llvm.

Edit2:
Been able to do multilib with VS.

[StvG]

Originally Posted by jpsdr

Edit:
Finaly, it didn't work, there is a loooot of lines begining with msys64/mingw64/bin/c++.exe, there is no -Bdynamic in it, and just one line with several -Wl.
I've removed them, but when running make ${MAKEFLAGS} it fails with errors.
The win32 thread version is working fine, i've been able to figure out the commands line to add to build a not slow exe, i'll stop here with gcc, as i have a working process.
I'm now trying to find a process allowing me to make multilib with Visual Studio + llvm.

Just tested with default msys2 gcc and it's fine here.

https://i.slow.pics/WoKl4fIq.png
https://i.slow.pics/sUg1ju0r.png

[jpsdr]

My file wasn't like that.
Also, i wanted to say "i'll stop here with others gcc"

[jpsdr]

New release, check my github.
And now i'm able to make multilib, yeah !!

[Barough]

x265 v3.5+93
Built on February 18, 2023, GCC 12.2.0

DL :
https://www.mediafire.com/file/2nwbzkhcmwiplv3

[jpsdr]

Seriously...! A new version just right now after all my strugles...
They made it on purpose, just after i put my build i spend all this time on...
Have to wait a little time unfortunately for a new build.