x264 options, --qp vs --crf

[ariga]

I'm trying to get a VBR (one pass) encode. Which option should I use ?

I started with x264gui and began experimenting with the command line that it generated.

x264.exe --qp 28 --qpmax 38 --filter 0:0 --analyse all --ref 3 --me umh --subme 6 --b-rdo --bframes 1 --weightb --threads 2 --sar 1:1 --quiet -o video_qp.264 "Video.avs"

After looking at the cli help I changed qp to crf and the video looked very bad.
x264.exe --crf 28 --qpmax 38 --filter 0:0 --analyse all --ref 3 --me umh --subme 6 --b-rdo --bframes 1 --weightb --threads 2 --sar 1:1 --quiet -o video_crf.264 "Video.avs"

[foxyshadis]

"--qp 28 --qpmax 38"?

Anyway, 28 is pretty low, and 38 is very low, it's no wonder it came out looking pretty bad. If you're looking for something with a very small size you're probably better off with 2-pass rate control. --crf doesn't seem to work so well for my minimum-size enocdes either; it seems the harder you push a codec the more leeway you have to give its rate control.

What you should use I have no idea since you don't say what output you want (all video is VBR), what you're encoding, or what encoding speed you want (though your settings are reasonable for all-around encoding).

[DarkZell666]

--qp 28 and --qpmax 38 is indeed very low ...

try 18 to 22 (e.g --crf 18 --qpmax 28)


Actually, --cqp option uses the same quantizer for all P-frames (I is 1.4 times less and B is 1.3 times more by default, see --ipratio and --pbratio)

--crf uses a nominal quantizer, and makes it vary according to the motion present in the scene. In high motions, x264 will raise the quantizer to give the same visual quality than still scenes at the nominal quantizer.

Hence the following conclusion : crf gives rather the same _visual_ quality than cqp but with a smaller filsize.

[nm]

Um, qpmax defaults to 51. Is there really a reason to change that?

[DarkZell666]

Originally Posted by nm

Um, qpmax defaults to 51. Is there really a reason to change that?

to avoid getting too ugly a picture in (very)high-motion scenes =)
But since we are talking about --crf (which doesn't deviate the quantizer than much), the use of --qpmax isn't as helpful as in multipass.

Making --qcomp bigger would give similar results in multipass.

[ariga]

Originally Posted by foxyshadis

Anyway, 28 is pretty low, and 38 is very low

Low as in low quality ?

Originally Posted by foxyshadis

(all video is VBR)

I thought specifying a bitrate produced a CBR ! So it's not absolute bitrate but nominal ?

With DivX I had noticed that when the quant went above 4, the picture quality degraded a lot. How does that value map to qp values in x264 ?

Is there a manual/guide that explanins the cli options ? Like what options work in conjunction and which options are mutually exclusive. Which options make significant improvement in quality/speed. The one line descriptions are good for those familiar with video encoding concepts/developers. The x264 guide explains some of the options that are offered by the gui.

Originally Posted by DarkZell666

qp option uses the same quantizer for all P-frames...
crf uses a nominal quantizer, and makes it vary according to the motion present in the scene..
crf gives rather the same _visual_ quality than cqp but with a smaller filsize.

I'd like to encode with good/high quality in one pass (with "acceptable" size). So I guess crf is what I should be using.

However sometimes it would be necessary to limit the size (if trying to fit on a CD). So I'd have to go for multipass with a specific bit rate? And the qcomp would determine the variation in the bitrate, right ?

EDIT: Just found out that this thread appears to be similar. Found some good links through that.

[pete]

I do one pass encoding, too (analog tv captures / MJPEG). Why do you use only one b-frame? Is there any reason NOT to use 3 b-frames? Most of Sharktooth's profiles use 3 and in my tests it reduces the file size significantly.

And although I read other threads about --qp/--crf, I still don't understand what is better for my situation.

[foxyshadis]

Yeah, 1 isn't bad, but won't really be any better than 10 and might be larger, since the encoder will usually only use 1 or 2 anyway.

DeathTheSheep has an old but still relevant guide going over different ways of achieving high-quality output, as well as going over the options with a more personal touch, so try searching for threads started by him.

If you're trying to hit a specific size bitrate is always the preferred option, which gives VBR too (CBR is actually very difficult to achieve, needs a lot of option tweaking). --crf is when you care about quality and mostly don't care about exact size. As compared to qp, it's when you want most of the video to be nearly as high quality as an equivalent qp but the size to be smaller (because some hi-motion parts are much higher quant and degraded). Certain options affect the tradeoff there, that thread goes over them.

[pete]

I found DeathTheSheep's thread, too bad it's really outdated. I hope someone writes a new guide that explains every x264 option in detail and gives some hints for sane values in different situations.

[nm]

A Doom9 Wiki could be a good idea for these kind of guides that need frequent updating.

[pete]

You could also add this to the wikipedia article:

http://en.wikipedia.org/wiki/X264

[ariga]

Originally Posted by pete

Is there any reason NOT to use 3 b-frames?

I started with 3, but QT wouldn't play it. Similar problems with b-pyramid. I cannot recall now whether it made much difference for the short duration clips I was encoding.

[Yong]

Originally Posted by ariga

I started with 3, but QT wouldn't play it. Similar problems with b-pyramid. I cannot recall now whether it made much difference for the short duration clips I was encoding.

If i recall correctly, QT wont play your x264 video clip if it contain more than 1 b frames and 8x8dct...(because QT doesnt not support High profile and b frames???)

[DarkZell666]

If i recall correctly, QT wont play your x264 video clip if it contain more than 1 b frames and 8x8dct...(because QT doesnt not support High profile and b frames???)

At least I'm sure QT doesn't support high profile at all. Now for bframes is another matter (search the forum, this has already been discussed a couple of months ago). Actually I'd rather live without quicktime, they promote heavy h264 involvement on their behalf but offer the worse implementation of h264 so far Would you be an unlucky Mac owner by any chance ?

As far as bframes are concerned, x264 usually only gives bframes away on low-motion/low-complexity scenes. No matter what the duration of your clip is, if it's near-still motion, bframes is a good idea =) foxshadis is right about x264 not using more than 1 or 2 by default, but you can have a play with the bframe bias (0-100) to force it to use more (which isn't always a good idea).
e.g. : setting bframes to 6 and using a bframe bias of 100 will enforce 6 bframes between 2 pframes

