x265 HEVC Encoder

[Boulder]

Originally Posted by Greenhorn

the comparatively enormous number of 64x64 blocks with rskip 2 to me, though-- from a total of 6.79% (normal + rect) to 65.33% (normal + rect)!

That puzzled me as well. Disabling early exits seems to favour bigger CUs in this case. Maybe it's something related to this test clip being HDR, so the image is quite flat compared to the graded result (edit: correctly displayed HDR) on the TV. Plenty of action, but plenty of plain white looking areas when I play the result back on my SDR display.

I checked a couple of frames where I found some onion artifacting -- happened to be next to edges -- and rskip 2 did fix them. So it's definitely helpful.

Is there any way to get CU-type in a more readable format than setting csv-log-level=1 and viewing the generated file in an Excel/CSV viewer? Would greatly help with some comparison's I've been doing for myself.

I'm afraid not. That is something I'd like to see as well, averages like I put there and also information regarding refs. All those you can see with x264 so I don't know why the statistics were not considered for x265. If I was a coder, I would definitely submit a patch for it.

[K.i.N.G]

Thanks for all the suggestions guys!
I will try them out as soon as I can.

Originally Posted by Boulder

I've never understood why max-merge gets increased in the slower and supposedly higher quality profiles. I always have it at '2'.

Funny you should mention this, as i always wondered why I seem to get less of these 'artifacts' when encoding at lower presets. Will have a look at max-merge.

Originally Posted by Boulder

I checked a couple of frames where I found some onion artifacting -- happened to be next to edges -- and rskip 2 did fix them. So it's definitely helpful.

Will try this too.

[vpupkind]

Originally Posted by Greenhorn

the comparatively enormous number of 64x64 blocks with rskip 2 to me, though-- from a total of 6.79% (normal + rect) to 65.33% (normal + rect)!

Do you see the difference in file size or average quantizer as well?

[benwaggoner]

Originally Posted by vpupkind

Do you see the difference in file size or average quantizer as well?

Or visually?

[Greenhorn]

I just meant to say it surprised me, but forgot a word. For most of the stuff I've tried it one (just my personal collection, nothing terribly interesting) rskip 2 produces slightly larger but very similar looking encodes, so realizing that it was making such different files on a basic level was a jolt.

IDK how it behaves when you have studio-grade clean/detailed sources, but for me rskip mode 2 needs an annoying amount of tuning, because with the default edge threshold some clips are a little better than with mode 2, while others just fall apart entirely.

[benwaggoner]

Originally Posted by Greenhorn

I just meant to say it surprised me, but forgot a word. For most of the stuff I've tried it one (just my personal collection, nothing terribly interesting) rskip 2 produces slightly larger but very similar looking encodes, so realizing that it was making such different files on a basic level was a jolt.

IDK how it behaves when you have studio-grade clean/detailed sources, but for me rskip mode 2 needs an annoying amount of tuning, because with the default edge threshold some clips are a little better than with mode 2, while others just fall apart entirely.

You can try with the source from my encoding challenge: https://forum.doom9.org/showthread.php?t=175776.

It'd be good to try with some files that used to have artifacts with rskip and see if and how they are improved with --rskip 2.

[charliebaby]

Patman Thank you the Build x265 :-)

[stax76]

Do following x265 crf values still make sense?

--crf 10 Super High
--crf 12 Very High
--crf 14 Higher
--crf 16 High
--crf 18 Medium
--crf 20 Low
--crf 22 Lower
--crf 24 Very Low
--crf 26 Super Low

I think the values were established many years ago when 4K was not popular.

There is a request to increase the value by 4:

--crf 14 Super High
--crf 16 Very High
--crf 18 Higher
--crf 20 High
--crf 22 Medium
--crf 24 Low
--crf 26 Lower
--crf 28 Very Low
--crf 30 Super Low

It would be identical to the x264 values then which also start at 14 and end at 30.

Change or not?

[K.i.N.G]

Sorry for the late reply but our remote desktop software crashed and didn't have access to the servers...

After a quick test adding these parameters to the encode improved the quality in parts with motion "--rskip 2 --max-merge 2 --rd-refine" with about the same bitrate.
The artifacts are still there but far less (and much less perceptible when playing the video).
I'll see if i can experiment some more with the settings later, maybe it can be improved even more.

Thanks to everyone for the usefull input and suggestions!

[K.i.N.G]

Originally Posted by stax76

Do following x265 crf values still make sense?

--crf 10 Super High
--crf 12 Very High
--crf 14 Higher
--crf 16 High
--crf 18 Medium
--crf 20 Low
--crf 22 Lower
--crf 24 Very Low
--crf 26 Super Low

