x265 HEVC Encoder

[filler56789]

Originally Posted by jpsdr

No luck, i've tried several options, but i always have an error message telling me that libstdc++6.dll is missing when i try to run the x265.exe builded...
Don't know what option i have to use to make a standalone version.

As qyot27 already said, your "best" (ooops ) option is to use a "static" build of GCC for Windows...
so you won't have to mess around with the CMake flags;
(just as an example...) ↓↓↓

Originally Posted by qyot27

-DCMAKE_EXE_LINKER_FLAGS="-static-libstdc++ -static -pthread" when configuring resolves it with vanilla MSys2 with default repo packages.

When I still had the "energy" to make builds of x265.exe, and when I did not use the GCC binaries compiled by myself, I used the GCC packages built by nevcairiel or by www.msystem.waw.pl/x265.

H.T.H. :-|

[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.
@filler56789
Ok, thanks, i'll try with the gcc versions on www.msystem.waw.pl/x265, i allready use this for one of my x264 build.
So it means that the gcc version provided by default with msys2 isn't working with the standard scripts provided in the build/msys directory of x265 git... (unless tweak them).

Edit:
According CMakeList.txt, CMAKE_CXX_FLAGS is not used unless you set CMAKE_BUILD_TYPE to None.
Using CMAKE_CXX_FLAGS seems to me the only way to add tune build options (like -mavx2).
But, i've not been able to figure out what are the CXX_FLAGS options in Release build.

[FranceBB]

Originally Posted by filler56789

I used the GCC packages built by nevcairiel or by www.msystem.waw.pl/x265.

I used them too, but the readme should really be updated as they're no longer Windows XP compatible and have not been for a while now (I think pre-pandemic).

@jpsdr... I'll bother you soon-ish via email, as soon as I have a bit of spare time at work (which is unlikely given the stuff I have to do right now). Anyway, to summarize, although I was totally fine with your x264 mod for x264, the fact that the company I work for is part of the partner program with Multicoreware makes me a bit "sad" to have to use modded version of x265 as well, so I'm determined to gather a list of the changes and come up with a big proposal to MCW to eventually merge them back into x265 and we can do this together given that we already had a chat with them about that other thing you asked last time. TL;DR given that we actually have a say on this, I'd like to avoid having an x265 mod that ends up becoming yet another x264 mod-like kind of situation where changes/fixes/improvements are never merged back and no one cares.

[StvG]

Originally Posted by jpsdr

@filler56789
Ok, thanks, i'll try with the gcc versions on www.msystem.waw.pl/x265, i allready use this for one of my x264 build.
So it means that the gcc version provided by default with msys2 isn't working with the standard scripts provided in the build/msys directory of x265 git... (unless tweak them).

Edit:
According CMakeList.txt, CMAKE_CXX_FLAGS is not used unless you set CMAKE_BUILD_TYPE to None.
Using CMAKE_CXX_FLAGS seems to me the only way to add tune build options (like -mavx2).
But, i've not been able to figure out what are the CXX_FLAGS options in Release build.

For CMAKE_BUILD_TYPE=Release use CMAKE_CXX_FLAGS_RELEASE / CMAKE_C_FLAGS_RELEASE

In order to use provided msys2 gcc and have statically linked internal libs use -DCMAKE_CXX_FLAGS_RELEASE="-static-libgcc -static-libstdc++ -static".

[jpsdr]

@StvG
Yes !! Finaly, it's working with the msys2 gcc. Thanks, after several people tall me the same thing, it finaly enters in my head...

Now... The last step.

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 ?

Edit:
As i was afraid, as i've already installed cmake, even if i put a mingw64 directory without it, msys said that's it's already installed and has nothing to do.
I can't switch to another version...
Edit2:
I was using pacman -S --needed, i changed to pacman -S, it said it's allready installed but re-install anyway, but... only the package, not the necessary dependancies, msys thinks they are all installed.
cmake installed but still not working with alternative gcc version...

@FranceBB
99% of the patches are not mine. They came either from the Patman version or others, i just gathered them.

[filler56789]

@jpsdr && to anyone interested as well...

«User Guide: How to setup an MSYS2 building environment»

https://forum.videohelp.com/threads/...ng-environment

12) Time to edit the file home\YourUsername\.bash_profile.
Add the lines below:

export PS1='[\w]\n<$MSYSTEM> '

PATH=/commons:/CMAKE/bin:/GIT/bin:/HG:$PATH
export PATH

[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.