x264: Optimal Settings for Black & White Encoding

[Loomes]

Searching for this topic did not bring up much but a few 5-6 year old very short discussions on the internet with almost no info.

I usually do my x264 color movie encoding using the options --preset veryslow --tune film --profile high "resize:width=1280,height=720" --bitrate 4000 doing a 2-pass. Now I want to encode my beloved Hitchcock collection, containing some movies in black and white. All the movies are on Bluray and resized for saving space. I am quite fine with 1280x720 on my TV if the encoding turned out to be excellent.

What are the best x264 settings for BW encoding?, e.g. to avoid grain effects and maybe save some more space by dropping redundant color info maybe? One good option might be --tune grain, what else is recommended? Encoding time does not matter, saving space is nice to have. Getting an excellent picture is most important. Thanks in advance.

[LoRd_MuldeR]

Don't think you need any special x264 settings for "Grayscale" footage.

But you could use GreyScale() (http://avisynth.nl/index.php/GreyScale) in your source AVS script in order to ensure that any Chroma noise that might be present in the source is eliminated. As soon as the Chroma channels are completely "flattened", they are pretty much no-cost (bit-wise).

Note that "--tune grain" is intended for very high bitrate encodes, where grain can actually be retained - and where the grain will eat up the vast majority of the bits. That's why "--tune grain" reduces AQ strength to ½. Use with care ;)

[F J Walter]

Thankfully there is no need to do anything to encode monochrome video efficiently; x264 will just do that anyway. In particular, the YCbCr color encoding is already tuned to eliminating redundancy in the color channels, so with no color information, the Cb and Cr channels will just be blank.

H.264 does have a rarely used "monochrome mode", also called "4:0:0 mode" where it does not encode the color channels, but that is unnecessary, because the color channels will not really occupy any space when they don't contain any information. Also, not all players will support that mode.

e.g. to avoid grain effects

Can you describe what you mean by grain effects and why it would be relevant to monochrome video?

and maybe save some more space by dropping redundant color info maybe?

This is not necessary because x264 will already see that there is no detail in the color channels and won't spend any bits on them.

One good option might be --tune grain

Why would this be relevant specifically to monochrome video? You mention above you want to *avoid* grain, whereas "--tune grain" tries to *preserve grain* better. If you don't want grain, you'll have to filter it using a decent filter prior to encode. "--tune grain" is a very strong tuning, like a much stronger version of "--tune film", which I tend to avoid but can be used as a last resort for a very grainy source where you want to preserve the uniform appearance of the grain at any cost.

[Boulder]

--no-chroma-me will speed up the encoding slightly.

I'd also recommend cropping the black mattes (and downsizing accordingly) and using CRF instead of a fixed-bitrate 2-pass encode if you are looking to preserve quality. B/w movies often are quite grainy and grain really likes bitrate. 4000kbps could be too little and you might get severe blocking.

[Loomes]

Thanks for your replies so far :) By saying "grain effects" I actually meant "noise" which can be often seen in awfully encoded black and white movies, mostly in the actors faces. "grain" was obviously the wrong term here, also misleading me to the conclusion that the option "--tune-grain" would be a good idea to avoid these noise effects. Sorry for that.

But you could use GreyScale() in your source AVS script in order to ensure that any Chroma noise that might be present in the source is eliminated. As soon as the Chroma channels are completely "flattened", they are pretty much no-cost (bit-wise).

I am not familiar with AviSynth yet but will get into it to try GreyScale(). Is it supposed to be used before x264 processing or afterwards?

I'd also recommend (...) using CRF instead of a fixed-bitrate 2-pass encode if you are looking to preserve quality.

Thats quite contrary to what I have read yet. I thought there would be no better choice than 2-pass encoding to get the best quality? On the other hand I already wondered why the CRF option does only work in 1-pass.

I would like to follow your advice and use CRF but also like to understand why, since 2-pass seems the better process -- what could be better than encoding on the basis of a complete video analysis that was done before? Is there a certain CRF level you would recommend for a 1280x720 BW movie? Like I said, quality rules size here.

[Boulder]

What comes to quality, it's safe to say that a CRF encode that produces video with avg 4000 kbps is equal to the same video being encoded using 2-pass at 4000 kbps.

I personally encode all my 720p (that is, horizontal width of 1280px for 16:9 or 960px for 4:3) material using CRF 18. It usually ends up in 2-6Mbps video depending on the vertical resolution, amount of detail (grain) and movement etc. I have determined this level to be sufficient to my needs by testing several different videos with different CRF values and inspecting the result by comparing to the original material. I found out that 18.5 was enough so I took a small step towards the safe side (in CRF, lower is better) and have been happy ever since then. For 1080p, I could probably do with CRF 19.

