x265 HEVC Encoder

[Dclose]

I've been running tests for days and for my current test sample of 5000 Kbps live-action 720p video, I agree with various proposed settings such as CTU 32. Other standard disabled things are SAO, intra-smoothing, etc. Early Skip really hurts quality imo, but maybe it will do better with higher bitrate, less action, or with more extreme settings I'm just starting to test such as RD5 with --subme 7.

Anyway, it's hard to do a search on this because I'm not sure what I'm looking for. x265 has always looked 2-D and flat and less "alive" to me than x264, and I thought it was a lack of grain and too much motion blur thing. I've been trying to tune those out of x265, but...

I think the 2-D thing is because x265 limits the lighting or color range. With x264, there seems to be more dynamic lighting. x265 seems to tone down bright light shining on someone's face. Or like someone having highlights in their hair. Or how the sun shines on a green pine tree and the edges or certain other parts of the tree have a shine. x265 seems to dull the lighting and or color.

Is there a known correction for what I'm talking about?

[LigH]

Please search for "sao" (smooth all objects) and see if it is related...

[sneaker_ger]

Originally Posted by Dclose

I think the 2-D thing is because x265 limits the lighting or color range. With x264, there seems to be more dynamic lighting. x265 seems to tone down bright light shining on someone's face. Or like someone having highlights in their hair. Or how the sun shines on a green pine tree and the edges or certain other parts of the tree have a shine. x265 seems to dull the lighting and or color.

Is there a known correction for what I'm talking about?

Post a sample with screenshots that show what you are talking about and your x264/x265 command-lines. Most often this is a user error resulting in wrong color conversion between YUV and RGB (BT.601 vs BT.709) or range (limited/full).

[brumsky]

Originally Posted by Jawed

So brumsky, since your encode parameters are so slow, perhaps you can use --rd 6 to replace other of your parameters that are "slow".

Perhaps you can get back to approximately the same quality as your default parameters (without --rd 6) and maybe gain performance

The parameters (including --rd 6) you provided are very impressive on that clip - I'd say close to, if not as good as, crf 18 slow (and about 1/4 the bitrate).

That's really going some. But the nature of the clip could be biasing such an assessment. In my experience useful conclusions come from many test clips (and single frames are ignored)...

I wonder if the x265 project will, at some point, completely overhaul their presets. It would appear that they've been chosen too early in the development cycle.

One of the things that concerns me with the presets is that higher quality presets often lead to increased bitrate. This is the opposite of what's seen with x264. To me that indicates the presets are pretty immature.

I know the test was limited and a single clip and frame is not indicative of every possible outcome. It was a simple test to verify your statement about RD 5/6, which I ended up agreeing with.

I also wanted to get a better idea of the performance impact vs quality of a variety of settings.

I've seen the opposite with the preset, generally they provide lower bitrates. My test clip isn't a good example because it is high motion.

[Dclose]

Originally Posted by LigH

Please search for "sao" (smooth all objects) and see if it is related...

lol, x265 is frustrating compared to x264. I've ran 100+ test samples the past few days, and taking some screenshots now, I guess it is a grain/blur thing not a color or lighting thing. Well, I suppose those are related since blurring diffuses highlights/color along with resolution.

I guess it's mostly during movement that x265 looks 2-D and dull, which is practically all the time in modern media with either a person moving or the camera moving.

Early on, I tried the Grain setting, but it was excessive so I didn't think about it anymore. Looking at it again, objects do have more "energy" on screen and look more alive, and I now see Grain's settings disable SAO.

I tried x265 a year ago but gave up on it quickly due to so much blur even at higher resolution/bitrate. Trying it again to see how small in file size a video could get, it is impressive over x264 at very low bitrate, but it still was so blurry at higher bitrates until I happened to turn off SAO. And then reading mentions of SAO in this thread was evidence I wasn't just seeing things and that maybe x265 has more hidden potential.

Very Slow with my test video encodes at 2fps or less. I don't know what Very Slow is trying to do to the video since the settings I'm gravitating towards from my tests look as good or better to me and encode at least 2+ times as fast. My settings are similar to the ones mentioned in the last 20 or so pages that other people are mostly agreeing on. Still working on fine-tuning, of course.

[Dclose]

