x265 HEVC Encoder

[LigH]

x265 2.6+2-32e6f04b8713

[pradeeprama]

The default branch of x265 has now moved to use nasm. The stable and release tips will continue to use yasm until the next release of x265.

If you are source-compiling x265, please download and install the nasm release 2.13 or newer from here and make sure that the binary is in your path before compiling.

Let us know if you run into any trouble with getting nasm installed on your machine

[LigH]

For people compiling in pre-installed MSYS environments: Both MABS and XhmikosR (+nevcairiel) already provide nasm 2.13.01, no problem to be expected with them; x265 2.6+5 just passed in both. Visual Studio integration may be more interesting.

[Magik Mark]

Hi!

Can you recommend a professional video editor & Encoder that uses this software?

[Midzuki]

Originally Posted by pradeeprama

The default branch of x265 has now moved to use nasm. The stable and release tips will continue to use yasm until the next release of x265.

If you are source-compiling x265, please download and install the nasm release 2.13 or newer from here and make sure that the binary is in your path before compiling.

Let us know if you run into any trouble with getting nasm installed on your machine

I have tried to compile the latest source-code on my ancient quadcore, but I had to cancel the process because it became incredibly slow

[ 25%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/ipfilter16.asm.obj

is taking more than 3 minutes It even seemed I was using my deceased Pentium 4. What happened? The ASM code itself was changed, OR nasm is too slow by default and should be configured to be faster like the previous release of yasm?

OR "none of the above"?

[Ma]

Yep, nasm is very slow.

[Midzuki]

Then what about switching to FASM?
At least you could check whether it is actually fast =)

http://flatassembler.net/download.php

[qyot27]

Originally Posted by Midzuki

I have tried to compile the latest source-code on my ancient quadcore, but I had to cancel the process because it became incredibly slow

[ 25%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/ipfilter16.asm.obj

is taking more than 3 minutes It even seemed I was using my deceased Pentium 4. What happened? The ASM code itself was changed, OR nasm is too slow by default and should be configured to be faster like the previous release of yasm?

OR "none of the above"?

make -j$(nproc)? Or better, just use the Ninja generator instead of make.

Not that it'll speed up nasm on single files, but at least the build process will use all the cores.

[nevcairiel]

Originally Posted by Midzuki

Then what about switching to FASM?
At least you could check whether it is actually fast =)

http://flatassembler.net/download.php

The code relies quite a lot on the nasm macro language, which is supported by nasm/yasm, so any other assemblers are not feasible.

[Midzuki]

Originally Posted by nevcairiel

The code relies quite a lot on the nasm macro language, which is supported by nasm/yasm, so any other assemblers are not feasible.

Thanks for the explanation *THUMBS UP*

P.S.: for the notes, latest nasm version is 2.13.02 since November 29.

[Barough]

