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 (http://forum.doom9.net/showthread.php?p=1957733#post1957733).

[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]

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]

--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]

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 (https://filedn.com/lNL17ziIgWrVnCREc5hiAEm/_Supernatural_source_VC1.mkv)

x265 custom: _Supernatural_encode_3pass_custom_x265.mkv (https://filedn.com/lNL17ziIgWrVnCREc5hiAEm/_Supernatural_encode_3pass_custom_x265.mkv)

x265 Waggoner: _Supernatural_encode_3pass_Waggoner_x265.mkv (https://filedn.com/lNL17ziIgWrVnCREc5hiAEm/_Supernatural_encode_3pass_Waggoner_x265.mkv)

x265 Boulder: _Supernatural_encode_3pass_Boulder_x265.mkv.mkv (https://filedn.com/lNL17ziIgWrVnCREc5hiAEm/_Supernatural_encode_3pass_Boulder_x265.mkv.mkv)

x264 custom: _Supernatural_encode_3pass_custom_x264.mkv (https://filedn.com/lNL17ziIgWrVnCREc5hiAEm/_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]

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]

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]

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...

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/1HrTfs_xfVrw8mpG2S3dNYuFBkydsWr3u/view?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]

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.


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


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

https://drive.google.com/file/d/1HrTfs_xfVrw8mpG2S3dNYuFBkydsWr3u/view?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 (https://en.wikipedia.org/wiki/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.

[tonemapped]

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 ?Why are you registered if that's your primary view? It's legal to make a copy of owned content.


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

Garbage in, garbage out (https://en.wikipedia.org/wiki/Garbage_in,_garbage_out)
I didn't create this thread to debate VC-1 vs H.264 quality. I'm not sure where you got that impression from.


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.'
I'm more than aware that encoding it isn't going to remove defects on the source. Again, that's not the problem - the problem is x265 having poor handling compared to x264 when more complex grain is involved. Based on your test file of the same scene, you've simply stripped all the grain from it. That's not a solution.


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.This is a problem I've encountered on a number of Blu-ray sources, including the German remastered Charmed collection (which is know for its excellent quality).

Why won't you name the encoder you claim you've created? The file you shared shows GPAC. Are you claiming you created that?


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.The issue I'm trying to solve is x265's poor handling of grain, compared to x264 at the same bitrate.


I only posted the output of a different encoder to prove that it can be done in higher 'quality' compared to x265.Which encoder?


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.And the relevance of that statement is...?

[tonemapped]

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.

I'm happy to use CRF, but used 6mbps for the sake of comparison, or do you mean low bitrate sources? The annoying this is, the majority of the encode looks great with grain at ~5mbps - apart from those types of scenarios where the grain 'clings' to moving objects. This is not a source problem, but something x265 fails at (even encoding 2-pass, very slow, 100mbps doesn't get rid of the issue), or something I'm doing wrong.

I don't use x265 for everything, but for less noisy sources it's excellent. Even with some noisy sources it's not bad. Sex and the City is one of the worst 'remasters' I've ever seen, with the usual trick of adding a thick layer of noise to help with perceived quality. Using slow (with a few changes), CRF 23, the file produced is 1.24GB (5,910 kb/s) and looks great.

[Boulder]

I'm happy to use CRF, but used 6mbps for the sake of comparison, or do you mean low bitrate sources? The annoying this is, the majority of the encode looks great with grain at ~5mbps - apart from those types of scenarios where the grain 'clings' to moving objects. This is not a source problem, but something x265 fails at (even encoding 2-pass, very slow, 100mbps doesn't get rid of the issue), or something I'm doing wrong.

I don't use x265 for everything, but for less noisy sources it's excellent. Even with some noisy sources it's not bad. Sex and the City is one of the worst 'remasters' I've ever seen, with the usual trick of adding a thick layer of noise to help with perceived quality. Using slow (with a few changes), CRF 23, the file produced is 1.24GB (5,910 kb/s) and looks great.
I mean low-bitrate encodes. Of course, that's pretty much a subjective thing as it depends on how well the source compresses. 6 Mbps might not be that much for 1080p - for example I'm currently encoding the LOTR movies and it looks like The Two Towers will end up at around 8 Mbps at CRF 19 using my slightly denoising script. If it had an AR of 1,78:1, it would require much more.

Having said that, I still suggest testing some very slight denoising to combat your issues.

[benwaggoner]

Some things to try when strugging with fine grain content in x265:

use --nr-inter to reduce grain swirling and bitrate consumption. It can go up to 2000; don't be afraid to test high values.
Raise --nr-intra to where I frames don't have visibly more detail
Reduce --ipratio and --pbratio for less frame strobing
Raise psy-rdoq to retain a more even appearance of grain detail
Reduce --aq-strength to keep grain detail more consistent across the frame
Use --aq-mode 4 instead of 2
Use --rskip 2 instead of 1, with a lower threshold. The original rskip was terrible with grain
Try --rd 4 if --rd 6 isn't working well

[tonemapped]

I mean low-bitrate encodes. Of course, that's pretty much a subjective thing as it depends on how well the source compresses. 6 Mbps might not be that much for 1080p - for example I'm currently encoding the LOTR movies and it looks like The Two Towers will end up at around 8 Mbps at CRF 19 using my slightly denoising script. If it had an AR of 1,78:1, it would require much more.

Having said that, I still suggest testing some very slight denoising to combat your issues.
That's an impressive bitrate for a film with some complex scenes. What's the basis of your denoising script?

Some things to try when strugging with fine grain content in x265:

use --nr-inter to reduce grain swirling and bitrate consumption. It can go up to 2000; don't be afraid to test high values.
Raise --nr-intra to where I frames don't have visibly more detail
Reduce --ipratio and --pbratio for less frame strobing
Raise psy-rdoq to retain a more even appearance of grain detail
Reduce --aq-strength to keep grain detail more consistent across the frame
Use --aq-mode 4 instead of 2
Use --rskip 2 instead of 1, with a lower threshold. The original rskip was terrible with grain
Try --rd 4 if --rd 6 isn't working well


I find intra frame noise reduction produces horrible results no matter what I do (and change elsewhere). I conducted a test with Inter-frame denoising at an absurd value (1000) and it produced a really great result. I also conducted a test with inter-frame noise reduction at 75 and SAO enabled with selective SAO at 1. That also produced a good result. Both were at CRF 21.

Using intra-frame NR seems to produce blurred results with a lot of detail lost (not just the perceived detail grain/noise offers). Is this something you've experienced?

I generally always reduce the ipratio and pbratio to 1.30 and 1.20, or if a complex source then 1.2 and 1.1 (or thereabouts).

I've tried values from the default 1.00 up to 30.00 and, perhaps it's my eyes, not really seen much difference between them - and that's with rskip on 2.

Oddly, I've found an AQ of 1 producing the best results with x265, with 3 and 4 prone to a strobing effect. Not sure how else to describe it. I usually set AQ strength to 0.80 for most content, and then ~0.60 for very noisy content. However, it appears AQ acts very differently on x265 compared to x264 and I've not managed to find a paper or even a simple answer on how it works differently etc.

I'll try changing RD to 4. Have you experienced content where 4 produces a better result compared to 6, and if so, why do you think that occurred?

I've replied with bullet points for clarity - I don't want it to be seen as rudeness.

[tonemapped]

Since I managed to get the Sex and the City boxset for a bargain price, here's what some testing produces. The idea was not to be transparent since the Blu-ray isn't great, but for it to be 'close enough' at a much reduced file size.

I'm curious if anyone can tell which is which - it should be obvious. This is was of the worst examples I could find (in terms of quality). Since the grain/noise is 'bigger' on this, I'm using --aq-mode 3 which seems to work better. For finer grain, AQ 1 (or disabled) seems the best.

One is taken from the Blu-ray disc and is just over 6.31GB at 1920*1080. The other is the x265 encode and is 1.40GB at 1440*1080 (screenshots using spline36 to resize to 1920*1080). The screenshot from the encoded file is a b-frame.

--crf 23 --preset slow --output-depth 10 --profile main10 --rd 5 --psy-rd 2.45 --psy-rdoq 3 --rskip 2 --no-rect --aq-mode 3 --aq-strength 0.7 --nr-inter 75 --ipratio 1.35 --pbratio 1.25 --subme 6 --bframes 8 --rc-lookahead 120 --deblock -4:-4 --no-sao --no-strong-intra-smoothing


https://i.ibb.co/KW7fwWq/satc-test16-1.png


https://i.ibb.co/G3rCLL3/satc-test16-2.png

[Boulder]

That's an impressive bitrate for a film with some complex scenes. What's the basis of your denoising script?


I can share the denoiser function after some cleanup. It's just similar stuff that many others do: 1) predenoise the clip used for motion search, 2) do analysis on that clip and 3) use MDegrain on the sharpened original clip for limited motion compensated denoising to avoid excessive detail loss. Does slight spatial denoising where block matching is bad (usually blocks with lots of motion).



The final average bitrate for the TTT was around 8.1 Mbps. However, I must stress that there is something wrong with CTU 64 and 1080p resolution at least when it comes to CRF encodes (EDIT: and rskip mode 2). I did a color corrected encode of FOTR EE (cropped resolution 1920x800) and started wondering why the flat backgrounds don't look good at all in motion. I then compared CTU 64 and 32 on a shorter sample from the movie and the filesize difference was very big. I've already noticed this earlier but thought it was only in case of --limit-tu 0. I am quite sure that the encoder does some stupid decisions with CTU 64 and rskip 2 because the avg QP differs a lot but frame types are of course the same. I really need to test if it applies to >1080p resolutions as well. Hope not, because it would mean some more rework for me :scared:

https://forum.doom9.org/showthread.php?p=1919347#post1919347

[Boulder]

And forget the exotic aq-modes, they just don't work well with regular encodes. I'd say modes 1 or 2 are the ones to use, and 1 preferred in most cases. The functionality was ported from x264 and I don't think the devs have done any real work on them. That's why they may not work like in x264 because the environment is not the exact same.

[Boulder]

I've pasted my function here: https://pastebin.com/0KegSZiR - I suppose you know how to handle Avisynth functions. If you don't have it already, I strongly recommend the latest official Avisynth+ build by pinterf and then possibly his latest test build from the Avisynth+ thread in the Avisynth Development section. Chances are that some of the dependencies require that.

Dogway's filter packs are used by the function, you'll probably need at least ExTools, TransformsPack, SPresso and SMDegrain. https://forum.doom9.org/showthread.php?t=182881
Get pinterf's MVTools and DFTTest as well.

What I usually do is:
1) Use debug=1 to select the prefiltering (adjusted by prefilter=1, 2 or 3) on the motion search clip. This depends on the amount of noise and grain as you want to have a rather clean clip to do the analysis on.

