x265 HEVC Encoder

[LeXXuz]

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

[benwaggoner]

Originally Posted by LeXXuz

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

What aq-strength does is baed on the --aq-mode being used. Generally aq-modes are about preventing blurring in smoother areas caused by more naive PSNR or SAD type metrics. In general x265 will spend fewer bits on areas of high motion that aren't good references for frames later in the GOP; --cutree is the main tool to identify those. This results in adaptive quantization, absolutely, but not directly controlled by --aq-mode or --aq-strength. I'm sure there are some interactions in practice, as all kinds of things can change how x265 allocates bits.

[benwaggoner]

Originally Posted by 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?

That is going to be some old hardware. It wouldn't take that many compressed titles before it'll be cheaper on electricity to buy a newer, faster, and much more efficient CPU. The fastest pre-AVX CPU probably will have <10% the throughput of a modern enthusiast chip, which will have many more cores, AVX2, and overall better instructions per clock.

[Lan4]

Originally Posted by benwaggoner

That is going to be some old hardware. It wouldn't take that many compressed titles before it'll be cheaper on electricity to buy a newer, faster, and much more efficient CPU. The fastest pre-AVX CPU probably will have <10% the throughput of a modern enthusiast chip, which will have many more cores, AVX2, and overall better instructions per clock.

Buying a new processor is too easy. And for the purchase of a processor, you will need a new motherboard, new memory, a new power supply. Still, my question was about the x265 codec.

[Boulder]

Originally Posted by 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?

They work the same way, the encoder uses the instruction sets that are detected.

You might get some performance benefits from compiling the executable with specific tuning for your CPU. Media Autobuild Suite can do this, there is a possibility to tweak the compiler parameters accordingly (-march and -mtune in specific).
https://github.com/m-ab-s/media-auto...nal-user-files

[LigH]

Just committed:

[PATCH] Fix bug in mcstf

Building...

[Barough]

x265 v3.5+97
https://www.mediafire.com/file/bu7j9tn2c98sw5i

[LigH]

New upload: x265 3.5+97-c666bc3d3

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

[jpsdr]

Hello.

Made a new build of my custom mod, check my Github.

Also, i've made out of curiosity some speed tests on my Core i7 6950X, encoding time results :
3.50.0.97 AVX2 GCC 12.2.1 : 614.55s
3.50.0.97 Broadwell GCC 12.2.1 : 608.67s
3.50.0.94 Broadwell LLVM 15.0.7 : 600.10s
3.50.0.97 Broadwell LLVM 16.0.0 : 590.88s

Up to 4% speed difference, well, anything is good to take

[FranceBB]

Originally Posted by Lan4

Buying a new processor is too easy.

Well, if your CPU is AVX capable only, get the AVX build: http://msystem.waw.pl/x265/

it really is as simple as that...

[john33]

Also did some speed tests with results that kind of surprised me:
Ryzen 9 3900XT - Win10 Pro x64
61,070 frames - 1920x816 --crf 24.0 --aq-mode 4 --no-cutree --no-open-gop --no-sao

Winlibs GCC 13.0.1                          1,946.89secs   31.37fps
Winlibs GCC 12.2.0                          1,928.15secs   31.67fps
Msys2 GCC 12.2.0                            1,903.41secs   32.08fps
http://www.msystem.waw.pl/x265/ GCC 12.2.0  1,898.15secs   32.17fps
LLVM Clang 16                               1,718.27secs   35.54fps
VS2019 V16.11.25                            1,717.45secs   35.56fps
Intel 19.2                                  1,600.23secs   38.16fps

These were all AVX2 optimised with similar settings.

[FranceBB]

Originally Posted by LigH

New upload: x265 3.5+97-c666bc3d3

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

Not that it matters, but just so you know and the XP community doesn't find out the hard way, the XP build you provided is attempting to call GetTickCount64 which doesn't exist in XP x86, while it should really be calling GetTickCount.