x265 v2.6+8-fc0570b8d8f9 (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version 2.6+8-fc0570b8d8f9
x265 [info]: build info [Windows][GCC 7.2.0][32/64 bit] 8bit+10bit+12bit

https://bitbucket.org/multicoreware/x265/commits/branch/default

[Barough]

x265 v2.6+11-94dc146c5f67 (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version 2.6+11-94dc146c5f67
x265 [info]: build info [Windows][GCC 7.2.0][32/64 bit] 8bit+10bit+12bit

https://bitbucket.org/multicoreware/x265/commits/branch/default

[Stephen R. Savage]

I wonder if x265 developers are even still working on the project anymore, or if all the development effort is going into their proprietary enterprise stuff. There hasn't been any meaningful change to the core encoder in terms of encoding strategy/quality for many versions now. In fact, the public repository sees only a handful of commits a month. Meanwhile, the picture quality is still not competitive with x264, which is similarly inactive, but actually good.

• Detail retention is still not competitive with x264. Disabling stuff like SAO helps with this, but then x265 loses all its advantages in edge artifacts.
• Ghosting artifacts have existed since the beginning (see the Bitbucket issues), but no sign of any developer interest in a solution.
• The recent lambda table change causes massive ringing artifacts on animated content, unless AQ strength is lowered.
• x265 still tends to produce bizarre circular artifacts in flat areas. Banding is also persistent.

Maybe the derailing of HEVC by patent licensing and the next-generation AOM has caused MultiCoreWare to pull out of x265.

Originally Posted by Stephen R. Savage

I wonder if x265 developers are even still working on the project anymore, or if all the development effort is going into their proprietary enterprise stuff. There hasn't been any meaningful change to the core encoder in terms of encoding strategy/quality for many versions now. In fact, the public repository sees only a handful of commits a month. Meanwhile, the picture quality is still not competitive with x264, which is similarly inactive, but actually good.

• Detail retention is still not competitive with x264. Disabling stuff like SAO helps with this, but then x265 loses all its advantages in edge artifacts.
• Ghosting artifacts have existed since the beginning (see the Bitbucket issues), but no sign of any developer interest in a solution.
• The recent lambda table change causes massive ringing artifacts on animated content, unless AQ strength is lowered.
• x265 still tends to produce bizarre circular artifacts in flat areas. Banding is also persistent.

Maybe the derailing of HEVC by patent licensing and the next-generation AOM has caused MultiCoreWare to pull out of x265.

The x265 Developers are wondering who Steven R Savage is, and what he is working on.

[videoh]

That's pretty lame, Mr. x265. Get over yourself. How about responding to the content instead of indulging in ad hominems?

Yeah it's a bit weird when someone is publicly wondering about your commitment and/or competence, as if you aren't in the room.

This is the official x265 HEVC encoder thread, which I started 4 years ago. I get email alerts for new posts, and I check it most every day. If you have a question or concern that you want me to answer, ask me. It's strange to read a post criticizing x265 where I or my team is being referred to in the 3rd person, as if I'm not in the room.

Mr. x265 is a bit formal. I'm on this list publicly, while most people are using anonymous usernames. You can call me Tom. But now I'm also wondering who videoh is, and what he works on. Seriously... I am. Don't you like to know who you're talking to?

If you have examples of content and settings that you feel x265 is not performing well on, let us know through our bug tracker. Yes, we are a business, and we're working to get a return on the millions of dollars of R&D investment we've made in x265.

There is still a very substantial R&D effort on x265 itself, but some improvements take a lot of time, and don't make sense to push into the public repo until they are fully ready.

Take a look at the code. Take a look at the HEVC specifications. This stuff isn't easy.

For comparison...
git pull http://git.videolan.org/git/x264.git
git rev-list --all --count
x264 has 2851 commits in roughly 13 1/2 years.

hg pull -u https://bitbucket.org/multicoreware/x265
hg up tip
x265 has 11948 commits in roughly 4 1/2 years.

Thanks to funding from our customers, and our own investment, our full-time funded commercial development team (and our contributors) have been able to make 4.2x the commits in 1/3 the time.

If you aren't happy with x265, don't worry...it's open source, so you have multiple options...
1 - clone the repo and improve x265 yourself
2 - pay someone to improve it
3 - ask us nicely to improve it
4 - criticize us publicly
5 - use a different encoder

I'm not a big fan of option 4.

[_kermit]

Originally Posted by x265_Project

Yeah it's a bit weird when someone is publicly wondering about your commitment and/or competence, as if you aren't in the room.

This is the official x265 HEVC encoder thread, which I started 4 years ago. I get email alerts for new posts, and I check it most every day. If you have a question or concern that you want me to answer, ask me. It's strange to read a post criticizing x265 where I or my team is being referred to in the 3rd person, as if I'm not in the room.

Mr. x265 is a bit formal. I'm on this list publicly, while most people are using anonymous usernames. You can call me Tom. But now I'm also wondering who videoh is, and what he works on. Seriously... I am. Don't you like to know who you're talking to?

If you have examples of content and settings that you feel x265 is not performing well on, let us know through our bug tracker. Yes, we are a business, and we're working to get a return on the millions of dollars of R&D investment we've made in x265.

There is still a very substantial R&D effort on x265 itself, but some improvements take a lot of time, and don't make sense to push into the public repo until they are fully ready.

Take a look at the code. Take a look at the HEVC specifications. This stuff isn't easy.

For comparison...
git pull http://git.videolan.org/git/x264.git
git rev-list --all --count
x264 has 2851 commits in roughly 13 1/2 years.

hg pull -u https://bitbucket.org/multicoreware/x265
hg up tip
x265 has 11948 commits in roughly 4 1/2 years.

Thanks to funding from our customers, and our own investment, our full-time funded commercial development team (and our contributors) have been able to make 4.2x the commits in 1/3 the time.

If you aren't happy with x265, don't worry...it's open source, so you have multiple options...
1 - clone the repo and improve x265 yourself
2 - pay someone to improve it
3 - ask us nicely to improve it
4 - criticize us publicly
5 - use a different encoder

I'm not a big fan of option 4.

1+

cheers

[Barough]

x265 v2.6+12-7bd8751a8183 (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[WhatZit]

Originally Posted by Stephen R. Savage

Maybe the derailing of HEVC by patent licensing and the next-generation AOM has caused MultiCoreWare to pull out of x265.

What the...? It'd be the exact OPPOSITE, I reckon!

I fully expect a sane Multicoreware to be focusing on greater HEVC industry acceptance in general, and prioritising x265 market penetration in particular.

That they haven't evolved the non-API version of their product much in the last few months might annoy the non-commercial bedroom encoders, but there's a much bigger picture to be seen here.

[LigH]

I keep providing build packages including a DLL, where are all the OpenSource GUI tools using x265 as DLL? ... Just as much demanding as other people demanding progress.

No, I don't want to sound demanding. I want to be curious, at most. And contributing if my little experience permits. Sometimes I do. I hope it was useful when I did.