x265 HEVC Encoder

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

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]

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]

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]

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]

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 !
:thanks:

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%... :D) 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]

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 !! :D

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

[Boulder]

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.

The latest commits don't concern the regular Windows binary at all I think.

[jpsdr]

Except maybe just one on the asm file, not being sure, i've made new builds, you can get them on my github.

[jpsdr]

Noooooooooooooooooooooooooooooooooooooooooooooooooooooo !!!!!!!!!!!!!!!!!!!!!!!!

[john33]

x265 v3.5+94
Built on February 20, 2023, VS2019 (AVX2 compiler optimisation)

DL: https://www.rarewares.org/files/x265-r3.50.94-20230220.zip

[Morku]

Noooooooooooooooooooooooooooooooooooooooooooooooooooooo !!!!!!!!!!!!!!!!!!!!!!!!

xD Love your build.

[filler56789]

x265 v3.5+94
Built on February 20, 2023, VS2019 (AVX2 compiler optimisation)

DL: https://www.rarewares.org/files/x265-r3.50.94-20230220.zip

Does your build also encode audio, like some ancient mods of x264? :)

[LeXXuz]

Noooooooooooooooooooooooooooooooooooooooooooooooooooooo !!!!!!!!!!!!!!!!!!!!!!!!
LOL. Someone over there must know when you just finished your work. :D:D:D
SCNR!:devil:

Really appreciate your builds. Still using +87 and I'm very happy with it. See no reason to update any time soon. ;)

[john33]

Does your build also encode audio, like some ancient mods of x264? :)

Just a current git build. :)

[jpsdr]

Made a new build, check my github.

[john33]

Since (and including) r3.50.0.87.1, the " // solve "fatal error C1061: compiler limit : blocks nested too deeply"" error has returned with attempted MSVC compiles of the "Patman" version. (source\common\param.cpp) GCC doesn't exhibit this issue. The standard git version does not have this problem so it is obviously to do with the "Patman" mods. And, @jpsdr, you'll be happy to know there is another update! ;)

[filler56789]

And, @jpsdr, you'll be happy to know there is another update! ;)

:devil: :D

That's why I'll keep using version 3.3+10 forever😇

[john33]

x265 v3.5+95
Built on February 22, 2023, VS2019 (AVX2 compiler optimisation)


DL:https://www.rarewares.org/files/x265-r3.50.0.95-20230222.zip

[Barough]

x265 v3.5+96
Built on February 22, 2023, GCC 12.2.0

DL :
https://www.mediafire.com/file/lvwa18uv48f4aq9

[jpsdr]

It's not even funny anymore...

Edit:
After looking the commits, not offect on PC, so no build necessary... :D
Yes !!!

[jpsdr]

The standard git version does not have this problem so it is obviously to do with the "Patman" mods.
It's not the Patman mods, it's the commands i've added.
This make me adds parameters description, and with the standard version it's very close to the limits.
If the standard version adds 3 or 4 others commands, it will hit also the limit.

[john33]

It's not the Patman mods, it's the commands i've added.
This make me adds parameters description, and with the standard version it's very close to the limits.
If the standard version adds 3 or 4 others commands, it will hit also the limit.

So I guess we're already there. ;)

[~ VEGETA ~]

hello,

in my setup i encode lossless 1080p first, then use it to encode final 1080p, 720p, etc.. this is usually in x264, qp 0 ultrafast for lossless which gives me fast enough results.

can I use that output as input to x265?

my lossless is .mkv but i can easily make it .yuv or .y4m if needed. I tried inputting that to x265 but it didn't take all frames even when specified, then outputted garbage video (full of colors and no actual content).

I prefer a direct usage of x265 rather than piping from vspipe or so.

for your kind input please.

[LigH]

