Still trying to work out x265's 'static grain' issue

[tonemapped]

It's really hard to demonstrate this with anything other than high quality video, but ever since using x265, I've found that grain is treated very differently - which makes sense - apart from when there is a medium grainy scene with moving content (people in a nightclub) and the grain seems 'stick' around the moving person, yet appear normal/transparent (CRF 16/1080p) everywhere else.

With my new CPU, I have decided to start encoding Supernatural (retail Blu-ray release, with heavy grain in earlier seasons) in 1080p and even setting a CRF of 16 and --tune grain (+disabling SAO) sees the problem persist.

Even setting a CRF so low that the output is higher than the source seems the problem persist.

I realise without video to see the issue, it's hard to explain, but the best way I can describe is a sort of fuzz around moving objects such as a person. SAO removes this issue, but also removes grain/perceived detail.

If you had a very grainy source (which could have done with more bitrate from the studio), what would you do? I can then produce a test encode.

Edit: I would be happy to produce 2 test encodes - one with recommended flags and one with --tune grain -- both at three-pass 6000kbps and then clip 30s from the three clips (source, encode 1, encode 2) to post here (if the rules allow, which is uncertain).

Edit: I have provided 15s video examples in this post.

[benwaggoner]

--tune grain is a pretty thermonuclear option these days. It was required to get decent grain quality with x265 back 4-5 years ago, but grain handling has been much improved even without it. And --tune grain takes a lot of bits. it's possible you're still seeing quality issues at --crf 16 because VBV limits are kicking in with QP spikes in that region (you'll see that if ABR is getting close to your peak bitrate). And it's slow without rskip.

Can you share your full command line?

Were I to make a new "does well with most grain" setting today, I might start with:
--preset slower
--ipratio 1.2
--pbratio 1.1
--no-sao
--hme
--rskip 2
--psy-rd 3
--psy-rdoq 8
--nr-inter 100
--tskip
--tskip-fast

[Boulder]

I'd simply try --preset slower --no-sao --deblock -1:-1 --rskip 2 --rskip-edge-threshold 2 --psy-rd 4 --psy-rdoq 15 --aq-mode 1 and see how it looks.

Of course, it would help to see a sample of the source video.

[RanmaCanada]

I refuse to encode anything with noticeable grain, in HEVC. H.264 is still far superior. AV1 is supposed to be better, eventually, but until that happens, I'll just keep remuxing grainy sources and storing the discs on a shelf.

[benwaggoner]

Originally Posted by RanmaCanada

I refuse to encode anything with noticeable grain, in HEVC. H.264 is still far superior. AV1 is supposed to be better, eventually, but until that happens, I'll just keep remuxing grainy sources and storing the discs on a shelf.

And AV1 isn't intrinsically better. It supports film grain synthesis.

So it's not encoding the grain better, but degraining the source, parameterizing the removed grain, encoding, and putting the parameters into metadata. On playback the degrained frames are decoded and the parameters fed into a grain synthesis filter to generate new grain which hopefully looks like the original grain.

Which is utterly brilliant and should drop bitrates by >50% for grainy content!

But it's not like we've figured out optimal fully automated grain removal and parameterization technology! And that is out-of-band of the actual codec itself, and not something codec engineers are particularly skilled with or interested in. During AV1 development it was largely a "and someone else can implement..." feature. I'm not aware of anyone actually using FGS in deployed AV1 yet.

A cool thing is that the degraining process, metadata, and grain synthesis tech is all codec agnostic. SoC vendors are implementing it generically, so any AV1 decode capable HW should be able to use the same technique with HEVC, VVC, AV2, etc.

[RanmaCanada]

That is incredibly informative. Thank you.

[Gravitator]

Five seconds will be sufficient (30s threshold).

[tonemapped]

Originally Posted by benwaggoner

--tune grain is a pretty thermonuclear option these days. It was required to get decent grain quality with x265 back 4-5 years ago, but grain handling has been much improved even without it. And --tune grain takes a lot of bits. it's possible you're still seeing quality issues at --crf 16 because VBV limits are kicking in with QP spikes in that region (you'll see that if ABR is getting close to your peak bitrate). And it's slow without rskip.

Can you share your full command line?

Were I to make a new "does well with most grain" setting today, I might start with:
--preset slower
--ipratio 1.2
--pbratio 1.1
--no-sao
--hme
--rskip 2
--psy-rd 3
--psy-rdoq 8
--nr-inter 100
--tskip
--tskip-fast

Thank you - encoding with suggested options now @ 8 fps on a 5900X, which isn't that bad [edit: it's now 3.041 fps @ 4.25GHz, which is slow for a thread pool with 24T). Once encoded, will create comparisons and post scripts. What is the policy on video? Ideally, a 30s clip would be great from each of the encodes, but obviously I do not own the copyright for Supernatural and don't encourage piracy.

[tonemapped]

The encode has completed and I mistakenly used CRF rather than two- or three-pass for it, so it's created a file that's over 4GB and 13.5mbps. I'll do another encode using the suggested options above, but two-pass, and do a fresh encode of what I think *should* work but doesn't. 6,000 kbps should be more than enough in theory.

[tonemapped]

Originally Posted by Gravitator

Five seconds will be sufficient (30s threshold).

When you say 30s threshold, is that forum rules? I'm trying to find an exact scene and do proper control encodes (two- or three-pass, 6000kbps) and as it's motion-dependant, it'll need more than 5s to demonstrate it.

[tonemapped]

OK, I have cut a segment from the source file (just under 15s long) and encoded it thrice.

Where to find the issue
A fair example (not a perfect example) of the problem can be seen with the woman's head movement at ~11s in to the clip for approximately 2500ms. Please note the background being 'merged' into her head movement. It's partially there in this x264 encode as well, but this is only there for a comparison to show that, in my eyes looking one frame at a time and comparing, the x264 encode at the same bitrate as the x265 produces a better result. I have completed about a dozen test encodes of full episodes and find x265 to be far better in general, but it's just this bloody grain issue that's stopping me from proceeding with x265 (my general tests have shown a 35% reduction in file size with x265 compared to x264, apart from this grain issue).

Files provided
I've provided four files - all the same 14s 919ms long:

• Source - VC1 (cut directly from source)
• x265 - Waggoner's suggestion
• x265 - Boulder's suggestion
• x265 - Custom - what I believe should work
• x264 - Custom - what could work with more tuning, but still looks better than x265 in terms of movement with grain

Opinion
Looking frame-by-frame, I believe the best result is (just about) produced with Boulder's suggestion parameters. What do you think?

Technical Specifications

• 3-pass
• ~6,000 kbps
• x264 and x265
• ~15s per clip

The Files - these will be deleted at some point

Source: _Supernatural_source_VC1.mkv

x265 custom: _Supernatural_encode_3pass_custom_x265.mkv

x265 Waggoner: _Supernatural_encode_3pass_Waggoner_x265.mkv

x265 Boulder: _Supernatural_encode_3pass_Boulder_x265.mkv.mkv

x264 custom: _Supernatural_encode_3pass_custom_x264.mkv


Disclaimer: I own the original Blu-ray discs and do not condone piracy. I offer these 15 second clips for evaluation in order to help me legally back-up purchased content for my viewing. If I have unknowingly broken any forum rules, I apologise and ask that this post is deleted.

[tonemapped]

Originally Posted by Boulder

I'd simply try --preset slower --no-sao --deblock -1:-1 --rskip 2 --rskip-edge-threshold 2 --psy-rd 4 --psy-rdoq 15 --aq-mode 1 and see how it looks.

Of course, it would help to see a sample of the source video.

Added your suggestions to the list of encodes in the post above. Thank you to you and Ben.

[Boulder]

6000 kbps is actually not much for a grainy 1080p source so x265 will definitely start eating the grain. It might do for a 720p encode, depending on the aspect ratio.

You could also try using Avisynth and some filtering. SPresso at some very light settings can be undistinguishable but reduces the required bitrate by 5-15%.

[tonemapped]

Originally Posted by Boulder

6000 kbps is actually not much for a grainy 1080p source so x265 will definitely start eating the grain. It might do for a 720p encode, depending on the aspect ratio.

You could also try using Avisynth and some filtering. SPresso at some very light settings can be undistinguishable but reduces the required bitrate by 5-15%.

The main point is that 6000 kbps would suffice for a reasonable x264 encode, and I would expect x265 to provide better performance. What's your opinion of the comparisons and is the fault or issue now clear?

[rwill]

Well for grain and such a good rate for HD is around 3.5-4 Mbit with HEVC. I dont know where you guys take that "6Mbit, use x264" from.

Now we do not have the actual source. The "Source" provided here has around ~13Mbit video which is already compressed hard and in an inferior codec. My guess is that most bits are spent on compression artifacts. The Grain is stuck to the hair in this "Source" already, an encoder cannot magically unstuck it.

[Boulder]

At lower bitrates, you are better off with aq-mode 2 and SAO (maybe selective SAO could be used). Yes, SAO does eat grain for breakfast but you can't have both detail and a low bitrate if the source is not easy to compress. HEVC blurs while AVC creates blocking when the bitrate is not enough to keep the details. Blocking may look better in motion, depending on your viewing distance etc.

A lot of people think that HEVC is better because it is newer, but in fact the use cases are more or less related to being able to create a watchable video at a low bitrate at higher resolutions, at least for x265. You can easily see how most of the actual development is done on that part, and that is why I've always taken the developers' fancy new things with a grain of salt. I myself use x265 because of HW support for 10bit encodes and of course HDR encodes pretty much require using it.

[tonemapped]

Originally Posted by rwill

Now we do not have the actual source. The "Source" provided here has around ~13Mbit video which is already compressed hard and in an inferior codec.

The source comes directly from the purchased Blu-ray disc from a number of years ago. Clearly you don't understand that VC1 was used on some discs...

Originally Posted by rwill

My guess is that most bits are spent on compression artifacts. The Grain is stuck to the hair in this "Source" already, an encoder cannot magically unstuck it.

Please zoom in and you'll see the problem is far more pronounced in the encodes.

[rwill]

Looks like I have to be happy your "source" is not in H.262. What I meant is that you did not provide the snippet from the mezzanine the Blu-Ray was made from. Sorry but your source is Not So Good.

Please zoom in and you'll see the problem is far more pronounced in the encodes.

My point that most bits go into artifacts still stands. I could zoom in but I am too afraid to contract eye cancer.

I tried encoding your VC-1 snippet and got this at 4Mbit video with a differenct encoder:

https://drive.google.com/file/d/1HrT...ew?usp=sharing

While the hard blocks from VC-1 got smoothed out due to rate I see no additional problems introduced around the hair ?

[tonemapped]

Originally Posted by rwill

Looks like I have to be happy your "source" is not in H.262. What I meant is that you did not provide the snippet from the mezzanine the Blu-Ray was made from. Sorry but your source is Not So Good.

And where do you suggest I obtain the source you appear to want? It's a retail Blu-ray - I'm aware the quality isn't the best to start with, but blame the authors/distributors. What an odd point of contention.

Originally Posted by rwill

My point that most bits go into artifacts still stands. I could zoom in but I am too afraid to contract eye cancer.

Originally Posted by rwill

I tried encoding your VC-1 snippet and got this at 4Mbit video with a differenct encoder:

https://drive.google.com/file/d/1HrT...ew?usp=sharing

While the hard blocks from VC-1 got smoothed out due to rate I see no additional problems introduced around the hair ?

Which is the encode you have developed? You've previously mentioned it but not named it, despite being asked to do so.

[rwill]

You know, Blu-Rays are copy protected and are not meant to be used as a source for encoding the content further. So I guess keep your disc ?

You also seem to have a basic misunerstanding of data processing. Please read this Wikipedia article:

Garbage in, garbage out

As I wrote previously: 'My guess is that most bits are spent on compression artifacts. The Grain is stuck to the hair in this "Source" already, an encoder cannot magically unstuck it.'

Now x265 is not among the best HEVC encoders that are available but it is not really bad either - I mean at least its free. I think using crappy sources like yours prevent proper detail retention with x265 further. The quality issue you try to solve is really negligible if one takes the state of the source material into account and what an encoder can still do given such input.

I only posted the output of a different encoder to prove that it can be done in higher 'quality' compared to x265. Proving that something can be done better is very important in compression for some people. It differentiates between realistic and unrealistic demands in the ever present request for higher compression efficiency.