2021 Consensus on Sample Adaptive Offset (sao)

[tonemapped]

I've read thousands of posts over hundreds of threads going back to ~2015 and it seems there's a lack of consensus over disabling sao for an encode, with many people saying it produces a 'wax-like' result.

With the relative maturity of x265, what's your opinion and why (for or against)?

[microchip8]

i never use SAO. Blurs too much.

[Boulder]

SAO = Smooth All Objects ;). It's not usable at all so I always disable it.
x265 may be mature, but SAO has had little development apart from the possibility to use it only on certain frame types.

[benwaggoner]

Yeah, SAO in HEVC has a good amount of flexibility with parameters, but x265 only uses a fixed set. And I don't think there is any way to tweak them.

SAO is a big help at lower bits-per-pixel, but there's a crossover point if detail is prioritized over compression efficiency.

[Gravitator]

And the reason for the lack of manual SAO settings was discussed earlier? I thought about it for the first time today :confused:

[benwaggoner]

And the reason for the lack of manual SAO settings was discussed earlier? I thought about it for the first time today :confused:
Five years ago it was on MCW's list of "something we can take a look at eventually" but there was much lower hanging fruit. I don't know that anyone has taken a serious look at it since. Does anyone know if other encoders do anything different or more elaborate with SAO?

I did find this paper proposing one implementation of it: https://ieeexplore.ieee.org/document/7889300

[rwill]

When I checked a couple of years ago the x265 implementation of SAO was broken. When I checked recently with x265 version 3.4 it was still broken. And with broken I mean artifacts broken and not bad subjective quality broken.

[benwaggoner]

When I checked a couple of years ago the x265 implementation of SAO was broken. When I checked recently with x265 version 3.4 it was still broken. And with broken I mean artifacts broken and not bad subjective quality broken.
Do you know of any encoders with superior SAO implementations?

[rwill]

Do you know of any encoders with superior SAO implementations?

Sure.

[FranceBB]

Sure.

Such as...?

[Blue_MiSfit]

I personally leave SAO on unless I'm targeting transparency. The blocking suppression is too good, even if the loss in fine detail in still frame comparison makes it look bad at first glance.

In terms of an ABR ladder that means almost always leaving it on. Maybe the very top rungs get it disabled.

I wonder if Ateme has a better SAO implementation? They have a lot of really sharp folks working on HEVC, AV1, and VVC these days. Maybe Beamr as well? They're both the first names that come to mind for good commercial HEVC encoders. I've not deeply evaluated either :)

[rwill]

I personally leave SAO on unless I'm targeting transparency. The blocking suppression is too good, even if the loss in fine detail in still frame comparison makes it look bad at first glance.

With "blocking suppression", do you mean what you get when you encode something like this:

https://drive.google.com/file/d/1U_lReuKcaFqwJbfI51lredQT1EqMkyY8/view?usp=sharing

With a x265 command line like this:

./x265-10b.exe --input gradient_with_noise_1920x1080_10b.yuv --fps 24000/1001 --input-depth 10 --input-res 1920x1080 --crf 30 --preset veryslow -o sao_failure.265

?

[Blue_MiSfit]

Fascinating! I see the opposite with real world content, typically :)

By blocking suppression I mean that if you compare two low bitrate encodes that are identically configured other than one having SAO enabled and one having it disabled, some of the blocking artifacts (particularly in motion) in the version without SAO will not be visible in motion in the version with SAO enabled.

[rwill]

Fascinating! I see the opposite with real world content, typically :)

By blocking suppression I mean that if you compare two low bitrate encodes that are identically configured other than one having SAO enabled and one having it disabled, some of the blocking artifacts (particularly in motion) in the version without SAO will not be visible in motion in the version with SAO enabled.

Actually it means YOUR real world content does not have film grain. If you take movies like, for example, Aliens, Safehouse, Titanic, Miami Vice, The Wizard of Oz (1939), Taxi Driver or The Grey - they all trigger this effect.

Regarding you statement about blocks going away, I hope you know SAO works only on 64x64 blocks or whatever LCU size you have configured so I guess either your blocks in motion are aligned on a 64x64 block grid that SAO can work on or you are seeing things.

[filler56789]

Do you know of any encoders with superior SAO implementations?
Sure.

Then please name them. :)

For the notes... the last I checked, Rovi's HEVC Encoder in the TotalStudio software offered three types of SAO — for luma only, for chroma only, and for both luma and chroma.
But there were no user-configurable parameters and I didn't bother to check whether their SAO implementation was good or not.

