x265 HEVC Encoder

[Barough]

If it still compiles without that 0001-cmake-split-absolute-library-paths-to-L-and-l.patch, then probably yes.

I'll test if compiling fails without...

Looking forward to your results

Remove / comment out that line in the compile script will be OK

Ok

[LigH]

Compiling without the patch works. And the hash matches. So it got removed from M-AB-S.

New upload: x265 4.0+10-304f02f (https://www.mediafire.com/file/5gswu8rcm4rwmbv/x265_4.0+10-304f02f.7z/file)

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

[LigH]

They reverted the API change with the multiple video streams. Now ffmpeg doesn't compile anymore, again.

[Z2697]

Reverting API change almost right after release... Isn't that somewhat reckless?

[Selur]

Only if it was part of a release, otherwise, I would say: not really.

[Z2697]

It's 4.1 time
Wow

[benwaggoner]

It's 4.1 time
Wow
x265 development has certainly picked up in 2024!

3.7 and 4.0. BIG speedups for ARM. MV-HEVC. Plus tons of quality improvements, bug fixes, and performance tweaks.

[Ritsuka]

x265 development has certainly picked up in 2024!

3.7 and 4.0. BIG speedups for ARM. MV-HEVC. Plus tons of quality improvements, bug fixes, and performance tweaks.

And many questionable choices, like adding Neon DotProd and I8MM optimisations without any run time check, so it will crash if you compile with those enabled and run it on a CPU that don't implement them.

It's like compiling AVX512 optimisations and trying to run them on a AVX2 cpu.

Oh well, it's not actually hard to add some run time checks.

[asarian]

x265 v4.0+23-487105d
Built on October 11 2024, GCC 14.2.0
Win32/64 / 8bit+10bit+12bit

Yikes, I am still on HEVC encoder version 3.5+2-g2b25c9ba0+45. Maybe I should upgrade. :)

[tormento]

Arrow Lake officially presented.

AVX-512 missing.

Fuck.

I hope it will be on par with Zen5 with AVX-512 or I will have to change cpu brand after 30+ years of Intel use.

Or wait for some cheap used Xeon.

[asarian]

Arrow Lake officially presented.

HEVC encoder version 3.5+2-g2b25c9ba0+45 missing.

Fuck.

I hope it will be on par with Zen5 with AVX-512 or I will have to change cpu brand after 30+ years of Intel use.

Or wait for some cheap used Xeon.

Eh. AVX-512 has always been a nightmare for me (i9 12900K). Problem with AVX-512 is, that it is so good, that it takes too much power. That means, for one, reduced sustained power availability for the entire CPU, and increased heat production; and the clockspeed needs to drop down significantly (in the BIOS) on AVX-512 even.

All extensive x265 testing I ever did with AVX-512 enabled, always worked out worse than just running without. AVX-512 is great on paper, but is, IMHO, indeed best just forgotten (unless you possess professional server cooling).

[LigH]

Sounds like the ratio between gain of efficiency and waste of power was not very comfortable?

But that is rather a separate topic, doesn't concern the development of x265 too much.

[tormento]

All extensive x265 testing I ever did with AVX-512 enabled, always worked out worse than just running without.
Both Zen5 core and last Xeon one show a few watt differences with AVX-512 on on off. That's not a concern anymore.

https://cdn.mos.cms.futurecdn.net/mfYbGGM3VEA8imRWXpSGHm-970-80.png

[LigH]

But AVX-512 support in x265 already exists. So discussing the support in CPU hardware doesn't matter much in this thread...

[benwaggoner]

Both Zen5 core and last Xeon one show a few watt differences with AVX-512 on on off. That's not a concern anymore.
Did you look at fps/watt? That's the more relevant question.

[benwaggoner]

Eh. AVX-512 has always been a nightmare for me (i9 12900K). Problem with AVX-512 is, that it is so good, that it takes too much power. That means, for one, reduced sustained power availability for the entire CPU, and increased heat production; and the clockspeed needs to drop down significantly (in the BIOS) on AVX-512 even.

All extensive x265 testing I ever did with AVX-512 enabled, always worked out worse than just running without. AVX-512 is great on paper, but is, IMHO, indeed best just forgotten (unless you possess professional server cooling).
AVX-512 has gotten better in Zen 5 and more recent Intel architectures. The first iteration seemed to double throughput and then cut internal clock speed in half, so gains were maybe 10% at best.

[asarian]

Both Zen5 core and last Xeon one show a few watt differences with AVX-512 on on off. That's not a concern anymore.

If that small difference in wattage is caused by the rather severe multiplier-throttling beating AVX-512 normally takes on my i9 12900k, then that is, IMHO, already de facto, an 'admission of guilt.' as it were (in that Intel thereby admits AVX-512 cannot run normally, needs reduced speed -- and even then consumes a lot of power -- and is thus effectively a failure).

My i9 12900k is not the latest CPU, though, so I'm sure a Xeon fare better in that regard.

[asarian]

AVX-512 has gotten better in Zen 5 and more recent Intel architectures. The first iteration seemed to double throughput and then cut internal clock speed in half, so gains were maybe 10% at best.

