Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 25th August 2014, 16:35   #1  |  Link
samtroy
Registered User
 
Join Date: Aug 2003
Posts: 95
x264: Grainy films - Higher CRF or NR parameter??

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.

Last edited by samtroy; 25th August 2014 at 18:39.
samtroy is offline   Reply With Quote
Old 25th August 2014, 17:50   #2  |  Link
videoh
Registered User
 
Join Date: Jul 2014
Posts: 562
It's up to you. Do you want to retain that grain or not? We can't tell you what you should prefer esthetically.
videoh is offline   Reply With Quote
Old 25th August 2014, 18:37   #3  |  Link
samtroy
Registered User
 
Join Date: Aug 2003
Posts: 95
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..
samtroy is offline   Reply With Quote
Old 25th August 2014, 21:43   #4  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,928
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...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 25th August 2014 at 21:49.
LoRd_MuldeR is offline   Reply With Quote
Old 26th August 2014, 01:44   #5  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,623
Quote:
Originally Posted by LoRd_MuldeR View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Instant Video

My Compression Book

Amazon Instant Video is hiring! PM me if you're interested.
benwaggoner is offline   Reply With Quote
Old 26th August 2014, 02:02   #6  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,928
Quote:
Originally Posted by benwaggoner View Post
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".
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 26th August 2014, 03:18   #7  |  Link
CarlEdman
Registered User
 
Join Date: Jan 2008
Posts: 185
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.
CarlEdman is offline   Reply With Quote
Old 26th August 2014, 20:16   #8  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,257
I usually find MDegrain3 a bit too strong/smooth so I prefer MDegrain2, MDegrain3 does remove almost all the grain though.
Asmodian is offline   Reply With Quote
Old 27th August 2014, 14:05   #9  |  Link
samtroy
Registered User
 
Join Date: Aug 2003
Posts: 95
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"..
samtroy is offline   Reply With Quote
Old 27th August 2014, 15:15   #10  |  Link
CarlEdman
Registered User
 
Join Date: Jan 2008
Posts: 185
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.
CarlEdman is offline   Reply With Quote
Old 4th September 2014, 08:10   #11  |  Link
F J Walter
Registered User
 
Join Date: Oct 2007
Posts: 47
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).

Last edited by F J Walter; 4th September 2014 at 08:13.
F J Walter is offline   Reply With Quote
Old 4th September 2014, 08:18   #12  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,120
--tune grain seems to do the opposite, i.e. reduce --deadzone-inter and --deadzone-intra while not touching trellis.
sneaker_ger is offline   Reply With Quote
Old 4th September 2014, 08:55   #13  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,357
Yes, but as I understand --tune grain aims at grain retention rather than grain removal...
Sharc is offline   Reply With Quote
Old 4th September 2014, 10:20   #14  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,120
Good point.
sneaker_ger is offline   Reply With Quote
Old 4th September 2014, 14:47   #15  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,173
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.
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 4th September 2014, 18:26   #16  |  Link
samtroy
Registered User
 
Join Date: Aug 2003
Posts: 95
OK guys, thanks again for all your input and thoughts.
samtroy is offline   Reply With Quote
Old 5th September 2014, 02:07   #17  |  Link
F J Walter
Registered User
 
Join Date: Oct 2007
Posts: 47
Quote:
Originally Posted by sneaker_ger View Post
--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.

Last edited by F J Walter; 5th September 2014 at 02:11.
F J Walter is offline   Reply With Quote
Old 8th September 2014, 13:13   #18  |  Link
samtroy
Registered User
 
Join Date: Aug 2003
Posts: 95
"--tune film" preserves grain?

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

Any opinions here?
samtroy is offline   Reply With Quote
Old 8th September 2014, 14:36   #19  |  Link
detmek
Registered User
 
Join Date: Aug 2009
Posts: 475
--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.
detmek is offline   Reply With Quote
Old 10th September 2014, 02:28   #20  |  Link
F J Walter
Registered User
 
Join Date: Oct 2007
Posts: 47
Quote:
Originally Posted by samtroy View Post
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.

Last edited by F J Walter; 10th September 2014 at 02:33.
F J Walter is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:46.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.