2) Use debug=6 to set thscd1 and thscd2 based on the amount of blocks it detects as "changed too much". In the upper left corner, if the bottom value exceeds thscd2, it triggers a scene change in the denoising. This must be set for each source as they differ a lot. Thscd1 affects which blocks are detected as "changed too much".

3) Finally, debug=2 to set limit (limits MDegrain) and blurlimit (limits spatial blur), it interleaves between the original and denoised frame. Debug=3 is the same but it shows the differences in luma amplified. Debug=4 does the same for chroma.

The defaults are set so that the denoising is very slight as I like to keep the grain. Still, it can easily shave off a nice amount of bits from the final encode without actually being noticable.

For example, my ROTK script looks like this (on a 3900X):
part1=DGSource("M:\lotr_rotk_part1.dgi",ct=144,cb=144,cl=4,cr=4).Trim(0,183541)
part2=DGSource("M:\lotr_rotk_part2.dgi",ct=144,cb=144,cl=4,cr=4).Trim(24,0)
part1+part2
MDG(limit=0.1, prefilter=1, blurlimit=0.3, thscd1=420, thscd2=90)
Neo_f3kdb(preset="medium", grainy=0, grainc=0, output_depth=16, sample_mode=4, mt=false)
AddBorders(8,0,8,0)
Prefetch(threads=24, frames=12)