^^ This. Plus, even at reduced speed, the power draw was insane, affecting the max power draw duration of the CPU (set to max); so, overall, negatively impacting the entire job. Not to mention heat issues (with watercooling even).

[Z2697]

AVX-512 is now a lot better than is was, based on some testing results published online, the only AVX-512 cpu I have owned is 7950X at this point. (still using, waiting to upgrade to 9950X)
But the performance benefit in video encoders is still only a few percent.

[Z2697]

If that small difference in wattage is caused by the rather severe multiplier-throttling beating AVX-512 normally takes on my i9 12900k, then that is, IMHO, already de facto, an 'admission of guilt.' as it were (in that Intel thereby admits AVX-512 cannot run normally, needs reduced speed -- and even then consumes a lot of power -- and is thus effectively a failure).

My i9 12900k is not the latest CPU, though, so I'm sure a Xeon fare better in that regard.

https://www.phoronix.com/review/amd-zen5-avx-512-9950x/7
You need to see the full picture.

[Z2697]

Arrow Lake officially presented.

AVX-512 missing.

Fuck.

I hope it will be on par with Zen5 with AVX-512 or I will have to change cpu brand after 30+ years of Intel use.

Or wait for some cheap used Xeon.

30+ years of exclusively using Intel CPU?

Do you mind to share some of your story?

[LigH]

Again, why here in a thread about the development of x265?

[tormento]

Again, why here in a thread about the development of x265?
As you are the only one complaining, eventually evaluate your "in topic" metrics. ;)

[Z2697]

I agree this is off topic, but sometimes a slight off topic is unavoidable.

This starts with an analogy of x265's runtime instruction set detection on ARM chips.

adding Neon DotProd and I8MM optimisations without any run time check

It's like compiling AVX512 optimisations and trying to run them on a AVX2 cpu.


