1 Pass CRF.... am I doing it wrong?

[nibus]

Up until now I have been encoding 720p and 1080p to fit on optical media, so I've been using two-pass encoding. I thought I'd give CRF a try because I'm tired of encodes taking days to finish...

From what I've read, most people say CRF 18-23 provides very good results.

When I encode a 720p sample at CRF 18, the resulting file has absolutely terrible quality and Bitrate Viewer reports an avg bitrate of only 1277 kbps. As a general rule I like to keep 720p encodes at around 5000kbps.

In order to achieve the same bitrate and quality with CRF, I have to lower the value all the way down to around 12! Is this common, or am I doing something wrong here?

The file sizes are about the same and the quality is very close, but I'm wondering why the "18-23" general consensus is giving me such poor results and such low bitrate.

x264 command line:

program --preset slower --tune film --crf 12 --bframes 8 --output "output" "input"

I am using the latest x264 revision and MeGUI build.

thanks in advance!

[nm]

When I encode a 720p sample at CRF 18, the resulting file has absolutely terrible quality and Bitrate Viewer reports an avg bitrate of only 1277 kbps. As a general rule I like to keep 720p encodes at around 5000kbps.

Give us a sample clip (and the source clip too, if possible). Otherwise we don't know what your "terrible quality" means.

x264 encoding log could also help.

[JEEB]

CRF is not magic. There's no formula to really keep a certain quality with whatever source. CRF is the closest to such on the free encoding tools' side, though, as far as I know.

The 18-23 range is nothing more than the range where most people are mostly completely fine with the result on most sources. Of course, sooner or later, you will find that some source will need a number of different caliber to please your eye. As such, CRF is a setting you set per-source (when you are dealing with lots of similar content, you can usually use the same, or very similar settings on them).

How much of such calibration is needed depends on the person's perception of quality and what that given person is striving to make.

[Blue_MiSfit]

I'd be very surprised if CRF 18 isn't producing excellent quality! It might not be "perfect" in some cases, but I've yet to see a case where it created terrible quality! Perhaps your source is pathological, or your settings weren't what you think they were :)

So yes, source sample pls.

Derek

[nibus]

Thanks guys, I'll post a sample when I get home later this evening.

[Lorax2161]

I agree with Blue_MiSfit re: settings maybe not being what you thought they were.

Easy way to eliminate that possibility is a test encode via the command line. Are the results the same as when you used the GUI? If not, you have your answer.

I used GUIs in the beginning, and I'm grateful to their developers because I learned a lot from their programs. But since that time I've learned how to use the command line and write some simple batch scripts, and I'm very glad I did.

[nibus]

I agree with Blue_MiSfit re: settings maybe not being what you thought they were.

Easy way to eliminate that possibility is a test encode via the command line. Are the results the same as when you used the GUI? If not, you have your answer.

I used GUIs in the beginning, and I'm grateful to their developers because I learned a lot from their programs. But since that time I've learned how to use the command line and write some simple batch scripts, and I'm very glad I did.

Would you mind sharing a couple of your batch scripts so I can have an idea of where to start? I've been wanting to switch to command line for a while, and have already done so with my audio tracks but not video yet.

[nibus]

Okay, here is the sample I've been working with. I cut down the 1080p original because the file was too large (thats why the crf-18 sample is longer):

Source:

http://dl.dropbox.com/u/5637223/sample2.demuxed.264

Encoded at CRF 18 (Slower profile, 8 b-frames). Pay close attention to the blue gradients as the door opens. Lots and lots of blocking.
http://dl.dropbox.com/u/5637223/crf18.mkv

Bitrate viewer reports an avg bitrate of 1277:
http://dl.dropbox.com/u/5637223/bitrate.jpg

[Dark Shikari]

I can't see anything unless I freeze-frame it and zoom in really closely. If you're complaining about the tiny bit of banding, it's impossible to completely eliminate banding at sane bitrates unless you're willing to run gradfun2db() on playback... in which case it's trivial and costs nothing. Another method is to use --no-dct-decimate and a much higher AQ strength (1.5 or 2.0). But really, I can't even see it unless I go looking.

The quantizer in the area of the frame you're complaining about? 15.

[Blue_MiSfit]

Indeed.

Since you're feeling like you have bits to spare, add some noise / dither ahead of time, increase AQ strength, maybe enable --no-dct-decimate, and use a very low CRF, like 14 or something.

As long as I'm below 25mbps ABR (BluRay), I'm pretty much cool with spending bits up the wazoo :)