New upload: x265 3.5+94-74a312564 (https://www.mediafire.com/file/grue0bgcpsjbuh4/x265_3.5+94-74a312564.7z/file)

[Windows][GCC 12.2.0][32/32XP/64 bit] 8bit+10bit+12bit

[jlpsvk]

it's better to use --aq-mode 2 or --aq-auto 6 for 4K HDR? both giving me almost same bitrate at CRF16 with preset slower (with some manual settings)

[benwaggoner]

it's better to use --aq-mode 2 or --aq-auto 6 for 4K HDR? both giving me almost same bitrate at CRF16 with preset slower (with some manual settings)
--aq-mode 2 is pretty optimal for 4K HDR encoding. The --aq-auto might be just picking that mode repeatedly, hence not much of a bitrate difference. Have you checked visually?

[redbtn]

--aq-mode 2 is pretty optimal for 4K HDR encoding. The --aq-auto might be just picking that mode repeatedly, hence not much of a bitrate difference. Have you checked visually?

Do you still recommend using --aq-mode 2 over --aq-mode 4 for 4K HDR?
I use --aq-mode 4 for SDR, but not sure about HDR.

[benwaggoner]

Do you still recommend using --aq-mode 2 over --aq-mode 4 for 4K HDR?
I use --aq-mode 4 for SDR, but not sure about HDR.
I use --aq-mode 4 for SDR and --aq-mode 2 for HDR.

[ShortKatz]

I recently started to use --aq-mode=4 for everything. It has been said --aq-mode=4 is for "videos with high edge contents (Ex: Ducks take off, Crowd run, Raindrops etc)". (1) And because this can happen in every video, I use 4 now with every kind of video. I've noticed that the encoding time is reduced for --aq-mode=4 compared to --aq-mode=2. I also visually like the result better (HDR and SDR).
(1) https://www.mail-archive.com/x265-devel@videolan.org/msg11661.html

[benwaggoner]

I recently started to use --aq-mode=4 for everything. It has been said --aq-mode=4 is for "videos with high edge contents (Ex: Ducks take off, Crowd run, Raindrops etc)". (1) And because this can happen in every video, I use 4 now with every kind of video. I've noticed that the encoding time is reduced for --aq-mode=4 compared to --aq-mode=2. I also visually like the result better (HDR and SDR).
(1) https://www.mail-archive.com/x265-devel@videolan.org/msg11661.html
In extensive testing, I found --aq-mode 2 to be slightly better overall compared to 4 for CVBR encoding of premium 24p HDRcontent, given a number of other parameters that were also used. But certainly 4 is probably better for some content and/or parameter combinations. The real comparison should probably be between the modes both with their own optimal --aq-strength, as generally --aq-mode 4 tends to be optimal with somewhat lower strengths than the other modes.

It's also possible that the --auto-aq mode isn't optimally tuned for HDR content; I've not tested with the feature myself.

[ShortKatz]

Yes, I still need to find the optimal --aq-strength. This will probably take some time.

[benwaggoner]

Yes, I still need to find the optimal --aq-strength. This will probably take some time.
And aq-strength is pretty content dependent, lower for cel animation and high grain, higher with cleaner natural images and CGI.

[ksks]

Hello,
I noticed that a trouble took place when someone was trying to use --rd-refine in order to encode videos with better quality and smaller size. I wonder if that could been solved as they thought.

https://bitbucket.org/multicoreware/x265_git/issues/630/rd-refine-will-cause-some-glitch-in-some
https://github.com/Mr-Z-2697/x265-Yuuki-Asuna/commit/8d78b0fa48d09f0f2b5a58372d573a4711a432fa#commitcomment-103498859

[benwaggoner]

I just noticed today is the 2nd anniversary of x265 3.5.

We've never had even a one year gap from releases before now. I hope a 3.6 is coming before long. There have been quite a few new features and fixes it would be nice to have in a official build.

[Barough]

I just noticed today is the 2nd anniversary of x265 3.5.

We've never had even a one year gap from releases before now. I hope a 3.6 is coming before long. There have been quite a few new features and fixes it would be nice to have in a official build.

It's been very slow going with x265 for sometime now. I sure do hope for v3.6 in a near future.

[ShortKatz]

Yes, the development of x265 has become really slow. My guess is that MCW is focusing more on x266 at the moment and therefore neglecting x265.

[~ VEGETA ~]

I have ryzen 7900x cpu with nvidia rtx 3060ti, which version should i use? what is the best website to get these up to date binaries from?

also, any specific cli commands regarding my cpu which can increase performance?

[LigH]

The GPU does not matter at all for x265.

The CPU supports AVX2 which any x265 build for an intel/AMD compatible CPU will detect and use automatically. It also supports AVX512 what you would have to enable by a command line parameter, but it will heat up the CPU a lot more and may get its clock rate throttled, so it may be faster or not, but will be a risk for reliability.

The most important core functions of x265 have CPU optimizations in several variants. There are also builds out there which are further optimized in rarely used functions, so their gain will probably be negligible. It is probably much more important to find a sane balance between multithreading of prefiltering (in AviSynth or VapourSynth or whatever conversion system you prefer) and multithreading in x265, to utilize all the cores without severe bottlenecks.

[Lan4]

Tell me the best x265 build for a processor with AVX only. Or similarly, build doesn't matter, they all work the same way?

[LeXXuz]

I have an argument with someone.
If I increase aq-strength, do high motion areas/scenes get more or less bits?