[tonemapped]

... However, I must stress that there is something wrong with CTU 64 and 1080p resolution at least when it comes to CRF encodes (EDIT: and rskip mode 2). I ... started wondering why the flat backgrounds don't look good at all in motion. I then compared CTU 64 and 32 on a shorter sample from the movie and the filesize difference was very big.

https://forum.doom9.org/showthread.php?p=1919347#post1919347
Genuinely fascinating. I've also noticed that CTU 64 vs CTU 32 for 1080p encodes produces results I perceived to be odd, but thought it was normal and perhaps an oddity of x265. I've found in tests that 3-pass (slow first pass) encodes at 7,000 kbps in 720p, backgrounds look more natural compared to the 1080p encodes at 16,000 kbps. This is on a source with very little noise and backgrounds should be clean with no banding at the bitrates used.

What's your results from n-pass tests?


I've pasted my function here: https://pastebin.com/0KegSZiR - I suppose you know how to handle Avisynth functions.
I do.


Dogway's filter packs are used by the function, you'll probably need at least ExTools, TransformsPack, SPresso and SMDegrain. https://forum.doom9.org/showthread.php?t=182881
Get pinterf's MVTools and DFTTest as well.I believe I have most of those, although SMDegrain is having issues on Windows 11 Pro (for me). No idea why.


What I usually do is:
1) Use debug=1 to select the prefiltering (adjusted by prefilter=1, 2 or 3) on the motion search clip. This depends on the amount of noise and grain as you want to have a rather clean clip to do the analysis on.

