Should I use --no-sao when encoding with HEVC?.

[Felow]

obsolete

[Selur]

nowadays using sao should be fine with x265 so I would not disable it (assuming that Handbrake uses x265 for H.265 encoding)

[Felow]

nowadays using sao should be fine with x265 so I would not disable it (assuming that Handbrake uses x265 for H.265 encoding)

So it doesn't affect skin textures right?.

[Selur]

It should not unless the bitrate is to low to show the textures properly.

[Felow]

It should not unless the bitrate is to low to show the textures properly.

ok what about "strong-intra-smoothing=0:rect=0" what does it do? it was activated on the default preset.

[Selur]

see: https://x265.readthedocs.io/en/latest/cli.html
strong-intra-smoothing=0:rect=0 means both options are disabled

[gdgsdg123]

nowadays using sao should be fine with x265 so I would not disable it (assuming that Handbrake uses x265 for H.265 encoding)

In my testing around 2019, it failed with high bit rate applications... (unnecessary blurriness)

[Selur]

@gdgsdg123:
If a features caused 'unnecessary blurriness' on an old version it does not really say much, especially since:
a. it's totally unclear what qualifies as 'high bit rate applications' (resolution, settings, content are all unknown)
b. not knowing what version this was (a lot happened during 2019, including the introduction of sliced based sao; different settings might change things)

[poisondeathray]

Yes it still blurs in 2020. But not as bad as before. Personally I still don't like it

To disable all , it's --selective-sao 0 --no-sao now.

SAO tends to blur smaller higher frequency details like fine hairs, skin pores, even at typical bitrate ranges. The trade off is slightly more artifacts. But I prefer details > smooth . Some people prefer smooth, that's ok too . You will typically see the blurring for 10bit x265 CRF 23-24 slow as per the OP's scenario , at least on still frames for typical live action sources. In motion, depends on the person.

But for low to very low bitrates, or "smooth" content like simple cartoons it can be beneficial (but so can a denoiser)

Those are just generalizations; it's always better to do some tests and check for yourself for your specific sources


(Handbrake still does not have a 10bit pipeline in 2020. Don't use it if you have a true 10bit source.)

[Felow]

Yes it still blurs in 2020. But not as bad as before. Personally I still don't like it

To disable all , it's --selective-sao 0 --no-sao now.

SAO tends to blur smaller higher frequency details like fine hairs, skin pores, even at typical bitrate ranges. The trade off is slightly more artifacts. But I prefer details > smooth . Some people prefer smooth, that's ok too . You will typically see the blurring for 10bit x265 CRF 23-24 slow as per the OP's scenario , at least on still frames for typical live action sources. In motion, depends on the person.

But for low to very low bitrates, or "smooth" content like simple cartoons it can be beneficial (but so can a denoiser)

Those are just generalizations; it's always better to do some tests and check for yourself for your specific sources


(Handbrake still does not have a 10bit pipeline in 2020. Don't use it if you have a true 10bit source.)

I switched to Vidcoder since handbrake doesn't allow up scaling I tried no Sao vs Sao on one video and I couldn't see any difference (crf 23 slow) to be honest.. I'll have to do more test.
Thanks.

[poisondeathray]

I switched to Vidcoder since handbrake doesn't allow up scaling I tried no Sao vs Sao on one video and I couldn't see any difference (crf 23 slow) to be honest.. I'll have to do more test.
Thanks.

Did your source have fine details to begin with ? The difference will be more noticable on higher quality sources with higher frequency, fine details

[gdgsdg123]

it's totally unclear what qualifies as 'high bit rate applications' (resolution, settings, content are all unknown)

For sample previews, check my YouTube channel. (I keep higher quality versions locally)

After various testing I choose to stick with x264 as x265 actually yielded worse result (both efficiency and quality wise) for my usage. (maybe because I don't know how to use x265... more likely because x264 works too good for me)

[Selur]

Looked channel, no details about resolution and settings.
-> it's probably best Felow tries with his content and decides for himself.

[gdgsdg123]

...no details about resolution and settings.

What I was using (for quality export):

ffmpeg -i "%INPUT%" -c:a aac -b:a 320k -c:v libx264 -r 30 -preset placebo -tune film -crf 19 -x264-params "level=5.1:keyint=150:qcomp=0.75" -pix_fmt yuv420p -sws_flags spline+accurate_rnd+full_chroma_int -vsync vfr -color_range 1 -colorspace 5 -color_primaries 5 -color_trc 6 "out.mp4"

%INPUT%: RGB24, 30 FPS VFR

Input resolution: 5120x1440, 2560x1440, 1920x1080



Note: I use different commands for YouTube uploading and quality export.

[Felow]

I have made a more meticulous test and the difference is negligible so I'll just stick with SAO enabled here is the comparison: https://imgur.com/a/sajWHXh

[poisondeathray]

I have made a more meticulous test and the difference is negligible so I'll just stick with SAO enabled here is the comparison: https://imgur.com/a/sajWHXh

That would be acceptable for me too.

But it's a lower quality 5Mb/s 1920x1080 source. There are already compression and banding artifacts; high frequency details are already missing in the source (essentially it's already been pre blurred or lowpassed, so there is not much to lose)

When people complain, it's usually a higher quality source that loses significant fine details after encoding