(To be clear, I'm not blaming Ritsuka for this.)

[asarian]

https://www.phoronix.com/review/amd-zen5-avx-512-9950x/7
You need to see the full picture.

I'll leave it be, from here on in, but just read we can forget about AVX-512 on Intel Core Ultra CPU's. So, there's that.

[kurkosdr]

x265 development has certainly picked up in 2024!

3.7 and 4.0. BIG speedups for ARM. MV-HEVC. Plus tons of quality improvements, bug fixes, and performance tweaks.
Nothing surprising here: where there is demand, there is supply. To this day, there is no way to create stereoscopic videos for the Apple Vision Pro other than using the little black box that Apple provides. So, there are lots of people with well-spec'ed PCs used for content creation who want to create stereoscopic videos for the Apple Vision Pro without having to buy a Mac just for that, so there is the demand side.

MultiCoreWare wants their product (x265) to be part of the supply and are moving fast to make it a reality, hence the supply. What remains to be seen is whether it'll be possible to do this using open-source GUI software, since GUIs that use x265 as the encoder need to add support for the feature.

[Z2697]

Nothing surprising here: where there is demand, there is supply. To this day, there is no way to create stereoscopic videos for the Apple Vision Pro other than using the little black box that Apple provides. So, there are lots of people with well-spec'ed PCs used for content creation who want to create stereoscopic videos for the Apple Vision Pro without having to buy a Mac just for that, so there is the demand side.

MultiCoreWare wants their product (x265) to be part of the supply and are moving fast to make it a reality, hence the supply. What remains to be seen is whether it'll be possible to do this using open-source GUI software, since GUIs that use x265 as the encoder need to add support for the feature.

Now some avs and vpy input support will be very convenient for MV-HEVC, otherwise 2 large temp files are required, or maybe named pipe.

8-bits only is disappointing though.

[kurkosdr]

8-bits only is disappointing though.
x265's MV-HEVC encoder doesn't do 10-bit? Not even 10-bit SDR?

[rwill]

x265's MV-HEVC encoder doesn't do 10-bit? Not even 10-bit SDR?

It is more a question of supported Profiles and not core capabilities. Up until recently there was no Multiview Profile with more than 8 bits defined in the H.265 standard. The most recent 07/24 release of the standard then specified a Multiview Profile that also allows for 10 bit.

[Z2697]

The profiles are sometimes too conservative...

[Z2697]

I don't know how Apple is involved in MV-HEVC and Alpha-HEVC but multiview encoding was in AVC already, alpha support is kinda new thing in MPEG world (libvpx supports alpha channel) and probably has more things to do with Apple than multiview.

[kurkosdr]

I don't know how Apple is involved in MV-HEVC and Alpha-HEVC but multiview encoding was in AVC already, alpha support is kinda new thing in MPEG world (libvpx supports alpha channel) and probably has more things to do with Apple than multiview.
The Apple Vision Pro uses MV-HEVC for stereoscopic videos, and Apple provides a tool for converting stereoscopic videos to MV-HEVC-encoded video suitable for the Apple Vision Pro.

This is the only significant use of MV-HEVC so far, that's why people started caring about MV-HEVC only after the reveal of the Vision Pro (note: Blu-ray 3D uses MVC aka the multiview encoding for AVC as you hinted).

[ShortKatz]

FFmpeg is going to mark x265 as experimental because of some "serious issues".
https://ffmpeg.org//pipermail/ffmpeg-devel/2024-October/335119.html

[Z2697]

If it's actually changed, that's breaking their own API (sort of) while blaming mcw break x265 API...
I think the experimental flag should be indicating the implementation in FFmpeg is "not production ready", not really fits this situation? For example, only libx265.c (not including upstream) or native decoders/encoders.

[FranceBB]

Yeah... marking it as experimental after more than 10 years doesn't make any sense. I'm gonna reply to the email chain stating my case hoping to stop this absurdity. Please add your replies as well. The more the merrier.

https://ffmpeg.org//pipermail/ffmpeg-devel/2024-October/335131.html

No, I strongly disagree.
Marking a vital encoder as libx265 that thousands of people rely on as "experimental" after more than 10 years since its inclusion doesn't make any sense and would make more harm than good.

Besides, the experimental flag is supposed to be used to indicate that the implementation in FFmpeg is "not production ready", which doesn't really fit this situation as it's an external open source encoder.

The right thing to do is to contact multicoreware directly and get the bug fixed once and for all.

[rwill]

The right thing to do is to contact multicoreware directly and get the bug fixed once and for all.


It is not a single bug, its multiple and their count grew since certain people have left x265 development. 'Somehow' marking x265 as not stable enough for production is the right thing to do.

[Boulder]

Any kind of proper patch review process went out the door a long time ago, and now there have been so many new things squeezed in that it was bound to create major issues.

[Z2697]

Oops, I searched through commits and found that experimental flag were used for external libraries but rarely, specifically, 3 times: libopenjpeg, libvpx-vp9 and libaom if I didn't miss something and all with a cetrain version check

Here're my assumptions:
API change breaks compilation but does not affect production after patch, ideally.
Memory leak a few hundreds of bytes will affect production in some way, like an encoding server that encodes millions of video streams in a run, but experimental flag mainly affects the command line tools, which won't "save" the sever use case, unless the server is using command line tools, but then the process is probably terminated after each video stream, and OS can reclaim it's memory.
Minor problems. The difference I think is FFmpeg have series of fixes every once in a while, but x265 is... once in a whiiiiiiiiiiiiiiiiiiilllllllllllllllllllllllle.

[FranceBB]

Kirithika Kalirathnam from Multicoreware replied to the mailing list by the way:


Hi al ,

We understand your concern behind marking x265 as experimental but w wanted to lt you know that our x265 deveopment tem is activey working
on resolving multipl issues that have been brought to our notice so fr
through bitbucket issue tracker(including issue #482) and are plnning to
reese v4.1 with al the fixes shortly. We are aso continuously lveling
up our tests to catch the issues beorehand and keep up code hygiene that
we have maintained so fr. Hence we request this forum to reconsider th decision for the beneit of severa x265 users.

*Thanks,*
*Kirithika*




I still think it shouldn't be marked as experimental.
I'm already compiling FFMpeg with a few unmerged patches applied (DolbyED2 decoding) so compiling with yet one more parameter isn't gonna make a difference in my very specific case, but it would have repercussions on plenty of other people, I'm sure.

I'd say "give them a chance".

[Z2697]

Kirithika Kalirathnam from Multicoreware replied to the mailing list by the way:





I still think it shouldn't be marked as experimental.
I'm already compiling FFMpeg with a few unmerged patches applied (DolbyED2 decoding) so compiling with yet one more parameter isn't gonna make a difference in my very specific case, but it would have repercussions on plenty of other people, I'm sure.

I'd say "give them a chance".

I think this is a user standpoint vs developer standpoint situation.
BTW, what happend to you quote? Words are deformed from the actual mail.

[FranceBB]

I think this is a user standpoint vs developer standpoint situation.

Yeah... and as a user I clearly value the practical implications that it would have more than the theoretical ones.


BTW, what happend to you quote? Words are deformed from the actual mail.

No idea, but it's not the actual Doom9 quote, I've got the email like that in my email client, so I think it got truncated/deformed either when the Multicoreware employee sent that to the mailing list or when the server forwarded it to everyone.

[Emulgator]

<JOKE>That might be...the final effort of data reduction, or ? See my signature</JOKE>

[GeoffreyA]

<JOKE>That might be...the final effort of data reduction, or ? See my signature</JOKE>

Perhaps we're advancing into the era of lossy text compression :)

[Z2697]

Sometimes bitbucket says the repo is updated but when I check commits, issues and pull requests there's no update.
Does anyone know why?
I mean, I can guess it's some private change, but I'm not familiar with bitbucket. Are private commits/branches in public repo possible?
https://files.catbox.moe/pfzt3x.png

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

[excellentswordfight]

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-much-does-avx-512-help-zen-5-in-x265-and-how-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]

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]

https://www.hwcooling.net/en/how-much-does-avx-512-help-zen-5-in-x265-and-how-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]

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 ($$$:sly:)