[rwill]

Then please name them. :)

For the notes... the last I checked, Rovi's HEVC Encoder in the TotalStudio software offered three types of SAO — for luma only, for chroma only, and for both luma and chroma.
But there were no user-configurable parameters and I didn't bother to check whether their SAO implementation was good or not.

Any encoder not having a broken SAO implementation should be superior. Its not hard to do really so my guess is all comercial encoders do it right one way or the other. And I think in this time and age one can expect to not get really bad artifacts by having a tool thats enabled by default. Asking if someone knows of an encoder that has a better SAO implementation, like one that does not totally wreck the picture, is grotesque. The question is rather why Multicoreware does not fix their x265 SAO implementation. The problems have been present since day 1 and have been reported shortly after.

SAO has 6 different modes it can apply to a CTU, the most important mode is the "dont touch the pixels" mode if an encoder cannot derive satisfactory parameters for the modes that actually do change some of the pixels. x265 produces worse results when SAO is enabled as can be seen with the sequence I posted. x265 just shouldnt modify a CTU through SAO if it cannot derive parameters that improve the CTU subjective or objectively but it does anyway.

[Asmodian]

Any encoder not having a broken SAO implementation should be superior. Its not hard to do really so my guess is all comercial encoders do it right one way or the other.

I do not think this is a safe guess. It might be true, but just because they are "commercial" does not mean they do it any better. :p

Do you have any experience with any of them doing better?

[rwill]

I do not think this is a safe guess. It might be true, but just because they are "commercial" does not mean they do it any better. :p

Do you have any experience with any of them doing better?

I develop software video encoders for a living. I know that my HEVC encoder is doing SAO better.

[Gravitator]

At least reduce the impact a little. How are things going with VVC?
--limit-sao --sao-non-deblock

[benwaggoner]

I develop software video encoders for a living. I know that my HEVC encoder is doing SAO better.
Can you share which is yours?

[Kill3rWolf]

I develop software video encoders for a living. I know that my HEVC encoder is doing SAO better.

Could you provide your HEVC encoder link?

[tonemapped]

Could you provide your HEVC encoder link?

Many have asked and he's either refused to, or simply not answered. It would seem likely he's not developed a custom encoder.

[rwill]

Heh.. Eternal September

[CruNcher]

i think you can see the SAO effect especially on Smartphone Still image HEIC results has the feeling of a very artificial reconstruction like wavelet paint

[rwill]

As SAO for still images is a pure post processing step, can you post a smartphone example with and without SAO applied where this "very artificial reconstruction like wavelet paint" can be seen easily ?

[CruNcher]

i assessed this by Psy of a older Samsung A51 but it could be also some interpolation they used at the highest 3:4 48 MP mode and their camera capture pipeline
that mode creates a lot of times a wavelet paint impression but it's surely not native at all

i guess nhw_pulsar would refer to it as "neatness is strange"

i might whatch some old review videos of that Phone to see what different Reviewer said and thought about this.

i didn't saw the SAO effect yet but i imagine that could be what is being described let me find a example PSY shoot

i didn't even looked at the bitstream yet to be honest

for 7 mb output it looks weird under this clear light conditions

Samsung A51 8 Core Exynos 9611/Mali-G72 MP3 3:4 MP 48 7 MB 6000x8000 HEIC (distance reconstruction)

https://i.postimg.cc/L4NYmnwP/samsungheic.pnghttps://i.postimg.cc/500kyMBw/samsungheic5.pnghttps://i.postimg.cc/65QFqnhk/samsungheic2.pnghttps://i.postimg.cc/ry7qbxWH/samsungheic7.pnghttps://i.postimg.cc/N0Wr96Tp/samsungheic3.pnghttps://i.postimg.cc/XvMV9QHG/samsungheic4.pnghttps://i.postimg.cc/VLxtgJD9/samsungheic8.pnghttps://i.postimg.cc/28Sg2Jb7/samsungheic6.pnghttps://i.postimg.cc/j2sRMhzD/samsungheic9.png


As SAO for still images is a pure post processing step, can you post a smartphone example with and without SAO applied where this "very artificial reconstruction like wavelet paint" can be seen easily ?

yeah you can actually disable it like the deblocking on the decoder side i will experiment with that on the Samsung samples.

and create some more realtime life tests and of course try to get some raw camera results

[Z2697]

That just looks like anything from smartphone camera.
At least try comparing with SAO disabled in decoding to confirm it's really SAO please.
x265's SAO is BAD, I don't have doubt on that, but this is highly unlikely the case here.