x265 Sharpness and Detail (Best Settings?)

[Boulder]

Well, why not try cropping and see what happens. Your player will definitely add them back during playback and you'll save a few bits too.

[brad86]

Originally Posted by Boulder

Well, why not try cropping and see what happens. Your player will definitely add them back during playback and you'll save a few bits too.

Same result. It blurs near the top edge.

[Boulder]

Hmm.. some things to test would be changing CTU to 32 (or 16 just for debugging) and cropping the border so that the actual active image area would not share a CTU with the border.

Also make sure that it's not a decoder related thing, because we've seen something similar at the bottom of the frame with Amlogic chips when the vertical resolution is not mod-8.

[brad86]

Sadly, no go with the CTU change. It changes the position of the blur somewhat, but it's still visible and not decreased.

Removing the boarders is something I will always avoid. Not everything plays nicely when you do this. My 2023 Sony TV has very good scaling, but it has to be fed normal resolutions, or it will not scale, and instead defaulting to a simple bilinear method. I want to keep a native 4K resolution.

[Boulder]

Originally Posted by brad86

Removing the boarders is something I will always avoid. Not everything plays nicely when you do this. My 2023 Sony TV has very good scaling, but it has to be fed normal resolutions, or it will not scale, and instead defaulting to a simple bilinear method. I want to keep a native 4K resolution.

That is quite odd behaviour, I have a 2019 Sony (XF9005) and I've not noticed any difference between feeding a 1920x800 or 1920x1080 source to the TV from the media player.

Is there some discussion regarding this somewhere?

[brad86]

Originally Posted by Boulder

That is quite odd behaviour, I have a 2019 Sony (XF9005) and I've not noticed any difference between feeding a 1920x800 or 1920x1080 source to the TV from the media player.

Is there some discussion regarding this somewhere?

Not that I am aware of. I enabled developer option within the android settings and have a resource overlay. MPV would be an easier way to see everything.

I have just switched to Slower preset whilst keeping the parameters I already had for Slow preset. It has absolutely helped removed most of the blocking I was seeing at the edge.

Encoding time has now skyrocketed, as expected. Would love to know which setting within Slower is helping solve it, so I can just use that along with the Slow preset.

[Boulder]

Originally Posted by brad86

Not that I am aware of. I enabled developer option within the android settings and have a resource overlay. MPV would be an easier way to see everything.

I have just switched to Slower preset whilst keeping the parameters I already had for Slow preset. It has absolutely helped removed most of the blocking I was seeing at the edge.

Encoding time has now skyrocketed, as expected. Would love to know which setting within Slower is helping solve it, so I can just use that along with the Slow preset.

My guess is that it's --amp. I almost proposed checking if it's enabled in the encode, but figured that Slow would probably have both --rect and --amp. So that one allows to split the CTU into asymmetric parts which most likely helps there.

[brad86]

Originally Posted by Boulder

My guess is that it's --amp. I almost proposed checking if it's enabled in the encode, but figured that Slow would probably have both --rect and --amp. So that one allows to split the CTU into asymmetric parts which most likely helps there.

Unless I am adding the parameter incorrectly. :amp does not seem to be the fix. Another setting within Slower that is fixing it.

selective-sao=2:no-strong-intra-smoothing:rskip=2:rskip-edge-threshold=3:aq-mode=3:aq-strength=1.3:deblock=-3:-3:amp

[Boulder]

You can see and compare the presets here: https://x265.readthedocs.io/en/master/presets.html.

[brad86]

Originally Posted by Boulder

You can see and compare the presets here: https://x265.readthedocs.io/en/master/presets.html.

That should be very helpful. Thanks

[benwaggoner]

Originally Posted by Boulder

That is quite odd behaviour, I have a 2019 Sony (XF9005) and I've not noticed any difference between feeding a 1920x800 or 1920x1080 source to the TV from the media player.

Is there some discussion regarding this somewhere?

Yeah, also works fine for me on my 2017 and 2023 Sony TVs.

Making sure the Sample Aspect Ratio is set correctly (probably 1:1 in your case) possibly can help.

[brad86]

Happy days. Changing rd=4 to rd=6 has fixed it.

Although, encoding time has doubled. It is what it is, though.

[benwaggoner]

Originally Posted by brad86

Happy days. Changing rd=4 to rd=6 has fixed it.

Although, encoding time has doubled. It is what it is, though.

Huh! I wouldn't have guessed that would be the magic knob.

Anyone have any theories as to why?

[brad86]

I can't figure why the higher RD level fixed the issue. Maybe some other parameters were not active unless RD was above 4 ?

I currently have it on 5, but it does add 2-3 hours to any encode. Finding the specific setting would be good, so I can get back that lower encoding time.

I went through all the preset parameters table, and still couldn't find what does it.

[Boulder]

Originally Posted by brad86

I can't figure why the higher RD level fixed the issue. Maybe some other parameters were not active unless RD was above 4 ?

I currently have it on 5, but it does add 2-3 hours to any encode. Finding the specific setting would be good, so I can get back that lower encoding time.

I went through all the preset parameters table, and still couldn't find what does it.

A higher value just adds more decision-making which naturally means slower encodes. By the way, 5 and 6 are the same.
I don't know if it also affects the decisions made by psychovisual settings (psy-rd, psy-rdoq), but at least it doesn't enable any other settings that you can do manually using parameters.

[benwaggoner]

Originally Posted by Boulder

A higher value just adds more decision-making which naturally means slower encodes. By the way, 5 and 6 are the same.
I don't know if it also affects the decisions made by psychovisual settings (psy-rd, psy-rdoq), but at least it doesn't enable any other settings that you can do manually using parameters.

--rd 6 can change psychovisual aspect for sure. I've seen a number of grainy UHD HDR sources where --rd 4 looked better than --rd 6.

I remember having a good theory about why that was, but I don't remember the theory .

[brad86]

It's a weird one. From the encodes I have been doing, it appears that 1080p videos are perfectly fine with rd 4, but if I do anything 4K with the exact same settings used for 1080, I need to increase rd to 5 or I start to get strange artefacts, and not always what was in my initial post. They seem to vary. A common one is small seems/lines, or the odd block which looks like if compression were to miss a few pixels. This is the case with SDR video, or when passing through HDR data for the encode.

[benwaggoner]

Originally Posted by brad86

It's a weird one. From the encodes I have been doing, it appears that 1080p videos are perfectly fine with rd 4, but if I do anything 4K with the exact same settings used for 1080, I need to increase rd to 5 or I start to get strange artefacts, and not always what was in my initial post. They seem to vary. A common one is small seems/lines, or the odd block which looks like if compression were to miss a few pixels. This is the case with SDR video, or when passing through HDR data for the encode.

Yeah, without much grain rd 6 is better, with a lot of grain rd 4 is better. It's possible a lot of other parameter tuning could make rd 6 more viable with grain, but I've not found a magic formula yet.