x265 HEVC Encoder

[excellentswordfight]

Originally Posted by tormento

Did anybody see 9950x x265 benchmarks with and w/o AVX512 enabled?

Asking for Arrow Lake ones is a bit early but please notice them when you see them too.

I feel the urge of changing my rig (I am still on a i7-2600k) but I will wait until AMD shows their Zen 5 3D flavors.

https://www.hwcooling.net/en/how-muc...to-turn-it-on/

So its the same as from what i've seen from the latest server chips, 5-10% increase.

From what i've seen its very close between 9950x and Core Ultra 9 285K in x265. According to techpowerup they also have pretty much the same perf/w in Cinebench (so we can guestimate that its pretty similar in x265 as well), so from that point on view I guess it doesnt matter which team you choose either.

If its strictly for encoding, do note that the X3D models might be slower, as previous models has been that as there is little gain from the L3 Cache in this workload and the models has been lower clocked.

[Ritsuka]

By the way, it seems they are committing new changes only to a "Release_4.1" branch, and forgetting about the master branch.

[Z2697]

Originally Posted by Ritsuka

By the way, it seems they are committing new changes only to a "Release_4.1" branch, and forgetting about the master branch.

Now they realized that and pushed a set of commits to master branch just an hour ago.

[benwaggoner]

Originally Posted by excellentswordfight

https://www.hwcooling.net/en/how-muc...to-turn-it-on/

So its the same as from what i've seen from the latest server chips, 5-10% increase.

From what i've seen its very close between 9950x and Core Ultra 9 285K in x265. According to techpowerup they also have pretty much the same perf/w in Cinebench (so we can guestimate that its pretty similar in x265 as well), so from that point on view I guess it doesnt matter which team you choose either.

If its strictly for encoding, do note that the X3D models might be slower, as previous models has been that as there is little gain from the L3 Cache in this workload and the models has been lower clocked.

At this point, I wouldn't be surprised if Apple's new M4 Max turns out to be the fastest x265 encoding platform on the planet. It is winning in single-core performance, and there's been a LOT of SIMD and other optimizations added in the last couple of years.

It'd be weird and funny if a tricked out Mac Mini is the fastest x265 platform. The mini would certainly win in throughput per rack unit or per watt.

[Z2697]

Originally Posted by benwaggoner

At this point, I wouldn't be surprised if Apple's new M4 Max turns out to be the fastest x265 encoding platform on the planet. It is winning in single-core performance, and there's been a LOT of SIMD and other optimizations added in the last couple of years.

It'd be weird and funny if a tricked out Mac Mini is the fastest x265 platform. The mini would certainly win in throughput per rack unit or per watt.

But at what cost ($$$)

[benwaggoner]

Originally Posted by Z2697

But at what cost ($$$)

US$1599 for the 14 core M4 Pro with 24 GB RAM (should be enough for 4K; the M-series is really memory efficient).

For a cluster, one could upgrade to 10 Gbps ethernet for another $100. Extra RAM and internal storage are pricey, but likely not needed for many applications.

[FranceBB]

Originally Posted by benwaggoner

At this point, I wouldn't be surprised if Apple's new M4 Max turns out to be the fastest x265 encoding platform on the planet.

If that ever happens, I'm gonna go in the server room and yell to each one of my 56c/112th AVX512 x86_64 Intel Xeon "you're pathetic!".

[benwaggoner]

Originally Posted by FranceBB

If that ever happens, I'm gonna go in the server room and yell to each one of my 56c/112th AVX512 x86_64 Intel Xeon "you're pathetic!".

Yeah, past a certain resolution and frame threads, more cores will start winning over better cores. M4 Max likely wins for 1080p or lower, and possibly 4K if using only 1 frame thread.

Unfortunately the M4 Max is only in MacBook Pro, which is a whole lot more expensive and bigger for headless work. Mac Mini tops out with the M4 Pro currently.

[LigH]

New upload: x265 4.0+42-5203eb5

[Windows][GCC 14.2.0][32b/32b~XP/64b/64b+MV] 8bit+10bit+12bit

[Z2697]

They probably opened release 4.1 branch too early and now they have to push to two branches simultaneously

[LigH]

New upload: x265 4.0+60-e012793

[Windows][GCC 14.2.0][32b/32b~XP/64b/64b+MV] 8bit+10bit+12bit

contains a lot of important fixes (e.g. of memory leaks) and improvements

[Barough]

x265 v4.0+61-7cc403076
Built on November 13 2024, GCC 14.2.0
Win32/64 / 8bit+10bit+12bit

https://www.mediafire.com/file/i1iuybxy5w3w6g6

[asarian]

Originally Posted by Barough

x265 v4.0+61-7cc403076
Built on November 13 2024, GCC 14.2.0
Win32/64 / 8bit+10bit+12bit

https://www.mediafire.com/file/i1iuybxy5w3w6g6

A bit confusing. Is your x265 version in competition with that of LigH? And yours is .61 I see.

[LigH]

The difference between v4.0+60 and v4.0+61 is probably:

A few tabs converted to spaces to equalize indentation.

Nothing that would affect the generated code.

[asarian]

Originally Posted by LigH

The difference between v4.0+60 and v4.0+61 is probably:

A few tabs converted to spaces to equalize indentation.

Nothing that would affect the generated code.

Thanks for the clarification.

[LigH]

More quality related patches (addressing e.g. memory leaks / double frees, crashes) are being submitted. Also pmode and pme will deprecate. Expect commits soonish...

[LigH]

Version 4.1 has been released.

The v4.1 release of x265 is out now. Below is the list of new features, optimization, and bug fixes in this version.

Version 4.1
===========

Release date - 22nd November, 2024.

New feature
-----------
1. Aom Film-Grain characteristics as a SEI message to support Film Grain Synthesis.

API changes
-----------
1. API Support to enable VBV end feature.
2. Reverted the 4.0 api changes.
3. Added command line parameters for Aom film grain characteristics as a SEI message to the bitstream (--aom-film-grain).
4. Added support to configure Bitrate, CRF, and QP at frame level, along with CLI support for frame-level RC configuration (--frame-rc)
5. Declared few params(numapools, csvfn, scalingLists etc) with fixed size to fix memory leaks

Optimizations
-------------
1. Eliminated redundant pointer copies in lowresMC and lowresQPelCost, improving encoding performance by up to 0.9% on modern CPUs.
2. Mcstf optimization - Improved mcstf performance by moving mcstf computation to lookahead and search range optimization.

Bug fixes
---------
1. mcstf crash when using multiple frame threads.
2. CLI parsing for MV-HEVC Encode.
3. segfault and decoder crash in scc.
4. compilation issue in clang.
5. potential stack buffer overflow issues.
6. documentation for b-intra, max-merge, limit-refs and qg-size
7. memory leak fixes for sei, zones, sao, hme, vbv, sbrc, mcstf, alpha, multiview, scc, two pass, rskip, film grain, aq-mode, scaling_list, fades, analysis save and load etc

Known issues
------------
1. Inconsistent output with recon option
2. Output mismatch between analysis save & load with cutree for reuse-levels < 10

Thanks,
Mahesh

[jpsdr]

A lot of commits, but the version is 4.0.0.077, so still a 4.0.0, not 4.1.

[LigH]

You say? ... My MinGW+GCC workflow calculates version 4.1+54-fa27709.

[jpsdr]

Ah... As i have a custom version, maybe something went wrong, even with pushing the tags.
The fact is the exe i built is tagged 4.0.0.77.
Well... i don't realy mind, the more important is to have the commits.