What is the meaning of q=26 ? [Archive]

lenouch

18th January 2006, 19:55

Hi folks :)
I come to x264 after a few years of xvid encoding. So, I tried to make some "quality tests" equivalent to the famous constant quantizer = q2 from Xvid.

On x264, is q=26 equivalent ? I have read some posts talking about contquant=26. Is that the same meaning than xvid q2 ? If not, what is the equivalent ?

Thanks :)

Sharktooth

18th January 2006, 19:57

~ 18.

lenouch

18th January 2006, 20:07

Do you think that the same "rule" as xvid can be used ?
Ex: final_size = 0.8 (or 0.75) x size(q=18)

And does q=26 mean something special ? This is also the default value constant quantizer when opening ConstantQuant item.

Sorry for my dummy questions but I don't know how works x264 codec :)

Sharktooth

18th January 2006, 23:21

26 is the default, just that.
That rule is good (and not always) for xvid and maybe for very similar codecs but h.264 (x264) is completely different.
Just try until you find a satisfying "rule" or method.

Igor Kharchenko

19th January 2006, 09:08

Some time ago I found this information (sorry I don't remember author):

[quote begin]
about comparing quantizers, this might help:

Quote:
The mapping is approximately H264QP = 12 + 6*log2(MPEGQP). For example, MPEG at
QP=2 is equivalent to H.264 at QP=18.

source: http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.txt
[quote end]

I calculate some values:
2 18,00
3 21,51
4 24,00
5 25,93
6 27,51

lenouch

19th January 2006, 11:13

Waouw ... I performed some quick tests with this. The input sequence is 2 min from PAL version of Gladiator (input reso is 704x432 anamorphic)

with profile CE-Baseline, MKV size is 68537KB => bitrate is about 4.570 kb/s
with profile CE-Main, MKV size is 52110KB => bitrate is about 3.470 kb/s

It's about 24% less (but encoding time is x2.5 !) Is this gain only linked to CABAC ?

Anyway, it looks very high for "eq q2" non ?

And then, what's the difference between "const quantizer" and "const quality" ? In both cases, a quantizer is asked.

Caroliano

19th January 2006, 16:01

And then, what's the difference between "const quantizer" and "const quality" ? In both cases, a quantizer is asked.
Search for -crf for constant quality. It use the same rate control of 2pass, giving an higher quantizer for high motion and an lower quantizer to low-motion, but it is only 1-pass. So the quantizers vary, but the perceived quality shoud remain the same.

lenouch

19th January 2006, 16:30

Search for -crf for constant quality. It use the same rate control of 2pass, giving an higher quantizer for high motion and an lower quantizer to low-motion, but it is only 1-pass. So the quantizers vary, but the perceived quality shoud remain the same.

If bitrates fluctuates more, but average bitrate is constant, I suppose that perceived quality is better no ?

slavickas

19th January 2006, 16:37

Waouw ... I performed some quick tests with this. The input sequence is 2 min from PAL version of Gladiator (input reso is 704x432 anamorphic)

with profile CE-Baseline, MKV size is 68537KB => bitrate is about 4.570 kb/s
with profile CE-Main, MKV size is 52110KB => bitrate is about 3.470 kb/s

It's about 24% less (but encoding time is x2.5 !) Is this gain only linked to CABAC ?

...
not only CABAC, B frames too, but probably most B frames size reduction comes from PBratio as B frames gets higher quantizers

Caroliano

19th January 2006, 18:05

If bitrates fluctuates more, but average bitrate is constant, I suppose that perceived quality is better no ?
I don't said nothing about bitrate. Bitrate in --crf mode shoud fluctuate less than in --cq mode and aproximately the same as in 2-pass mode. But you don't have any average bitrate specified. It is constant quality, not ABR.

And I was not comparing the perceived quality between the two modes, but inside --crf it self. If you compare this to --cq mode, you shoud have an better perceived quality to the same bitrate AFAIK.

OvejaNegra

19th January 2006, 18:47

Caroliano

19th January 2006, 21:49

i think this is interesting
I encoded Ocean´s eleven 720x288 25fps with this:
Xvid 1.1 Q=2 + Qpel+ GMC + MPEG quantization+ + bframes + all reamain settings at max
and with this x264.exe --qp 22 --ref 5 --mixed-refs --no-fast-pskip --bframes 2 --b-rdo --weightb --nf --subme 7 --analyse all --8x8dct --me esa --progress --no-psnr
Acording to the Igor Kharchenko table, x264's q22 is equivalent to Xvid's q3, and not q2. I think that this is right also. So the results are not comparable.

As of your x264 comandline, --me esa is a waste. The defauts are already good, and if you want any more than that go to --me umh. And what is --nf?

lenouch

19th January 2006, 22:02

i think this is interesting
I encoded Ocean´s eleven 720x288 25fps with this:
Xvid 1.1 Q=2 + Qpel+ GMC + MPEG quantization+ + bframes + all reamain settings at max
and with this x264.exe --qp 22 --ref 5 --mixed-refs --no-fast-pskip --bframes 2 --b-rdo --weightb --nf --subme 7 --analyse all --8x8dct --me esa --progress --no-psnr

The result was:

Xvid: 1.4 GB
X264: 736 MB

Any Opinion? (Screen shots will come soon, sorry for my english)

Let try q18

OvejaNegra

20th January 2006, 18:00

well.... my results .. are only results. Not for compare of any kind.
When i encode with a fixed quantizer if i use exhaustive 16 the files are smallers and i don´t care the compression time.

yesterday i try Q=20 and the resulting filezise was 1.03 GB

-nf = disable loop filter (i use it only for anime)

i´ll try Q=18 so the results will be useful for compare.

sorry for my bad english

Multimon

20th January 2006, 23:13

If you really want max. quality without caring about time you can use more ref frames (max. 16) and you could consider using ME range 32.

Both should have less impact on speed and probably help quality more than me esa. (and combined with esa they should be as slow as x264 will get in CQ;) )