May as well post some screenshots. Maybe other people can see things that make the x265 presets look better. The modded setting below has a lot of room left since it encodes much faster than x265 preset Very Slow. I only used that for this since I already had it saved as a profile and it's a decent baseline.
A thing not seen well from screenshots is the blur during motion I mentioned. In the scene, she moves her head just a bit, and x265 presets want to blur her hair, making it look clumped up and flat instead of looking 3-D and alive.

original
http://i64.tinypic.com/28jxna9.jpg

x265 Slower
http://oi64.tinypic.com/24pmq7k.jpg

x265 Very Slow
http://oi66.tinypic.com/120iiw1.jpg

x264 Very Slow
http://oi67.tinypic.com/zwxbwz.jpg

x265 modified
http://oi67.tinypic.com/2qxb4lu.jpg

x265 --preset slow --input - --y4m --ctu 32 --qg-size 16 --merange 25 --no-strong-intra-smoothing --crf 23.50 --qpfile 
GENERATED_QP_FILE --psy-rd 1.00 --rdoq-level 1 --psy-rdoq 2.00 --deblock=-2:-2 --no-sao --range full --colormatrix bt709 
--ipratio 1.38 --pbratio 1.28

[Jamaika]

It is difficult to say anything, because you added the sceenshot aren't identical. Lacking the "aq-mode 3". Lacking the "zone". Otherwise, the beginning and the end film will be of poor quality (~500 frames).

[Dclose]

Originally Posted by Jamaika

It is difficult to say anything, because you added the sceenshot aren't identical. Lacking the "aq-mode 3". Lacking the "zone". Otherwise, the beginning and the end film will be of poor quality (~500 frames).

I didn't notice half of the shots were slightly different since they all read the same frame number in PotPlayer when I saved the screenshot. It looks like the first two x265 are the same, and the x264 and last x265 are the same. Even still, there's some obvious differences there.

I copied and pasted what Hybrid showed in its configuration area. Lacking the "aq-mode 3?" They're the preset settings except for the last one, which is a modded Slow and so uses the same as umodded Slow.

It's not meant to be a big technical comparison. Just that I was taking screenshots so figured I'd post some. And to show that I think the presets are doing x265 a disservice in showing its potential.

[Barough]

x265-2.1+12-11bfa0ae9710 (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Jawed]

Originally Posted by x265_Project

We take a look at this every so often. We've updated our presets several times already, and we'll certainly do it again as we make improvements to different algorithms, or develop new algorithms. We don't want to do it too often, as we think people like to develop a favorite recipe, and when we change presets it changes things for everyone using x265 (except those who specify every option manually).

Thanks for explanation. I'm glad to hear to hear that the presets are not sacrosanct.

[benwaggoner]

Originally Posted by Jawed

Thanks for explanation. I'm glad to hear to hear that the presets are not sacrosanct.

Are any ?

Certainly the x265 presets have had many years less tuning than x264's, and don't include --tune animation or film. Plus HEVC is a much more complex codec than H.264, so there are a lot more axes for tuning.