[Loomes]

I think I will do some test encoding on a BW movie, comparing CRF 18, CRF 20 and 2-pass 4000.

By the way: Is there a way to see at which CRF level (if even) a video was compressed by examining a MKV container afterwards? I looked with MediaInfo on several MKV files with h264 videos but I can not find any CRF entry at the section "Encoding settings". Is the CRF setting not written to the h264 file?

[jpsdr]

Is it supposed to be used before x264 processing or afterwards?


Before.

About CRF :
Absolutely not. In contrary to bitrate, from what i've understood, crf has no real physical meaning, and you can't measure it afterward. And more, talking of a crf value without providing all the others parameters, has also no real meaning.
And, but only an x264 dev can confirm it, i wouldn't be surprised if the crf algorithm used by x264 is something specific to x264. Maybe another H264 encoder offering the same function (a constant quality encode mode), will have a total different algorithm. But this last part is only a guess/feeling from my part, needed to be confirmed (or denied) by an x264 dev (or someone who know very well x264).

[foxyshadis]

I think I will do some test encoding on a BW movie, comparing CRF 18, CRF 20 and 2-pass 4000.

By the way: Is there a way to see at which CRF level (if even) a video was compressed by examining a MKV container afterwards? I looked with MediaInfo on several MKV files with h264 videos but I can not find any CRF entry at the section "Encoding settings". Is the CRF setting not written to the h264 file?

It'll show up as "rc=crf / crf=16.600" or whatever number. If rc isn't crf, then crf wasn't used.

Really old x264 had an incomplete list of settings, though.

[vivan]

By the way: Is there a way to see at which CRF level (if even) a video was compressed by examining a MKV container afterwards? I looked with MediaInfo on several MKV files with h264 videos but I can not find any CRF entry at the section "Encoding settings". Is the CRF setting not written to the h264 file?It's not a stream characteristic (like bitrate or resolution), it's saved only in "Encoding settings" string as "crf=value", and only if crf encoding was used (not 1/2-pass). CRF encoding is unique to x264, files encoded with other encoders can't have this info (they don't have "encoding settings" section at all). Also custom x264 builds may not write encoding settings.

If file has "encoding settings", check what it says in "rcmode" if it says "bitrate" - that would mean that bitrate-based ratecontrol was used instead of crf.

Maybe another H264 encoder offering the same function (a constant quality encode mode), will have a total different algorithm. But this last part is only a guess/feeling from my part, needed to be confirmed (or denied) by an x264 dev (or someone who know very well x264).Yeah, even in x264 CRF was changing over time (when it was still in active development).

[Boulder]

Forgot to mention that --preset veryslow and --tune film is also recommended to try if you have no problems with the encode time.

[Loomes]

I did some encoding to test and compare the CRF option on a black and white movie. I reviewed the resulting videos on a half year old ASUS PB298Q with a resolution of 2560x1080.

Source:
- MakeMKV BRRip of "Psycho" (1960, Black & White)
- Running Time: 01:48:51
- Resolution: 1920x1080
- Size of VC-1 video file: 25.71 GB
- Max. Peak (Bitrate Viewer): 47.566 kbps

Platform:
- Intel i5-4670K @ 4.0GHz
- 16 GB DDR3
- Windows 10 64bit

Encoder:
- x264-r2638-7599210
- Used Options: --video-filter "resize:width=1280,height=720" --no-interlaced --level 3.2 --vbv-maxrate 8000 --vbv-bufsize 16000 --preset veryslow --tune film --profile high --threads auto --b-pyramid none --no-dct-decimate --qcomp 0.9 --qpmin 3

Results:
1)
x264 options: -crf 18:
-> encoding time: 04:30 h
-> resulting video file size: 6.24 GB
-> bitrate (MediaInfo): 7824

2)
x264 options: -crf 20:
-> encoding time: 04:18 h
-> resulting video file size: 5.91 GB
-> bitrate (MediaInfo): 7419

3)
x264 options: 2-pass -bitrate 4000:
-> encoding time: 04:00 h
-> resulting video file size: 3.18 GB
-> bitrate (MediaInfo): 4000

4)
x264 options: 2-pass -bitrate 6000:
-> encoding time: 04:15 h
-> resulting video file size: 4.78 GB
-> bitrate (MediaInfo): 6000

