x265 HEVC Encoder

[Barough]

x265 v2.6+8-fc0570b8d8f9 (http://www.mediafire.com/?077qpb7750kug46) (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 (http://www.mediafire.com/?lwqyaha1uyyf2ac) (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.

[x265_Project]

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?

[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 (https://bitbucket.org/multicoreware/x265/src). Take a look at the HEVC specifications (http://www.itu.int/rec/T-REC-H.265-201612-I/en). 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]

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 (https://bitbucket.org/multicoreware/x265/src). Take a look at the HEVC specifications (http://www.itu.int/rec/T-REC-H.265-201612-I/en). 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 (http://www.mediafire.com/?q6zcl5a1o5iiy5l) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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

[WhatZit]

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.

[sneaker_ger]

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.
Encoder development is difficult. Like rocket science or maybe even harder. It seems all the low-hanging fruits have been picked...

[excellentswordfight]

Encoder development is difficult. Like rocket science or maybe even harder. It seems all the low-hanging fruits have been picked...
I think most people get that, and I do belive that x265 is an amazing encoder and that the devs and contributers have done amazing work the last couple of years, but I do understand the naysayers that complains beacuse x264 is still superior for near visually lossless HD encodes. And while I think that x265 outperformance x264 even here when you get down to preset slow (and use no-sao), but something like preset fast and tune grain is still both slower and retains less details to slower/tune film with x264.

Personally this is a limitation that isnt that big of deal (just use x264!), but I dont think it's unreasonable that people expect x265 to outperform (or at least match!) it's predecessor for this purpose as well as the other ones were it's already ahead (low bitrate, high res etc).

[Barough]

x265 v2.6+13-6b079854e56e (http://www.mediafire.com/?8alj4y8997ci27j) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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

[x265_Project]

Encoder development is difficult. Like rocket science or maybe even harder. It seems all the low-hanging fruits have been picked...
Of course, it always makes sense to pick the low-hanging fruit first. But don't take the statistics I posted as a sign that there isn't much room for improvement. I just wanted to point out that HEVC is significantly more complex than AVC, so developing an optimal encoder is just a much bigger job.

[LigH]

And I wish your team all the best success. https://cosgan.de/images/smilie/liebe/h053.gif

[mandarinka]

Same here, good luck!

[x265_Project]

Thanks! We really appreciate the contributions and constructive feedback / ideas we get from the community, including Doom9 forum members LigH (Mario) and Ma0 (Mateusz). If you track our developer mailing list you'll see that outside contributions and feedback have been picking up nicely. Thanks to all!

[divxmaster]

Lol, Steven R Savage....
x264 better detail than x265? No way. I'm getting WAY WAY more detail in x265, yet the x265 file is much smaller. Just reencoded voyager s1ep1, x264 is 700mb, x265 is 402mb, with x265 having so much more detail they arent even comparable.

divxmaster.

[LigH]

I guess it's the old debate about "SAO vs. grain retention": yes, HEVC can look a lot smoother with one set of options...

[Cole_Turner]

@divxmaster

Can you tell me what is your CLI options to get best results?
To 1080p and 2160p.

[Stephen R. Savage]

Lol, Steven R Savage....
x264 better detail than x265? No way. I'm getting WAY WAY more detail in x265, yet the x265 file is much smaller. Just reencoded voyager s1ep1, x264 is 700mb, x265 is 402mb, with x265 having so much more detail they arent even comparable.

divxmaster.
400 MB? Are you kidding me? I compared 1080p x264 at 10 GB/hr to x265 at 10 GB/hr and there's no question. No matter how many bits you put into x265, it always removes details. No problem in x264.

I guess it's the old debate about "SAO vs. grain retention": yes, HEVC can look a lot smoother with one set of options...
Yes, disabling SAO improves the detail retention, but it's clear that x265 was not tuned with this in mind. As soon as you remove SAO, you start encountering all manner of bizarre artifacts ("worms") in flat areas and around edges. This is at any bitrate, including 10+ GB/hr.

[LigH]

I suggest both sides will need to provide samples (preferably public lossless sources, including full command line and used versions) where they can point at and say: "Look, here, this looks {good|bad}".

[Majorlag]

Stephen R. Savage,
I had at one point an issue with x265 10bit hardware acceleration on Nvidia graphics playback that exhibited the same issues of unusual artifacts. Have you tried turning off HEVC hardware decoding or playing on AMD or Intel hardware to see if that resolves issues?

You could also use avisynth to export the same frame from source and encoding file therby bypassing Hardware acceleration to compare in your chose flavor of image viewer.

~Mjoarlag

[divxmaster]

400 MB? Are you kidding me? I compared 1080p x264 at 10 GB/hr to x265 at 10 GB/hr and there's no question. No matter how many bits you put into x265, it always removes details. No problem in x264.

10GB/hr?? Are you kidding me? Theres no point in even using that high a bit rate. Unless you are a publishing house/tv studio.
Try 1GB/hr. That produced x265 1080p that you cannot distinguish from the 20gb/hr original at a sane viewing distance. normally 2-3m. I test comparisons on 48" tv and 102" projector at these distances.

[Stephen R. Savage]

10GB/hr?? Are you kidding me? Theres no point in even using that high a bit rate. Unless you are a publishing house/tv studio.
Try 1GB/hr. That produced x265 1080p that you cannot distinguish from the 20gb/hr original at a sane viewing distance. normally 2-3m. I test comparisons on 48" tv and 102" projector at these distances.

Sorry, but if the quality is bad at 10 GB/hr, it can't be better at 1 GB/hr.

Stephen R. Savage,
I had at one point an issue with x265 10bit hardware acceleration on Nvidia graphics playback that exhibited the same issues of unusual artifacts. Have you tried turning off HEVC hardware decoding or playing on AMD or Intel hardware to see if that resolves issues?

You could also use avisynth to export the same frame from source and encoding file therby bypassing Hardware acceleration to compare in your chose flavor of image viewer.

~Mjoarlag

I always use software decoders for this exact reason.

[WhatZit]

No matter how many bits you put into x265, it always removes details.

I recently spent two weeks explaining to everyone how one single option utterly neutralises this default behavior. You must have missed it.

As soon as you remove SAO, you start encountering all manner of bizarre artifacts ("worms") in flat areas and around edges.

I haven't had that problem since x265 v2.0, and I routinely encode at 30-50% of "transparent" (using naughty flick-screen frame comparisons) x264 bitrates.

That you can't get x265 to perform superbly is YOUR fault, not Multicoreware's.

[FranceBB]

400 MB? Are you kidding me? I No matter how many bits you put into x265, it always removes details.

We have been airing in UHD 2160p HEVC 10bit at 25 Mbit/s for a while now and it looks very good, actually. Quality wise, in broadcast we just moved from an XDCAM 50 Mbit/s master and 6 Mbit/s MPEG-2 1080i 8bit encode to an XAVC 500 Mbit/s master and an HEVC 25 Mbit/s 2160p 10bit encode. HEVC does a really good job and delivers a good quality file to our end users.

[Stephen R. Savage]

I recently spent two weeks explaining to everyone how one single option utterly neutralises this default behavior. You must have missed it.



I haven't had that problem since x265 v2.0, and I routinely encode at 30-50% of "transparent" (using naughty flick-screen frame comparisons) x264 bitrates.

That you can't get x265 to perform superbly is YOUR fault, not Multicoreware's.

I am afraid that you must be either blind or misinformed. With 2.6 and even the latest hg version, it is still impossible to disable SAO and avoid massive artifacts. In fact, since they changed the lambda tables a few versions ago, it has regressed further.

We have been airing in UHD 2160p HEVC 10bit at 25 Mbit/s for a while now and it looks very good, actually. Quality wise, in broadcast we just moved from an XDCAM 50 Mbit/s master and 6 Mbit/s MPEG-2 1080i 8bit encode to an XAVC 500 Mbit/s master and an HEVC 25 Mbit/s 2160p 10bit encode. HEVC does a really good job and delivers a good quality file to our end users.

I could not care less about your "end users." x265 does not deliver good quality for me. It does not outperform x264, and even introduces many artifacts and detail losses not present in the "previous generation" codec.

[burfadel]

I don't see how you could be having so many issues with it. Have you eliminated other possibilities like the video decoder? In any case, if you don't like it don't use it! Constructive criticism with examples would help. Upload a small troublesome clip, take a screenshot of frames with issues, and then they could maybe recreate the issue and work on it. B!tch!ng helps no one.

[WhatZit]

I am afraid that you must be either blind or misinformed. With 2.6 and even the latest hg version, it is still impossible to disable SAO

SAO?! You think I was talking about SAO?

"Misinformed"... hahah, pot meet kettle.

In fact, since they changed the lambda tables a few versions ago, it has regressed further.

Sure, I had to extensively test & retune for the new tables, but it wasn't hard, just very time consuming (involving hundreds of frame comparisons).

After that, it was back to transparent x265 encoding at bitrates that would leave x264 exploding into lego blocks.

So, if you love x264 so much, then keep using it! But don't come here poking your neanderthal spear at those who've evolved beyond it.

[LigH]

Still no shared samples to compare objectively?

[jd17]

I recently spent two weeks explaining to everyone how one single option utterly neutralises this default behavior. You must have missed it.

I must have missed that too.
Would you be so kind as to enlighten me?

I am not unhappy with the performance of x265, a combination of 10bit, CRF17, no-sao and preset slow looks transparent to me.

However, I am very interested in the option you are talking about and I would like to do some comparisons myself, so please share! :)


Edit:
I searched for even older posts from you than I did before and stumbled over this:
https://forum.doom9.org/showthread.php?p=1800261#post1800261

Is that what you are talking about? Using --tune grain?

If that is the case, I agree that --tune grain can work wonders, I used to encode with that option too.
However, while I am convinced of the --tune grain results when using --preset medium, I found that --tune grain added to --preset slow (or slower presets than slow) does too much.
This may sound weird, but it looked to me as if it then introduces noise/grain where there is none in the source.
I assume that the high --psy-rdoq (10) might be the root cause for what I consider artificial noise/grain.

[WhatZit]

I found that --tune grain added to --preset slow (or slower presets than slow) does too much.
This may sound weird, but it looked to me as if it then introduces noise/grain where there is none in the source.

You're not imagining any of it, JD. :)

The slower the preset, the more "overboard" the detail retention gets (ridiculously so at veryslow). Also, the new lambda tables seem to have made the phantom grain effect more pronounced.

That's why you always need to think in opposites with --tune grain: go faster with lower bitrates, and let the special algorithms for stable quantization & high-frequency bias do the work of traditional slower presets and higher bitrates.


Still no shared samples to compare objectively?

Having to use 3rd party sites to host these dissuades a lot of people, I reckon. Including myself, who's already wasted too much time on frame-grab comparisons that are now auto-deleted.

Now, if doom9 had it's own flick-tool feature...

[jd17]

You're not imagining any of it, JD. :)

The slower the preset, the more "overboard" the detail retention gets (ridiculously so at veryslow). Also, the new lambda tables seem to have made the phantom grain effect more pronounced.

That's why you always need to think in opposites with --tune grain: go faster with lower bitrates, and let the special algorithms for stable quantization & high-frequency bias do the work of traditional slower presets and higher bitrates.

That is interesting, I'm glad that you share my assessment. :)

After my trials, I pretty much concluded that I get very comparable results by either going medium/grain or slow/no-sao, both with CRF17.
While the medium/grain version is quicker to encode, the resulting bitrate is considerably higher.
This is why I use the before mentioned slow/no-sao now.


I have not seen the negative effects of --no-sao Stephen R. Savage refers to. Not even at close inspection during my trials.

Accordingly, I too would like to see a sample demonstrating the phenomenon.

[Barough]

x265 v2.6+14-f09f3b4a2115 (http://www.mediafire.com/?vy3jcbv8tzatyxq) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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

[LigH]

x265 2.6+14-f09f3b4a2115 (https://www.mediafire.com/file/fsr6u62dtu88bgf/x265_2.6%2B14-f09f3b4a2115.7z)

New options:

--fullhelp Show all options and exit
--gop-lookahead <integer> Extends gop boundary if a scenecut is found within this from keyint boundary. Default 0
_

I wonder ... how much GOP lookahead would you consider sensible, in relation to min and max keyframe intervals.

[divxmaster]

I don't see how you could be having so many issues with it. Have you eliminated other possibilities like the video decoder? In any case, if you don't like it don't use it! Constructive criticism with examples would help. Upload a small troublesome clip, take a screenshot of frames with issues, and then they could maybe recreate the issue and work on it. B!tch!ng helps no one.

Thanks Burfadel, I was about to post exactly that, but you beat me to it!

And just to confirm, I have calculated (roughly) 10GB/hr is a bit rate of 22.755mbps.... bad output of x265 1080p at 22.755mbps??? I dont think so.

[Weyoun]

I could not care less about your "end users." x265 does not deliver good quality for me.

I am so glad x265 was not created for you.

[birdie]

Sorry, but if the quality is bad at 10 GB/hr, it can't be better at 1 GB/hr.

This topic was created to discuss x265 development.

If you have issues with the codec, please create a new thread and post your sources and encoding settings, so that we could all decide whether what you're trying to convey is true or not, and if there's something we or you have overlooked.

As mentioned earlier, 10GB/hr translates to 10*1024*1024*1024*8/3600/1024/1024 = 22.755Mb/sec which will be 100% transparent (unless you want a lossless compression) using x264.

[divxmaster]

As mentioned earlier, 10GB/hr translates to 10*1024*1024*1024*8/3600/1024/1024 = 22.755Mb/sec which will be 100% transparent (unless you want a lossless compression) using x264.

Haha, I think you meant "100% transparent (unless you want a lossless compression) using x265" ??

[Boulder]

Out of interest, there was earlier some discussion that --qcomp 0.8 would be better than the default 0.6. Has anyone made any recent tests, especially with --tune grain?

[birdie]

Haha, I think you meant "100% transparent (unless you want a lossless compression) using x265" ??

I did mean x264.

[divxmaster]

I did mean x264.

Oh Ok,
Well 22.755Mbps will be transparent in x264 or x265. Thats a higher bitrate than some bluray masters.

Cheers,
Divxmaster

[Barough]

x265 v2.6+15-57eaef9abfd8 (http://www.mediafire.com/?s841p3e947h8i76) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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

[Majorlag]

Out of interest, there was earlier some discussion that --qcomp 0.8 would be better than the default 0.6. Has anyone made any recent tests, especially with --tune grain?

I found --qcomp 0.8 to work perfectly for my needs, but I use --rc-grain since I don't want to change my --qpstep to 1. I use the higher qcomp since x264 days. I lean towards less fluctuation in quantizer compression so I change a few of the settings to reflect that, such as"--qpmin 4 --qpmax 44 --qpstep 4 --qcomp 0.8 --rc-lookahead 30 --rc-grain"

[Motenai Yoda]

I found a discrepancy between documentation and source about qg-size, docs sayz [maxCUSize], source 32, maybe it's related to f0b9b9e?
also dc5d584 set it to 32 for "commandlines with medium and all slower presets", but as fast and faster doesn't change it againg, actually it's 32 for all presets

[Barough]

x265 v2.6+17-7a6d244c922b (http://www.mediafire.com/file/j95clsuoxxlf8k6/) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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

[pingfr]

Merry Christmas to all! :cool:

[dipje]

This might have been posted, but if I wanted to re-encode some youtube-HDR files to make them compatible with my set, how do I translate the HDR metadata?
ffprobe gives this:
Content Light Level Metadata, MaxCLL=2000, MaxFALL=300
Mastering Display Metadata, has_primaries:1 has_luminance:1 r(0.6800,0.3200) g(0.2649,0.6900) b(0.1500 0.0600) wp(0.3127, 0.3290) min_luminance=0.009900,max_luminance=2000.000000
and this:
Stream #0:0(eng): Video: vp9 (Profile 2), yuv420p10le(tv, bt709/bt2020/smpte2084), 3840x2160, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn, 1k tbc (default)

am I correct that x265 needs:
--master-display "G(2649,6900)B(1500,0600)R(6800,3200)WP(3127,3290)L(99,20000000)" --max-cll 2000,300 --range limited --colorprim bt2020 --colormatrix bt709 --transfer smpte2084

Specially the order for --max-cll which is listed as cll,fall in the help text, and the master-display string where I did every ffprobe value * 10000, is that correct?

[Barough]

x265 v2.6+22-ff02513b92c0 (http://www.mediafire.com/file/8zg33ajm1u4eu9z/) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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