Quote:
Originally Posted by foxyshadis
Anyway, 28 is pretty low, and 38 is very low

Low as in low quality ?

Exactly, sorry for that (doing the same mistake, shame on me lol) It's like XviD/DivX but the scale isn't the same (someone calculated that MPEG4 ASP's quant 2 was equivalent to h264's qp 18, with a formula much too complicated for me )

[Yong]

Originally Posted by DarkZell666

At least I'm sure QT doesn't support high profile at all. Now for bframes is another matter (search the forum, this has already been discussed a couple of months ago). Actually I'd rather live without quicktime, they promote heavy h264 involvement on their behalf but offer the worse implementation of h264 so far Would you be an unlucky Mac owner by any chance ?

Im on Win32 platform
If im unlucky mac user, i will use mplayer osx or other players :P
Now i cant test x264 encoded video clips because i have problem with the stupid quicktime installer
Ive treid play x264 viedo clips + b-frames with QT player(already forgot x264 settings), its play, but jerky.

As far as bframes are concerned, x264 usually only gives bframes away on low-motion/low-complexity scenes. No matter what the duration of your clip is, if it's near-still motion, bframes is a good idea =) foxshadis is right about x264 not using more than 1 or 2 by default, but you can have a play with the bframe bias (0-100) to force it to use more (which isn't always a good idea).
e.g. : setting bframes to 6 and using a bframe bias of 100 will enforce 6 bframes between 2 pframes

If you want to force x264 use max b-frames as specified ,try use --no-b-adapt.
Here can find out more details about x264 encoding options(search for -x264encopts):
http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html

Correct me if im wrong, is that x264 using libavcodec b-frames decision mode?

[DarkZell666]

If you want to force x264 use max b-frames as specified ,try use --no-b-adapt.

True, forgot about that one

is that x264 b-frames decision mode is same as libavcodec?

Don't know about libavcodec itself, but ffdshow (if that's what you meant) uses libx264 to do the h264 vfw encoding apparently :

[Yong]

Sorry, my english is really suck....
I mean, is that x264 "borrow" libavcodec b-frames decision method as its own b-frames decision method?

[ariga]

Originally Posted by Yong

Here can find out more details about x264 encoding options(search for -x264encopts):
http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html

Aaah..