View Full Version : Difference between -qp and -crf?
_leech_
17th November 2006, 01:50
Could someone explain the difference between how -qp and -crf work? Usually when I do one-pass encodes I use -qp, would -crf offer an advantages?
Thanks.
Audionut
17th November 2006, 05:02
Use search.
_leech_
17th November 2006, 07:51
Use search.
I would, but the forum doesn't allow searches of 3 characters or less.
quake74
17th November 2006, 08:33
Quoting from http://mewiki.project357.com/wiki/MeGUI_FAQ
What's the difference between Constant Quantizer and Constant Quality
These two modes are variations on the generic idea of "unknown filesize/bitrate, known quality" where the encoder aims to encode to a specified quality level. This is opposed to the normal "known bitrate/filesize, unknown quality" model where the encoder is given an average bitrate and must produce the best file possible with that. The advatage of the former is obviously that the quality can be precisely set, while the latter allows precise filesize control. Which one is right for you is your decision. Note that a 2pass encode to the same bitrate will look better.
In x264, there are two modes of "known quality", Constant Quantizer (CQ) and Constant Quality (aka CRF, Constant Ratefactor).
* Constant quantizer: every frame is encoded with a mathematically identical quantizer. Constant quantizer produces a file that for the x264 program is of perfect constant quality (it would be 'interpreted' in a similar fashion by other video encoder programs).
* Constant quality (aka constant rate factor): the video is encoded to a nominal quantizer, but the encoder varies the quantizer on different frames to give a higher percieved quality for human eyes. The output will be the same size as a CQ encode, but it will look subjectively better to humans and is therefore generally the more used of these two modes.
Manao
17th November 2006, 09:04
Some amendments must be made to that :The output will be the same size as a CQ encodeNo. It's true statistically speaking ( the CRF scale was chosen roughly to match to QP scale ), but it will most probably give different sizes on a given video.Constant quality (aka constant rate factor)Instead of constant quality, I'd call it "constant quality/bitrate tradeoff" : it will most probable degrades a little very complicated scenes in order to improve a lot very easy scenes.
bananacreamandpeca
5th January 2007, 20:27
What does it mean when I encoded a video with -qp20, the bitrate
went through the roof (filesize 660MB 8000+ kbps for 10min.)
But when I encode the same source with -crf20, the output = 420MB?
Manao
5th January 2007, 20:35
The principle of CRF XX.X is : if it's a "complicated" scene, the quantizer will be over XX.X, if it's a "simple" scene, the quantizer will be under XX.X.
In your case, CRF 20 gives a smaller size than QP 20, so it means your video was "complicated".
bananacreamandpeca
6th January 2007, 10:17
The principle of CRF XX.X is : if it's a "complicated" scene, the quantizer will be over XX.X, if it's a "simple" scene, the quantizer will be under XX.X.
In your case, CRF 20 gives a smaller size than QP 20, so it means your video was "complicated".
This doesnt make sense.
If my video were complicated, -crf would've bumped the bitarte all the way.
But now I got a smaller filesize?
Manao
6th January 2007, 10:27
What doesn't make sense ? With what part of my post are you disagreeing ? The principle of CRF ? Or the reasoning "CRF 20 smaller than QP 20 --> average quantizer for CRF 20 > QP 20 --> the video was complicated" ?
bananacreamandpeca
6th January 2007, 11:09
Doesn't quantizer mean that the higher the value the more compression a video gets?
So this:
The principle of CRF XX.X is : if it's a "complicated" scene, the quantizer will be over XX.X, if it's a "simple" scene, the quantizer will be under XX.X.
Should be the other way around?
Why would CRF higher the quantizer value when a scene gets complicated?
Manao
6th January 2007, 12:29
Here is why :
- The more complicated the scene, the more bitrate it takes - at the same quantizer - relatively to a more simple scene.
- Bitrate saving when raising the quantizer from Q to Q+1 is (in average) 12% of the bitrate at quantizer Q.
- So when you raise the quantizer by one on a complicated scene, you save more bitrate than if it was on a simple scene.
- And when you lower the quantizer on a simple scene, it costs less bitrate than if you were lowering it on a complicated scene.
So lets say you have a simple scene followed by a more complicated scene that takes twice the same amount of bitrate at the same quantizer. Both scenes last as long ( duration of a scene : T ).
You start at a quantizer Q for both scene. It gives you a size S = T * B (simple scene) + T * 2 * B (complicated scene, twice the bitrate, same duration) = 3 * T * B.
Now, you raise the quantizer by 1 for the complicated scene. That lowers its bitrate by 12% ( of 2 * B ), so now the size is 2.76 * T * B. You saved 0.24 * T * B, which you can put in the simple scene, raising its bitrate by 24%. 24% increase bitrate amounts almost to lowering the quantizer by 2.
So, you end up with a simple scene with Q-2, and a complicated scene with Q+1. The average quantizer is lower ( Q - 1/2 ), though that doesn't necessarily mean it's better.
bananacreamandpeca
6th January 2007, 14:08
Didn't knew that x264 CRF mode will actually yield less bits to/lower the quality of a complicated scene.
And give more bits to a less complex scene.
Wich mode drops the bitrate for a les complicated part and raises the bitrate for a complicated part of the video?
Sounds so illogical.
Manao
6th January 2007, 14:16
It doesn't give complicated scenes less bits ( than simple scenes ). Taking again my example, the complicated scene, though encoded with a higher quantizer, gets a bitrate of 1.76B, while the simple scene has a bitrate of 1.24B. With constant quantizer it would have been 2B and 1B.
Furthermore, from a psychovisual point of view, artifacts on complicated scene are more easily hidden by the complexity of the scene itself. For example, a lack of details in high motion scene doesn't matter that much.
bananacreamandpeca
6th January 2007, 14:25
OK. i'll re-read it all see if I can grasp it.
BTW. When you have lots of smoke/when something explodes and theres lots of dust falling.
This could also be seen as a high-action scene right?
Bit giving this scene less detail will result in artifacts being clearly visible (?)
I run into that roblem right now. And I dont know if I should bump the bitrate or use some deblocking before encoding of some sort.
sjchmura
6th January 2007, 16:50
THanks for the primer - glad I read this:
So CRF seems like a good tradeoff for 1-pass encodes if you don't really care about filesize.
The "profiles" in MEGUI for CRF are only for ASP. Has anyone made a profilefor CRF/AVC to play with the settings?
Manao
6th January 2007, 17:10
CRF exists only in x264. So I guess you're mistaken between ASP/AVC and the profile's denomination.
foxyshadis
6th January 2007, 17:16
The "profiles" in MEGUI for CRF are only for ASP. Has anyone made a profilefor CRF/AVC to play with the settings?
ASP doesn't have CRF, you might be confusing it with the "equivalent of ASP's q2" profile. Any of the profiles can be switched from 2 pass to CRF, quite simply. Under 20 it should be transparent, over 30 it's ugly, and between those are your trade-off range.
WorBry
26th March 2007, 11:36
My standard approach to MPEG-4 encoding of deinterlaced/denoised DV has always been to run a compression test (10-20% depending on the source) in CQ mode (typically DivX 6 (Insane; I like to watch paint dry) at Q2.67 without B-frames for 25p and XviD at Q2.35 - 2.5 with B-frames (usually 1, sometimes 2) for 50p encodes), note the bitrate and then encode in 2-pass mode at that bitrate or thereabouts.
Applying the same principle to x264 encoding, from a theoretical standpoint, is it preferable to perform a compression test in Constant Quant or 'Constant Quality'(crf) mode? I'm assuming from the above discussion, that the consensus would be the latter?
Cheers.
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.