I think the values were established many years ago when 4K was not popular.

There is a request to increase the value by 4:

--crf 14 Super High
--crf 16 Very High
--crf 18 Higher
--crf 20 High
--crf 22 Medium
--crf 24 Low
--crf 26 Lower
--crf 28 Very Low
--crf 30 Super Low

It would be identical to the x264 values then which also start at 14 and end at 30.

Change or not?

I wouldn't change them. Its just going to add more confusion than it will fix when using presets with different versions.
And then there's the fact it also depends on the type of source. HDR needing a lower CRF than SDR etc.

I dont think 'normalizing' the CRF with x264 is that important if it is even possible... since result will always be different depending on the footage imho.

[benwaggoner]

Yeah. CRF fundamentally maps to QP, and while AVC and HEVC have similar QP scales, HEVC can do more with higher QP than AVC can. Any QP delta between x264 and x265 is going to vary based on profile and content. That said, I think the average CRF delta for the same subjective quality would be less than 4. That said, CRF 16 IS generally very high quality with x265. 10-12 are almost always psychovisually indistinguishable from 14 except for some heavy noise edge cases.

[Boulder]

At CRF 10-14, I wouldn't be surprised if the encode sometimes ended up at a higher average bitrate than the source itself

[Forteen88]

Originally Posted by Boulder

At CRF 10-14, I wouldn't be surprised if the encode sometimes ended up at a higher average bitrate than the source itself

I hear that for HDR UHD video, CRF 14 isn't very extreme.

[stax76]

A test encode I did come out like this:


Source:

HEVC, Main 10@L5.1@High, 3840x2160, 23.976 FPS, 57.5 Mbps


Settings:

x265.exe --crf 14 --preset slower --output-depth 10


Result:

HEVC, Main 10@L5@Main, 3840x2160, 23.976 FPS, 32.9 Mbps


It was a sample from the movie Snow White and the Huntsman, had some noise, not particular much.


It would also be possible to add additional items, very, super, extreme, ludicrous...


My sample with the highest bitrate is:

HEVC, Main 10@L5.1@High, 3840x2160, 23.976 FPS, 70.0 Mb/s


Some old boring movie called Crash.

[Boulder]

Originally Posted by Forteen88

I hear that for HDR UHD video, CRF 14 isn't very extreme.

True, HDR requires a significantly lower CRF to achieve visual transparency.

[benwaggoner]

Originally Posted by Boulder

True, HDR requires a significantly lower CRF to achieve visual transparency.

Having a perceptually uniform EOTF helps a lot, as QPs don't need to be lowered for dark regions. In SDR it's easy to seams between Y'=16 and Y'=17.

HDR always being 10-bit also helps.

Ballpark, HDR needs ~20% fewer bits than 8-bit SDR to get to a similar subjective quality.

[Blue_MiSfit]

Worth mentioning, x265 does require special tuning for good quality HDR.

The default hdr-opt is pretty good for PQ YCbCr (HDR10), but when encoding for Dolby Vision Profile 5 using PQ IPT (quite similar to ICtCp) masquerading as YCbCr, some additional tuning is needed to mitigate banding artifacts, even at high bitrates. I've seen some proprietary patches to x265 to improve performance here. Hopefully MCW makes something like this in mainline x265

[Boulder]

Originally Posted by benwaggoner

Having a perceptually uniform EOTF helps a lot, as QPs don't need to be lowered for dark regions. In SDR it's easy to seams between Y'=16 and Y'=17.

HDR always being 10-bit also helps.

Ballpark, HDR needs ~20% fewer bits than 8-bit SDR to get to a similar subjective quality.

But CRF needs to be adjusted quite heavily. With my SDR settings + hdr-opt + HDR metadata, an encode of a HDR source produces a proportionally much smaller file than a similar one in SDR at CRF 18. With HDR sources, I tend to use CRF 14.

[benwaggoner]

Originally Posted by Blue_MiSfit

Worth mentioning, x265 does require special tuning for good quality HDR.



The default hdr-opt is pretty good for PQ YCbCr (HDR10), but when encoding for Dolby Vision Profile 5 using PQ IPT (quite similar to ICtCp) masquerading as YCbCr, some additional tuning is needed to mitigate banding artifacts, even at high bitrates. I've seen some proprietary patches to x265 to improve performance here. Hopefully MCW makes something like this in mainline x265

There's a whole different optimization flag for doing Profile 5, tuned for Y'CtCp instead of Y'CbCr.

Sent from my SM-T837V using Tapatalk

[Blue_MiSfit]

In mainline x265? Do tell. I've been using a patched 3.0 build for quite awhile.