Derek

[nibus]

Thanks for the suggestions Shikari and Misfit... I'll try --no-dct-decimate and increase AQ and give it another shot.

[Blue_MiSfit]

Make sure to add some dither before encoding! I suggest gradfunkmirror(1.51), or possible GrainFactory3(g1str=3, g2str=5, g3str=6) or something like that.

Derek

[Lorax2161]

@nibus

In answer to your original question "...am I doing this wrong?" using the command line w/x264 allows you to eliminate the GUI part of your process to see if that was the cause of your encoding concern, and here is one way you can automate this. (Very basic just to get you started.)

rem x264 one pass batch encode

x264.exe my_script.avs --crf 18 --preset slow --tune film --output "my_one_pass_test_crf18.mkv"

rem x264.exe my_script.avs --crf 20 --preset slow --tune film --output "my_one_pass_test_crf20.mkv"
rem x264.exe my_script.avs --crf 22 --preset slow --tune film --output "my_one_pass_test_crf22.mkv"

pause

I remarked out two other encode commands with different settings (and most importantly) different output names. Enabling them would allow you to do several tests in one batch, and give them each a relevant name.

A two pass version might look like this:

rem x264 two pass batch encode

x264.exe my_script.avs --pass 1 --bitrate 1500 --preset slow --tune film --output nul --stats "test.stats"

x264.exe my_script.avs --pass 2 --bitrate 1500 --preset slow --tune film --output "my_two_pass_test_br1500.mkv" --stats "test.stats"

pause

The "pause" is to prevent the command line window from closing before you have had a chance to review the log. It is optional.

[nibus]

thanks for posting that Lorax!

@Misfit -

Should I just add one of those filters to my .avs before denoise?

[Blue_MiSfit]

Why are you denoising if you're complaining about x264 not using enough bits? :)

Noise hides banding, and can hide blocking.

So, either don't denoise at all, or (if your source really needs denoising), dither AFTER denoising.

Derek

[RunningSkittle]

The [strong] banding is certainly caused by your denoising, I did a test with just resize and crf 18 and the result looked great.

[nibus]

Why are you denoising if you're complaining about x264 not using enough bits? :)

Noise hides banding, and can hide blocking.

So, either don't denoise at all, or (if your source really needs denoising), dither AFTER denoising.

Derek

The [strong] banding is certainly caused by your denoising, I did a test with just resize and crf 18 and the result looked great.


Yeah I just came to the same conclusion myself. I lightened the denoising and used the suggestions provided here and the results are very good now at about CRF 17. :)

[foxyshadis]

I'm not sure what you use to denoise, but try the new dfttest - it includes a built-in dither option now that makes gradients look spectacular even with very strong denoising.

[nibus]

I'm not sure what you use to denoise, but try the new dfttest - it includes a built-in dither option now that makes gradients look spectacular even with very strong denoising.

nice, I'll give that a shot! I've been using MVDegrain1/2.

[tormento]

The problem of DFTTest is speed, it's the only thing that keeps me away from using it in usual encoding.

[nibus]

The problem of DFTTest is speed, it's the only thing that keeps me away from using it in usual encoding.

What settings do you use for most film?

So far this

dfttest(dither=2,sigma=6,sigma2=6)

Looks very good on my sources, but I'm not great at sifting through readme's and code in general.

[tormento]

Looks very good on my sources, but I'm not great at sifting through readme's and code in general.
How many FPS do you get on 1080p contents?

[nibus]

How many FPS do you get on 1080p contents?

I used it in conjunction with other filters so I can't say how it performs by itself. But with MVDegrain and LSFMod I was getting about .75 fps on 1080p. (but with very high x264 settings)

Later tonight I'll try just dfttest by itself with standard x264 settings and let you know. I'm running an i7 930 w/6gb ram.

At .75fps it rounds out to over 2 days for one 1080p movie. But man... it looks amazing.

edit:

here are some stats on a Core 2 Duo T7700 w/4gb DDR2:

1080p, default x264 settings CRF 16: ~.5 fps
720p, default x264 settings CRF 16: ~1.1 fps

Using these settings:
dfttest(dither=2,sigma=6,sigma2=6)

[nibus]

How many FPS do you get on 1080p contents?

With x264 default settings / CRF 16 and:

dfttest(dither=2,sigma=6,sigma2=6,tbsize=3)

I get right around 2 fps with 60-75% CPU utilization.

Running on an i7 930 w/6gb ram.