Also (and fortunately) x265 is in MUCH more active development than x264. This also means that settings that worked well 6-12 months ago might now work as well now. In a lot of cases, special settings for special content are less necessary as x265 does a better job adapting to the content by default (for example --rskip is way better now, so --no-rskip isn't nearly as necessary). Also, the quality/perf tradeoff of different parameters have changed a lot, and we have new parameters like --limit-refs and --limit-modes that allow us to use higher --refs and advanced features like --amp and --rect with much lower CPU cost.

And for really grainy/noisy content, we have --tune-grain with its whole grain-tuned rate control mode.

Exciting stuff is coming (via the changelog), like support for non-IDR I-frames mid-GOP.

Originally Posted by benwaggoner

Are any ?

Certainly the x265 presets have had many years less tuning than x264's, and don't include --tune animation or film. Plus HEVC is a much more complex codec than H.264, so there are a lot more axes for tuning.

Also (and fortunately) x265 is in MUCH more active development than x264. This also means that settings that worked well 6-12 months ago might now work as well now. In a lot of cases, special settings for special content are less necessary as x265 does a better job adapting to the content by default (for example --rskip is way better now, so --no-rskip isn't nearly as necessary). Also, the quality/perf tradeoff of different parameters have changed a lot, and we have new parameters like --limit-refs and --limit-modes that allow us to use higher --refs and advanced features like --amp and --rect with much lower CPU cost.

And for really grainy/noisy content, we have --tune-grain with its whole grain-tuned rate control mode.

Exciting stuff is coming (via the changelog), like support for non-IDR I-frames mid-GOP.

Thanks Ben. To clarify a couple of points, we last updated our presets in December, and we incorporated limit-refs and limit-modes into the presets at that time.

Support for scene change detection within fixed GOPs is coming, but this will be on by default for all presets.

Right now we're looking at how presets might be optimized for different picture sizes (certain settings that work well for 4K might not be as optimal for 480P and below).

[eclipse98]

Hi All,

Suppose I encode (x265) at CR26 and get a 5mbps bit rate. Then I encode at 3 pass with 5mbps target rate. Will there be any difference in quality ? Logic says it shouldn't be, just wanted to confirm with experts !

Thanks for your help.

Cheers !

[microchip8]

Originally Posted by eclipse98

Hi All,

Suppose I encode (x265) at CR26 and get a 5mbps bit rate. Then I encode at 3 pass with 5mbps target rate. Will there be any difference in quality ? Logic says it shouldn't be, just wanted to confirm with experts !

Thanks for your help.

Cheers !

there will be small, mostly unnoticeable quality difference, due to difference in distribution of bits. Also, 3-pass will gain you no more quality than 2-pass, and is mostly used when 2-pass misses the target file size, which can happen only rarely

Rule of thumb is: if you aim for specific quality, use CRF. If you aim for a specific target file size, use 2-pass

[eclipse98]

Originally Posted by froggy1

there will be small, mostly unnoticeable quality difference, due to difference in distribution of bits. Also, 3-pass will gain you no more quality than 2-pass, and is mostly used when 2-pass misses the target file size, which can happen only rarely

Rule of thumb is: if you aim for specific quality, use CRF. If you aim for a specific target file size, use 2-pass

Thanks, just what I thought, appreciate your help !

[cojj]

Originally Posted by x265_Project

Thanks Ben. To clarify a couple of points, we last updated our presets in December, and we incorporated limit-refs and limit-modes into the presets at that time.

Support for scene change detection within fixed GOPs is coming, but this will be on by default for all presets.

Right now we're looking at how presets might be optimized for different picture sizes (certain settings that work well for 4K might not be as optimal for 480P and below).

First of all, thank you for such a great open-source project.

Now my question: Persoanlly, do you think this change is worth waiting for? I've starting re-encoding all my videos but I could wait bit longer if its worth.

Originally Posted by cojj

First of all, thank you for such a great open-source project.

Now my question: Persoanlly, do you think this change is worth waiting for? I've starting re-encoding all my videos but I could wait bit longer if its worth.

You're welcome. You should not be using fixed GOP length (keyint = min-keyint). If you use our default presets and you don't mess with key interval settings, or turn off scene detection, x265 will create a new GOP at the start of each scene. This will give you the best encoding quality.

Fixed GOP length is never desirable from a quality (compression efficiency) standpoint. Unfortunately, for some scenarios, the system designers chose to use a fixed GOP length for convenience, to simplify streaming or broadcasting. Using variable GOP length for video means that you need to segment audio and metadata into the same varying chunk sizes, which makes the broadcasting or streaming server/client design more complex.

[benwaggoner]

Originally Posted by froggy1

there will be small, mostly unnoticeable quality difference, due to difference in distribution of bits. Also, 3-pass will gain you no more quality than 2-pass, and is mostly used when 2-pass misses the target file size, which can happen only rarely.

I saw some rare cases where a 3rd pass actually made things slightly better at a few points where the encode was VBV constrained, mainly in cases where a fast first pass was used, or when the VBV was really constrained. I think those were only in 2015, though.

Rule of thumb is: if you aim for specific quality, use CRF. If you aim for a specific target file size, use 2-pass

Quite right!

[mzso]

Hi!

Is aliasing a significant issue for x265 (our HEVC)? I came across two separate x265 encoded files of the same thing. The higher bitrate one had some pretty bad aliasing where there were fine patterns. The lower bitrate one was even worse with with more stuff aliased an aliasing being more pronounced.

[microchip8]

Originally Posted by mzso

Hi!

Is aliasing a significant issue for x265 (our HEVC)? I came across two separate x265 encoded files of the same thing. The higher bitrate one had some pretty bad aliasing where there were fine patterns. The lower bitrate one was even worse with with more stuff aliased an aliasing being more pronounced.

I haven't read of any... care to provide a sample of the issue?