2) Use debug=6 to set thscd1 and thscd2 based on the amount of blocks it detects as "changed too much". In the upper left corner, if the bottom value exceeds thscd2, it triggers a scene change in the denoising. This must be set for each source as they differ a lot. Thscd1 affects which blocks are detected as "changed too much".

3) Finally, debug=2 to set limit (limits MDegrain) and blurlimit (limits spatial blur), it interleaves between the original and denoised frame. Debug=3 is the same but it shows the differences in luma amplified. Debug=4 does the same for chroma.

The defaults are set so that the denoising is very slight as I like to keep the grain. Still, it can easily shave off a nice amount of bits from the final encode without actually being noticable.

For example, my ROTK script looks like this (on a 3900X):
part1=DGSource("M:\lotr_rotk_part1.dgi",ct=144,cb=144,cl=4,cr=4).Trim(0,183541)
part2=DGSource("M:\lotr_rotk_part2.dgi",ct=144,cb=144,cl=4,cr=4).Trim(24,0)
part1+part2
MDG(limit=0.1, prefilter=1, blurlimit=0.3, thscd1=420, thscd2=90)
Neo_f3kdb(preset="medium", grainy=0, grainc=0, output_depth=16, sample_mode=4, mt=false)
AddBorders(8,0,8,0)
Prefetch(threads=24, frames=12)
Thank you for sharing your snippet. What's your view of something like TemporalDegrain2 instead of MDegrain, and perhaps GradFun3 instead of neo_f3kdb? Certainly in the latter I see better results with noisy sources.

[Boulder]

Genuinely fascinating. I've also noticed that CTU 64 vs CTU 32 for 1080p encodes produces results I perceived to be odd, but thought it was normal and perhaps an oddity of x265. I've found in tests that 3-pass (slow first pass) encodes at 7,000 kbps in 720p, backgrounds look more natural compared to the 1080p encodes at 16,000 kbps. This is on a source with very little noise and backgrounds should be clean with no banding at the bitrates used.

What's your results from n-pass tests?
I've never properly tested a multipass IIRC, since I don't do any of that for production use. I would expect that it still shows the same symptoms. My findings earlier were that the encoder favours merges a lot when CTU is 64 and you use rskip mode 2.


Thank you for sharing your snippet. What's your view of something like TemporalDegrain2 instead of MDegrain, and perhaps GradFun3 instead of neo_f3kdb? Certainly in the latter I see better results with noisy sources.
As far as I know, TemporalDegrainV2 also does similar things, i.e. MDegrain is used there too. I've noticed that neo_f3kdb does very slight debanding with my settings so I've kind of settled on that. Strong settings can easily start removing detail from the image.

[tonemapped]

Off topic, but ...

Currently running three x265 jobs - including one testing out TemporalDegrain2 as a substitute (as mentioned above). Still amazed after going from a 4C/8T 6700K @ ~4.5 GHz (overclocked) to a 12C/24T 5900X at ~4.30 GHz (stock). The new CPU also runs 20°C cooler (although it does have a 360mm radiator)!

https://i.ibb.co/B4hyywB/encode-x265-x3.png

Boulder, the reason I've gone off topic is because you mentioned you also have a 12C CPU. What sort of thread/pool allocation do you tend to use with x265? In x264 it's easy to work out, but with x265 it seems that the extra threads really hurt quality if allocated to a single job, hence running three jobs at the same time. I've done tests on a 32C/64T server at work, but that's different as the default setup is four simultaneous jobs.

[Boulder]

Boulder, the reason I've gone off topic is because you mentioned you also have a 12C CPU. What sort of thread/pool allocation do you tend to use with x265? In x264 it's easy to work out, but with x265 it seems that the extra threads really hurt quality if allocated to a single job, hence running three jobs at the same time. I've done tests on a 32C/64T server at work, but that's different as the default setup is four simultaneous jobs.

That is an interesting question indeed. I've not encountered any quality issues with the default settings - I believe the biggest thing with faster presets is that they use lookahead slices which can affect frame type decisions negatively. The slower ones run just one slice.

I've also tested -F 1 to -F 4 and have not noticed any negative impacts by running four frame threads as per default. I think it may affect reference frame decisions negatively, but nothing that I could see with my own eyes (frame by frame or in motion).

So in short; I just run with the default settings and also assign 24 threads to Avisynth so the total CPU usage is usually 80-99%.

[funskel]

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.