However I've never really tested that, on my XP 3200+ me esa is just too slow for my needs and I even hardly ever use umh.

Caroliano

20th January 2006, 23:34

Also --bime and trellis. Even trellis level 2 has a better speed/quality tradeoff than esa...

And a bit of inloop filter (even if it is -6\-6) is good IMHO. H.264 was made to work with in-loop.

Multimon

21st January 2006, 00:18

Does trellis help with CQ? I thought it was made for better bit allocation for a given bitrate (trade a little quality loss here for visibly more quality there)?
If that's the case it would probably reduce the filesize, but the quality would also be lowered a little. (and it would need more time)

I don't know if you would even be able to spot any difference without inloop and with inloop -6/-6 at those quants.
Even if it's mostly a matter what you like better:
Maybe a few artifacts but definitely no loss of detail from the filter,
or a smoother picture with very little loss of detail (probably even none).
I would also go for no artifacts as I will never look so close to notice the detail loss...

akupenguin

21st January 2006, 02:03

Does trellis help with CQ? I thought it was made for better bit allocation for a given bitrate (trade a little quality loss here for visibly more quality there)?
Trellis is not bit allocation. It's rate-distortion optimization.

Ratecontrol is independent of all other encoding options. Any option that improves quality/compression under one ratecontrol method will help equally under all other methods. This applies even to the options that are about bit allocation, like AQ.

Multimon

21st January 2006, 02:22

k, sorry then I mixed it up and thx for the explenation!

But it is correct that bit allocation options may actually reduce the quality of a CQ encode, because the bits they safe on the easy frame X can't be used at the difficult frame Y, so the slight (probably unnoticeable) quality loss on frame X only lowers the filesize? At least that's what I (think I) experienced with Xvid and AQ...

akupenguin

21st January 2006, 05:10

The goal of any codec, and any option in any codec, is to maximize quality per bitrate. Reducing filesize is exactly the same as increasing quality. The only thing that makes CQP mode different from anything else is that you didn't even tell it what bitrate you want. If you didn't want a smaller file, you wouldn't be using H.264.

http://forum.doom9.org/showthread.php?p=771602#post771602

OvejaNegra

26th January 2006, 19:13

ok, today i´ll make the q=18 test,
tomorrow wait the results and i´ll try some other things (like 16 ref and ME range 32)
ATM i wont try loop filter or trellis, please wait for the test of today....

be patient

sorry for my english

OvejaNegra

28th January 2006, 01:24

OK: The RESult: 1.49 GB
Allmost the same as Xvid, but the visual quality (with my eyes ;-) is very superior. Even the grain of the movie is preserved (with Q=20 too but not the same amount). So in terms of size, YES is allmost the same, but the quality is superior than Xvid with Q=2. Of course, i don´t have your eyes. Next week i´ll try some other things.

The settings (i did not change anything than the q)

x264.exe --qp 18 --ref 5 --mixed-refs --no-fast-pskip --bframes 2 --b-rdo --weightb --nf --subme 7 --analyse all --8x8dct --me esa --progress --no-psnr

Bye ;-)

MeteorRain

30th January 2006, 05:52

I would recommend adding the useful infomation in this thread, about the quantizer between XviD and x264, into x264 FAQ.