x264: Grainy films - Higher CRF or NR parameter??

[samtroy]

Hi all,

I usually encode my films with CRF 17. Sometimes a movie is so grainy that it takes a veeery high bitrate to encode with CRF 17. Definately too high, so I want to get rid of the grain ;-). Now, my question is:

What is better, quality- (or technical-)wise to eliminate the grain: To choose a higher CRF (like CRF 18 or 19) or stay with CRF 17 and add the "--nr 100" parameter to x264?

I don't want to user external "de-grainers" since I don't use AVISynth and also don't want to add hours to the encoding process. I've read that x264's --nr parameter is quality-wise fairly acceptable and also very fast.

Any opinions on this? Thanks in advance, guys.

[videoh]

It's up to you. Do you want to retain that grain or not? We can't tell you what you should prefer esthetically.

[samtroy]

No, I do *not* want to retain the grain. It's just too bitrate-intensive.

I just thought, using a higher CRF may be a better "grain eliminator" that using the NR parameter.. :confused:

[LoRd_MuldeR]

Well, I think "destroying" the noise by using higher compression will probably not give a good result. But evaluating the "--nr" parameter in CRF mode will be difficult and may be misleading!

Instead, you should use 2-Pass mode in order to ensure you always get the same bitrate and can compare results. Choose a bitrate that will be acceptable for your final encode. Then you can test how different "--nr" values effect the quality.

And with all this keep in mind that the "--nr" option of x264 is a very simple denoise filter. You will probably get much better results with something like MDeGrain, DeGrainMedian or dfttest...

[benwaggoner]

And with all this keep in mind that the "--nr" option of x264 is a very simple denoise filter. You will probably get much better results with something like MDeGrain, DeGrainMedian or dfttest...
It's not that simple. It only applies to predicted blocks, so tends to preserve grain texture from intra blocks or I-frames, without as much frame-to-frame random motion of grain. Tuning it can be tricky, but it can significantly reduce bitrate at a given CRF for noisy sources. And can make what some people would find a more pleasing (but less accurate) result.

[LoRd_MuldeR]

It's not that simple. It only applies to predicted blocks, so tends to preserve grain texture from intra blocks or I-frames, without as much frame-to-frame random motion of grain. Tuning it can be tricky, but it can significantly reduce bitrate at a given CRF for noisy sources. And can make what some people would find a more pleasing (but less accurate) result.

We need to keep in mind here that CRF is not a "constant quality" mode. Adding some "--nr" at a certain CRF value will probably result in a smaller file, but it will also preserve less detail. So does it really improve things, compared to just using a somewhat higher CRF? It's difficult to judge - as always when you are trying to compare the quality of files with different size (bitrate). That's why I would suggest using 2-Pass mode with a fixed target bitrate to evaluate the effect of "--nr".

[CarlEdman]

I dislike grain too, both for the look and the bitrate waste on essentially noise.

Over the years I have tried many different solutions, but by far the best is the MDegrain3 avisynth filter. It preserves fine detail, while significantly reducing noise, from grain or other sources, thereby improving both compressibility and--to my eye at least--actually improving the perceived quality of the output over the source material.

The only downside to MDegrain (unless you love film grain) is that it is quite CPU intensive, but with every passing year that becomes less of an issue.

[Asmodian]

I usually find MDegrain3 a bit too strong/smooth so I prefer MDegrain2, MDegrain3 does remove almost all the grain though.

[samtroy]

OK, thanks for all the interesting info.

Maybe I will take a look at MDegrain2/3. I was hoping thet the --nr parameter would also produce somewhat acceptable results. I really don't want to spend twice the encoding time just for the "de-graining".. :(

[CarlEdman]

Yeah, MDegrain3 (and to a lesser extent MDegrain2) can really increase CPU usage by 50% or more. That can be a big impact, in particular if you do not have a lot of cores to spare. On the positive side, you'll be able to efficiently use a lot of cores in avisynth MT (because it runs in a separate process and MDegrain exploits parallelism well), there are *substantial* improvements in compression ratio even for normal content (and even more so for grainy sources), and the result may look even better than you could obtain otherwise.