The technique is codec agnostic, but AV1 patents are licensed (https://aomedia.org/license/patent-license/) only for implementations of AV1. I haven't found documentation of what patents are involved, but if ATEME's film grain patent (https://patents.google.com/patent/US20210344968A1/en) is one (they are an AOM member), it might require a separate license to use it with another codec.

[BuccoBruce]

The technique is codec agnostic, but AV1 patents are licensed (https://aomedia.org/license/patent-license/) only for implementations of AV1. I haven't found documentation of what patents are involved, but if ATEME's film grain patent (https://patents.google.com/patent/US20210344968A1/en) is one (they are an AOM member), it might require a separate license to use it with another codec.

Interesting, I have yet to see it implemented in a video file though, and other than my own toying around with AOMenc's "out of band" grain synthesis tools, I don't think I've really seen anyone mess with this in any meaningful way.

x265 added support for side-band grain synthesis data (https://mailman.videolan.org/pipermail/x265-devel/2022-March/013459.html) a while back, and multicoreware released their own utility for generating noise data (https://bitbucket.org/multicoreware/libfgm/src/master/).

Technically it was in the spec for H.264 too (https://ieeexplore.ieee.org/document/7289655)...and it looks like now it's MPEG-C/9 (https://www.mpeg.org/standards/MPEG-C/9/)

It looks like ffmpeg might have decode support for film grain synthesis SEI messages in HEVC bitstreams as well? https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2021-August/128333.html

ITU calls it "H.274" now as well.

TL;DR Grain synthesis sounds cool, I've played with it before with AV1 (https://forum.doom9.org/showthread.php?p=1969629#post1969629), and it's still got a long way to go

Back to HEVC and grain synthesis, at least with x265, an immediate observation comparing it with the aforementioned reference/test tool that you can compile alongside AOMEnc is that:

AOMEnc's grain tool actually has you supply two .yuv files - one with grain, and one without
It generates the grain parameters based on the difference between the two, which means degraining the video is on you
This mcw utility does the de-graining for you and generates a binary grain model file and...
I assume you're then meant to encode the de-grained "output.yuv" file it also produces, but there's technically nothing stopping you from telling it to send output.yuv to NUL, and then de-graining the source how you prefer and just encoding that while still supplying the generated grain model to x265 to then re-inject the grain parameters


On paper, I liked how AOM's test implementation sounded, since it meant I could use an obnoxious chain of AVISynth filters to degrain in a way that looked pleasing to me. It also meant I could "clean up" the grainy source a little bit first without actually doing any de-graining, like trying to remove any macroblocking introduced by compressing grain from 80+ year old film at 15 Mbps using AVC and use the difference between that and the "fully de-grained" input .yuv to "generate" the grain parameters. In practice? I only tested it once, but the grain synthesis parameters AOM's tool generated were...not great.

Speaking of grain that's compressed so much that it's turned into macroblocks...shame on you WHV...you could've given us an extra couple of discs and bumped the bitrate, these weren't exactly cheap for 80+ year old cartoons. You could've fixed the pitch issues on "very musical" shorts like Rabbit of Seville that you introduced somewhere in the restoration process instead of forcing me to hunt down older DVD copies and yoink the audio from there. You could've thrown in a TrueHD track as well, since DTS-HD MA 2.0, even with a smaller 768 kbps "core", would've likely wasted more space than TrueHD 2.0 + the mono AC-3 that's already on here. Really makes me chuckle that neither lossless audio format has any provision for actual mono sound, DTS doesn't have support for 1.0 channel sound at all, but at least newer TrueHD encoders seem to be a bit more clever about what I can only assume is using things like joint-stereo coding internally and saving some more bits on tracks like that, not that I have access to one for testing, but I digress...

Was it better than trying to make the resulting ~2-4 Mbps AV1 encode (I forget) that I ended up making with the grain left intact as is from the already bit-starved ~15 Mbps Blu-Ray source? YES, no question.

I also deliberately picked a test clip that you could see "elsewhere" in any number of different places and formats. With WB uploading the same clip in a longer video presumably "unfiltered" to YouTube - you can see how poorly YouTube's 1-2 Mbps AV1, AVC, and VP9 compression fared with grain that heavy. In addition to places like Amazon and iTunes, I think the same short is probably on Boomerang or HBO Max or both, with the former seemingly using nearly identical files, with very similar bitrates to their Blu-Rays in my experience (but usually 25 fps PAL masters meant for European terrestrial broadcast - no speed-up, just frame duplicated) and the latter using lower bit-rate x264 or x265 (they keep the SEI messages in there...lol, just like Netflix) from the same masters as either of the other two. Amazon and iTunes obviously do their own thing as well.

There's very clearly only one "newly restored master" for all of these old shorts, but how "early on" in the generational loss chain either of the three, WHV/WBHE, Boomerang, or HBO Max, got their hands on the material is only something they'd be able to tell you. benwaggoner, will you get in trouble if you hint at what kind of files WBHV might have given Amazon in the past? :p

Was it better than letting AOMenc try to de-noise on its own and generate grain parameters? Absolutely.

Did it look any good? Eh...it was certainly "as noisy" when comparing side-by-side with the source, but I could see..."grain macroblocks" if that makes sense. Clear boundaries in the areas of the drawn grain pattern, which make more sense when you look at the actual information the utility spits out, it's just frame/timestamps, regions, and what I think are seed numbers. You could also very easily see the "synthetic" structure of it all. I haven't actually looked at what the SEI data looks like, or if it's any different from the information the utility made.

It didn't look like natural film grain, it looked like an overlay. I mean, I know it already is technically nothing more than an overlay, but it took a long ass time to generate, so I certainly had higher expectations than that. I wouldn't be surprised if somebody writes some kind of GPGPU plug-in (please make it platform agnostic, and not bound to CUDA...) to generate its own synthetic grain in real-time that looks better than you could ever signal in tiny little sideband/SEI messages.

Did I ever use it again? No. My poor results might've been entirely on me, with just how grainy the source was, and how spotless the "no grain" comparison file was I made this time around. I'm not very skilled with making "good" filter chains for this kind of thing, and it was also contrasharpened. When I normally de-grain old animation like this, I tend to prefer sharper output over either completely removing all of the grain or saving the most amount of bits when I encode it at the end. I just want it to look "how I think it ought to."
Everybody who worked on these is long since dead, may they rest in peace, and it's really old, at times not well preserved, film. I get to decide what I like, purists pls cry elsewhere - if the "source" material available was better then maybe I'd be more of a "purist" about it...

There was a third option I didn't explore, using two slightly different "de-grained" files, one with no additional processing to generate the grain, and one with more of the filters I'd probably be applying to material like this - a little bit of contrasharp, etc. for the encode. If I ever find the extra hard-drive space for a bunch of .yuv video and the time to play with it some more, I might try it again with the sharpened file only being used for the final encode, and the "de-grained" parameter generation file being completely un-sharpened, but I'd probably wait for an improvement in the utilities themselves before considering it.

[benwaggoner]

AFAIK no one is using the AOM reference FGS implementation in practice. Degraining is a whole other area of research with different participants, and where commercial implementations seem the most likely FGS route for the next few years. Speed is absolutely a concern for degraining as well. CUDA-based implementations can be quite good, but tons of existing encoding workflows in the cloud are on CPU-only instances, with CUDA enabled instances a lot more expensive.

While degraining and grain synthesis are generally well understood, the middle part where the grain gets parameterized while removed is relatively new stuff, with a whole lot of implementation complexities. A mature FGS solution would remove grain that can be parameterized, but pass through other noise types that can't be parameterized well under the AV1 FGS synthesis algorithm. There are other complexities, like some seed numbers providing suboptimal results, that need to be worked around. I hope we'll see a solution with good enough quality, fidelity, and performance to safely leave on by default in the next year or two. But that'll probably be commercial, not open-source. Once a good commercial implementation exists, I imagine the open source community will work to reverse engineer the techniques.

[HD MOVIE SOURCE]

If anyone is still working on this, please let me know the success you've had, and what grain settings work best. I'd just like to see if there's anything you're doing now that's improved the look compared to x264 vs x265. Thanks.

[benwaggoner]

If anyone is still working on this, please let me know the success you've had, and what grain settings work best. I'd just like to see if there's anything you're doing now that's improved the look compared to x264 vs x265. Thanks.
I am getting good results with what I listed above:


use --nr-inter to reduce grain swirling and bitrate consumption. It can go up to 2000; don't be afraid to test high values.
Raise --nr-intra to where I frames don't have visibly more detail
Reduce --ipratio and --pbratio for less frame strobing
Raise psy-rdoq to retain a more even appearance of grain detail
Reduce --aq-strength to keep grain detail more consistent across the frame
Use --aq-mode 4 instead of 2
Use --rskip 2 instead of 1, with a lower threshold. The original rskip was terrible with grain
Try --rd 4 if --rd 6 isn't working well

I'd suggest just defaulting to --rd 4 with grainy 4K content. --rd 6 only works well at 4K with no or low grain. --rd 6 with grainy content is generally better at 720p and below, and at 1080p with moderate or less grain.
A --nr-inter to --nr-intra ratio of 2-5x has been good in my experiments. --nr-intra 100 --nr-inter 350 are probably good starting points. These can have a big impact on bitrate with --crf.

[simple_simon]

I've pasted my function here: https://pastebin.com/0KegSZiR

I know this is an old thread but I'm trying to test your script and getting errors. I don't know if some of the terminology changed in the Dogway dependencies? Do you have an update version?

[Boulder]

I know this is an old thread but I'm trying to test your script and getting errors. I don't know if some of the terminology changed in the Dogway dependencies? Do you have an update version?

I think it's not changed much. What errors do you get?

[simple_simon]

I think it's not changed much. What errors do you get?

I think I got it figured out. I changed "sstr" to "str" in line 65. I was also getting an error saying it didn't know what "limit" meant or something before but now I can't reproduce that again.

I'm still not sure how you use the debug switches to figure out the values to use? Do I just use the settings listed on screen? And debug=1 doesn't seem to do anything. How does it help determine the prefilter version to use?

[Boulder]

I think I got it figured out. I changed "sstr" to "str" in line 65. I was also getting an error saying it didn't know what "limit" meant or something before but now I can't reproduce that again.

I'm still not sure how you use the debug switches to figure out the values to use? Do I just use the settings listed on screen? And debug=1 doesn't seem to do anything. How does it help determine the prefilter version to use?
Yes, use the values shown in debug=6 to see if thscd1 and thscd2 are set correctly in your script and adjust based on if there are clear missed scene changes or false detections. Nowadays I usually adjust thscd1 unless it gets insanely high, but the range can easily be 300-700 depending on the source and prefiltering.

Debug=1 interleaves the original and prefiltered video so you need to step back and forth in the video in VDub to see the effect.

Looking at the code more thoroughly, I do have a more recent version of the script on my system. I can post it if you want to try it out. There's at least more prefiltering options and some more debug options for determining what the script does to the video.

[simple_simon]

Yes, use the values shown in debug=6 to see if thscd1 and thscd2 are set correctly in your script and adjust based on if there are clear missed scene changes or false detections. Nowadays I usually adjust thscd1 unless it gets insanely high, but the range can easily be 300-700 depending on the source and prefiltering.

Debug=1 interleaves the original and prefiltered video so you need to step back and forth in the video in VDub to see the effect.

Looking at the code more thoroughly, I do have a more recent version of the script on my system. I can post it if you want to try it out. There's at least more prefiltering options and some more debug options for determining what the script does to the video.

Ok, I understand debug=1 now. But I don't know what's going on in debug=6. It's probably because I'm not familiar with mvtools. Do I just copy the thscd1 & thscd2 from the stats listed in yellow? Or how do I determine if they are correct or need adjustment? And what are the stats in grey that change every frame that are above the yellow stats that never change? Also really not sure how to determine limit and blurlimit using debug=2.

And sure, please post newer script when you get a chance.

[Boulder]

Ok, I understand debug=1 now. But I don't know what's going on in debug=6. It's probably because I'm not familiar with mvtools. Do I just copy the thscd1 & thscd2 from the stats listed in yellow? Or how do I determine if they are correct or need adjustment? And what are the stats in grey that change every frame that are above the yellow stats that never change? Also really not sure how to determine limit and blurlimit using debug=2.

And sure, please post newer script when you get a chance.
In debug=6, the yellow values are the function parameters currently in use. Then at the top, the first grey value tells you the average SAD of the blocks in the frame. The second value tells you how many blocks are over the limit set by the thscd1 parameter. The thscd2 parameter is used to tell how many blocks can be over the limit before the frame is considered to be a scene change. So in this debug mode, you should find some good representative range of the source (which includes scene changes) and check what values the average SAD shows and if there are false scene changes detected or clear ones missed. In a scene change frame, the first grey value usually shows a quite high value and also the dots and lines representing the motion vectors are gone. Usually with clean sources, you can lower thscd1 while a very grainy source requires a higher value. The prefiltering you select affects this part as well.

Here's the latest version. I'm not entirely sure if the dependecies are the exact same as I have all Dogway's packages in my Avisynth autoload folder. It should work fine with the latest versions.
https://pastebin.com/TX2g5E2m

Debug=7 now shows you interleaved comparison of the original frame, original vs. the blurred frame (used in MDegrain for bigger weight on areas which have more motion), original vs. MDegrain and finally original vs. filtered. Debug=8 shows the same but with a more pronounced effect.

I always use debug=7 to adjust the settings; the blurred frame for adjusting blurlimit and bias and the MDegrain frame for thsad and limit. Quite often I try to set limit so that the MDegrain frame starts showing a slight difference. With a low value, the frame might just look all black. The PlaneMDSI value is a metric which tells how big the change is. I've noticed that in the MDegrain frame, it usually needs to be over 0.1 in order to see any real effect in the final result.
After adjusting the parameters, use debug=2 to see how it looks in "real life", it interleaves the original and filtered frame. Change those values a lot and you can see the effect quite easily.

There's also five different prefilters with prefilter=1..5 with increasing strength.

[tormento]

I am getting good results with what I listed above
Can you give us some numbers that you proved to be ok?

[Lucky38]

thank you. It is very informitive

[Lucky38]

In debug=6, the yellow values are the function parameters currently in use. Then at the top, the first grey value tells you the average SAD of the blocks in the frame. The second value tells you how many blocks are over the limit set by the thscd1 parameter. The thscd2 parameter is used to tell how many blocks can be over the limit before the frame is considered to be a scene change. So in this debug mode, you should find some good representative range of the source (which includes scene changes) and check what values the average SAD shows and if there are false scene changes detected or clear ones missed. In a scene change frame, the first grey value usually shows a quite high value and also the dots and lines representing the motion vectors are gone. Usually with clean sources, you can lower thscd1 while a very grainy source requires a higher value. The prefiltering you select affects this part as well.

Here's the latest version. I'm not entirely sure if the dependecies are the exact same as I have all Dogway's packages in my Avisynth autoload folder. It should work fine with the latest versions.
https://pastebin.com/TX2g5E2m

Debug=7 now shows you interleaved comparison of the original frame, original vs. the blurred frame (used in MDegrain for bigger weight on areas which have more motion), original vs. MDegrain and finally original vs. filtered. Debug=8 shows the same but with a more pronounced effect.

I always use debug=7 to adjust the settings; the blurred frame for adjusting blurlimit and bias and the MDegrain frame for thsad and limit. Quite often I try to set limit so that the MDegrain frame starts showing a slight difference. With a low value, the frame might just look all black. The PlaneMDSI value is a metric which tells how big the change is. I've noticed that in the MDegrain frame, it usually needs to be over 0.1 in order to see any real effect in the final result.
After adjusting the parameters, use debug=2 to see how it looks in "real life", it interleaves the original and filtered frame. Change those values a lot and you can see the effect quite easily.

There's also five different prefilters with prefilter=1..5 with increasing strength.

Hi,

I have got this for debug=7

https://imgur.com/a/acTJFsT

Have you got some advice how to solve it?

[Lucky38]

In debug=6, the yellow values are the function parameters currently in use. Then at the top, the first grey value tells you the average SAD of the blocks in the frame. The second value tells you how many blocks are over the limit set by the thscd1 parameter. The thscd2 parameter is used to tell how many blocks can be over the limit before the frame is considered to be a scene change. So in this debug mode, you should find some good representative range of the source (which includes scene changes) and check what values the average SAD shows and if there are false scene changes detected or clear ones missed. In a scene change frame, the first grey value usually shows a quite high value and also the dots and lines representing the motion vectors are gone. Usually with clean sources, you can lower thscd1 while a very grainy source requires a higher value. The prefiltering you select affects this part as well.
.

Does it mean i need to look at the second grey value to adjust thscd1?

for example i have this
MDG(limit=0.1, prefilter=1, blurlimit=0.3, thscd1=600, thscd2=100,debug=6)

which gives me 110 0 grey values. Should i change thscd1 till then i get 0 on second grey value?

Could you please clarify ?

[Boulder]

Hi,

I have got this for debug=7

https://imgur.com/a/acTJFsT

Have you got some advice how to solve it?

You need to have Dogway's SimilarityMetrics.avsi in your plugins folder as well, it's a dependency with ex_makediff and MDSI as a metric.

[Boulder]

Does it mean i need to look at the second grey value to adjust thscd1?

for example i have this
MDG(limit=0.1, prefilter=1, blurlimit=0.3, thscd1=600, thscd2=100,debug=6)

which gives me 110 0 grey values. Should i change thscd1 till then i get 0 on second grey value?

Could you please clarify ?

What I usually do is check a "calm" frame with little motion to see the base level (the first value) as this is often dependent on the noisiness of the source (after prefiltering). Then I check one with more motion to see if the second value gets too close to triggering a scene change, in which case thscd1 would need to be a little higher. No need to have the second value at 0 because by default it needs to be over 85 to trigger a scene change. The default thscd1=600 is very much on the safe side and something like 400 would probably work with most sources as well. The difficult scene changes are ones with low luma, it's easy to miss them.

Find a scene change frame and you can see how big the values are there :D

For improved motion detection, I suggest changing search to 5 and raising the searchparam values to something like 16-24 as default. Those old defaults in the script are very conservative what comes to performance.