Sending GetTickCount64 to GetTickCount fixes the issue of course:




I don't know if something changed under the hood in the way you compile (or if indeed is an autobuild issue?), but... well... now you know.

[LigH]

Well, thank you for your discovery ... but don't tell me. I only compile. I do not develop. Multicoreware needs to know (via mailing list) and find a workaround if they still officially support XP compatibility at all. Instead they may probably just call it obsolete.

[benwaggoner]

Originally Posted by LigH

Well, thank you for your discovery ... but don't tell me. I only compile. I do not develop. Multicoreware needs to know (via mailing list) and find a workaround if they still officially support XP compatibility at all. Instead they may probably just call it obsolete.

Given that there is no support or security updates for XP, I think it makes sense to not offer builds for it anymore as that's encouraging people to stick with insecure systems.

For embedded applications things are different, of course.

XP doesn't have explicit NUMA support and is missing a lot of other things helpful for maximizing performance.

[filler56789]

Originally Posted by benwaggoner

XP doesn't have explicit NUMA support and is missing a lot of other things helpful for maximizing performance.

That's a very-good reason for an HEVC encoder to drop Windowx XP support.

OTOH,

Given that there is no support or security updates for XP, I think it makes sense to not offer builds for it anymore as that's encouraging people to stick with insecure systems.

is just a lame excuse for trollish devilopment.

Seriously: 🆖

[LigH]

I don't mind unmounting a dead horse. There are plenty old but functional versions.

[FranceBB]

Originally Posted by benwaggoner

Given that there is no support or security updates for XP

Although Microsoft pulled support in mid 2019 with the last security update, there's still 0Patch that picked up the task. That + a good antivirus like Avast and it's good enough for a home user, probably.
Anyway, I found out 'cause I do regular testing on all environments in a VM and one of those is indeed XP.

Originally Posted by benwaggoner

I think it makes sense to not offer builds for it anymore

Nah, as I showed it's easy enough to build it in an XP compatible way, so much so that with 1 minor adjustment the build works. My post was more of a "just so you know", that's it.

Originally Posted by LigH

Well, thank you for your discovery ... but don't tell me. I only compile. I do not develop.

Yeah, that's the thing, it's not the source code per se, rather I'm trying to figure out why the compiler is calling a non existing kernel function while it really shouldn't given that you're targeting XP in a specific build...

TL;DR Multicoreware has nothing to do this with, rather the compiler or whoever made the autobuild compilation script :P

Originally Posted by benwaggoner

XP doesn't have explicit NUMA support and is missing a lot of other things helpful for maximizing performance.

True. In a multicore and multisocket environment, it would probably underperform by a margin: no NUMA, no AVX, no AVX2, no AVX512, also 32bit version of bit depth higher than 8bit don't have any intrinsics at all, so they would run in plain C. Anyway, I don't really think there are any businesses out there running XP/Server 2003 to encode stuff; I myself am on Server 2019 x64 with my farm at work, but I was thinking more about some home users, that's it.

[ShortKatz]

Finally someone made a pull request to fix the compilation on macOS arm64.
https://mailman.videolan.org/piperma...il/013600.html
Hopefully this patch gets applied soon to fix the broken arm64 compilation on macOS.

[LigH]

Originally Posted by FranceBB

Multicoreware has nothing to do this with, rather the compiler or whoever made the autobuild compilation script :P

In that case ... it might be possible that newer GCC versions (12) should get added a command line parameter which was not yet required in older versions (9/10)?

[benwaggoner]

Originally Posted by ShortKatz

Finally someone made a pull request to fix the compilation on macOS arm64.
https://mailman.videolan.org/piperma...il/013600.html
Hopefully this patch gets applied soon to fix the broken arm64 compilation on macOS.

It was checked in five days ago! Yay!

https://bitbucket.org/multicoreware/...25267b16258c21