[F J Walter]

The --nr parameter is not particularly sophisticated, but it will make grain more compressible by effectively temporally smoothing it in predicted blocks. It's a very fast, and motion-compensated, alternative to running a more sophisticated de-noising filter as pre-processing.

Raising the CRF will settle for less quality over the movie overall. It's not the recommended way to deal with grain taking up too many bits.

The best way quality-wise would be to use a high quality denoising filter prior to compression. Using --nr is a relatively quick and easy alternative to this which in some cases can suffice. Use values of say 50 to 200 for a decent improvement in terms of bitrate without much perceptual loss in appearance.

Other crazy hackish ideas may include: turning off trellis (--trellis 0) and possibly also raising the --deadzone-inter slightly, remembering that 32 is the maximum. Turning off trellis and raising deadzones effectively reverse some of the optimisations for sharpness and detail retention which will result in less grain preserved (and less bits spent trying to do so).

[sneaker_ger]

--tune grain seems to do the opposite, i.e. reduce --deadzone-inter and --deadzone-intra while not touching trellis.

[Sharc]

Yes, but as I understand --tune grain aims at grain retention rather than grain removal...

[sneaker_ger]

Good point.

[asarian]

Just use something like MCTemporalDenoise: it's superior! Yes, you didn't want to to add CPU cycles to the process, but do it anyway!

At the very least, increasing CRF (= lowering overall quality) to make things so smudged that you won't see the grain any more, that feels like a very bad idea.

[samtroy]

OK guys, thanks again for all your input and thoughts.

[F J Walter]

--tune grain seems to do the opposite, i.e. reduce --deadzone-inter and --deadzone-intra while not touching trellis.

You observe correctly, and as pointed out, --tune grain is doing the opposite of what the OP wants here.

With trellis off, lowering deadzones will spend more bits on retaining grain and subtle detail, and raising deadzones will spend less bits on it.

Having trellis on, however, ignores deadzones for the most part (--though trellis 1 still uses deadzones for making some decisions) because trellis takes over the responsibility of deciding how coefficients should be rounded up or down - this would otherwise have been determined by deadzones. Trellis biases towards retaining as much detail as possible using as few bits as possible, which is why disabling it, and relying on deadzones instead, can help spend fewer bits on grain.

I should point out that these measures, however, *will* smear out some detail along with the grain, but that's just the price you pay for saving bits on a grainy source. The better a grain removal method, the less effect it will have on wanted detail, so using a dedicated high quality noise filter prior to compression - assuming it's a decent one - will probably give best overall results.

[samtroy]

One more thing I've noticed recently:

When I do NOT use the "--tune film" parameter on my encodings, the required bitrate goes down dramatically:

sample.mkv with --tune film -> 19MBit/sec
sample.mkv without --tune film -> 13MBit/sec

I've also read somewhere that the "--tune film" parameter also helps to preserve film grain (aside from the --tune grain parameter), but I don't know if this is a correct statement. Actually I don't know what *exactly* the film tuning does.

So maybe the easiest way to get rid of the grain is to to just NOT use the --tune film parameter.. :D ??

Any opinions here?

[detmek]

--tune film lowers inloop deblocking from 0:0 to -1:-1 and activates psy-trellis (0.15). Both of those keep a bit more details and grain. Also, with those changes CRF does not measure quality (and needet bitrate) in same way.

[F J Walter]

When I do NOT use the "--tune film" parameter on my encodings, the required bitrate goes down dramatically:

You're confusing matters here.

You cannot compare encodes made using the same CRF with different settings (such as --tune film) because the different settings change what the CRF means. --tune film does not raise the "required" bitrate. It does change the number of bits a given CRF will require. But it also changes the perceptual quality that a certain CRF will give. You'll need to pick a suitable CRF all over again when you change parameters. What you *can* do is compare the two settings with 2-pass using the same target bitrate, to see if you can see the quality improvement when the same target bitrate is used.