All the results are pretty good. CRF 18 lead to a (subjectively) identical copy of the original VC-1, while bitrate 4000 did some slighty viewable smoothering to the grain in the actors faces (Psycho is a rather grainy film), but the result of bitrate 4000 is acceptable, most people wont see the difference to the original I guess.
Really wonder made me CRF 20. I expected a significant lower bitrate and lower file size compared to CRF 18. Instead, the difference can be clearly seen when viewing the result -- CRF 20 is only slightly better than bitrate 4000. How can that be?
Bitrate 6000 is what I expected from CRF 20. 6000 is really good but slighty worse than CRF 18.

Since Psycho is a grainy film I maybe should do some more tests with the grain setting of x264 instead of the film preset. You might wonder about the low vbv values: My videos are also supposed to run on tablets and I did some excessive testing months ago. These values are save here to avoid having the video stop when there are peaks in a video.

I appreciate any further suggestions to my x264 settings or feedback to the tests etc.

[Boulder]

Your VBV settings probably cause the small difference in bitrate between CRF 18 and 20. Psycho will require a lot of bits if not restricted, and the low VBV settings will force the bitrate to lower. Don't use --tune grain, --tune film is already optimal for any normal movie, be it grainy or not.

I'd ditch the options "--threads auto --b-pyramid none --no-dct-decimate --qcomp 0.9 --qpmin 3" and let x264 care about those according to the preset you have. Or is the B-pyramid something the tablets don't like?

[Loomes]

I'd ditch the options "--threads auto --b-pyramid none --no-dct-decimate --qcomp 0.9 --qpmin 3" and let x264 care about those according to the preset you have. Or is the B-pyramid something the tablets don't like?
I'll try ditching these options, though qcomp 0.9 was highly recommended on the internet to improve the quality (in trade for longer encoding time). About bpyramid and tablets I dont know. I added this setting afterwards.

[Boulder]

I'd trust the x264 devs since those defaults were set for a good reason. Of course, YMMV as always.

Also, use --no-chrome-me to disable chroma motion estimation (since there is no chroma information).

[foxyshadis]

Qcomp doesn't change the encoding time; what it does is adjust how close to constant quant or bitrate the encoder stays. Don't touch it. VBV compliance is what will slow down the encode by re-encoding frames if you're too close to the limit. Since crf 18 was nearly 8000 in this case, you ended up with an extra half hour encoding time to keep a bunch of frames from underflowing. I bet you're constantly hitting VBV emergency mode on that encode, with pulsing quality, and ending up with a much higher average quant than 18. Pay attention to the final frame stats!

I think you should just leave it at --preset veryslow --tune film (or maybe --tune grain at a high bitrate), and stop trying to change debugging settings. Don't even touch VBV unless you absolutely have to because of hardware limitations, because hardware limitations are the only reason VBV exists.

[Loomes]

I'd trust the x264 devs since those defaults were set for a good reason.

Yeah of course, but I guess when it comes to default presets the devs always have a certain user type in mind, like "the user wants a fair trade off between quality and encoding time" which is absolutely okay, but does not really fit when there is a user like me saying "I want awesome quality and dont care about encoding time." So I thought using --qcomp 0.9 for instance might adjust the preset a bit more to my attitude. But on the other hand, using --preset veryslow might already do that... and one should not become too religious about x264 settings ;)

[Loomes]

Don't even touch VBV unless you absolutely have to because of hardware limitations, because hardware limitations are the only reason VBV exists.
Like I said, the videos also have to run on tablets here. I did some testing months ago and before having every 2nd video get stuck on the iPads several times, I would have never come to the idea messing with the vbv settings. But setting these values really solved it. I also tried higher vbv settings but that did not work out. I ended up with vbv maxrate = 2x bitrate and vbv buffsize = 4x bitrate. With these, no streaming problems anymore on the tablets so far.

I bet you're constantly hitting VBV emergency mode on that encode, with pulsing quality, and ending up with a much higher average quant than 18. Pay attention to the final frame stats!
I have to admit I dont really get that. What do you exactly mean by "pulsing quality", like variations in quality? And what does "paying attention to the final frame stats" mean?

[foxyshadis]

x264 shows stats at the end of every encode about what min/max/average quants you actually hit. If the P-frame stats are way off from your requested quant/crf, then you're running into a wall, usually from VBV, but sometimes also from AQ & psy. Pulsing quality means that in hard parts, every few frames end up super-smoothed or even super-blocky next to frames with good detail, because the VBV can't keep up with handling a bitrate set too close to the limit. It can even happen in the middle of frames, but I think realtime mode has to be enabled for that.

Since your tablet can't play everything, VBV sounds useful. Are you sure 8mbps is the limit? The higher you can go, the better. If it is, then you're basically at 8mbps with anything less than --crf 20, so that's your hard limit for this movie. You should switch to two-pass if you want the bitrate to be about the same as the VBV limit.

[Loomes]

Regarding your comments I simplified the settings and made another test run.

Results:
1) (same as above, listed for comparrison here)
x264 options: -crf 18:
-> encoding time: 04:30 h
-> resulting video file size: 6.24 GB
-> bitrate (MediaInfo): 7824
-> Max. Peak (Bitrate Viewer): 15.705 kbps

5) (new run)
x264 options: -crf 18, new settings: --video-filter "resize:width=1280,height=720" --no-interlaced --crf 18 --level 3.2 --preset veryslow --tune film --profile high --no-chroma-me.
-> encoding time: 03:56 h
-> resulting video file size: 5.70 GB
-> bitrate (MediaInfo): 7449
-> Max. Peak (Bitrate Viewer): 20.603 kbps

Like expected, file size is lower and encoding time is shorter. What I do not like about this is that leaving out the vbv settings produced a higher maximum Peak. This was actually the reason why I did the vbv settings: Tablet streaming got stuck when the video had enormous peaks and I used the vbv settings for reducing those. Is there another way to lower the peaks but with vbv settings?

[Asmodian]

Regarding your comments I simplified the settings and made another test run.

Results:
1) (same as above, listed for comparrison here)
x264 options: -crf 18:
-> encoding time: 04:30 h
-> resulting video file size: 6.24 GB
-> bitrate (MediaInfo): 7824
-> Max. Peak (Bitrate Viewer): 15.705 kbps

5) (new run)
x264 options: -crf 18, new settings: --video-filter "resize:width=1280,height=720" --no-interlaced --crf 18 --level 3.2 --preset veryslow --tune film --profile high --no-chroma-me.
-> encoding time: 03:56 h
-> resulting video file size: 5.70 GB
-> bitrate (MediaInfo): 7449
-> Max. Peak (Bitrate Viewer): 20.603 kbps

Like expected, file size is lower and encoding time is shorter. What I do not like about this is that leaving out the vbv settings produced a higher maximum Peak. This was actually the reason why I did the vbv settings: Tablet streaming got stuck when the video had enormous peaks and I used the vbv settings for reducing those. Is there another way to lower the peaks but with vbv settings?

For high quality video on tablets VBV is necessary, as you found, but do you need to use such a low rate? How about limiting max rate to 15000 instead? The larger peak is exactly what VBV is designed to prevent, but x264 needed that peak to get the quality so lowering peaks will lower the quality.

A setting you haven't used that is actually a simple speed for quality trade off (unlike qcomp) is --no-fast-pskip. This is only activated by the placebo preset but it is much less of a speed hit compared to some other options used in placebo. I use --no-fast-pskip in combination with --preset veryslow when I want a "superslow" preset, a bit slower than veryslow but still much faster than placebo. I have noticed the improvement in quality/size when testing, but it is a minor improvement.

I also want to reiterate that qcomp is NOT a speed for quality option at all. It is a rate control option, changing it can improve quality when using crf but it also changes the size a lot! Almost always using a lower crf and the default qcomp will result in better quality/size than raising qcomp with the same crf. Only when already using very low crf values (e.g. 12) does messing with qcomp sometimes make sense.

Lowering qcomp will lower peaks at the cost of making the scenes that need more bitrate look worse and the scenes that need less look better. Usually this is not a good tradeoff as the average apparent quality goes down; the hard scenes lose more quality than the easy scenes gain.

[~ VEGETA ~]

Well, I suggest looking into the commands further rather than relying on some tune settings. I never use tune.

I didn't see your source, but if it is like you say without grain and stuff like that... then this is going to help a bit:

use x264-tmod version...

--preset veryslow --crf 18 --aq-mode 3 (mode 2 can save a lot of size here!) --aq-strength 0.7 --ref 16 (or lower if you like) --bframes 10 (or higher).

try these for now, and then modify them to your needs. Just don't rely on any tune settings and preferably no pre-defined bitrate.

[sneaker_ger]

Vanilla x264 does have --aq-mode 3 as well, no need to use an outdated mod.

[jpsdr]

I've been able to continue to update the t_mod version, and also include some features of the 7mod here (https://github.com/jpsdr/x264).