View Full Version : Quantizers
atreya2011
12th February 2004, 15:22
Another novice (or newbie) question from me. I have this simple question and, thanks in advance, to the kind people who would answer it. Here goes:
1. What's a quantiser?
2. How does that number actually determine the compression of I frame,
P-frame, B-frame?
I mean what kind of mathematical equation is used to determine the filesize of the I frame , P frame, B frame?
(lower quantiser=good quality, higher quantiser=poor quality?)
Sorry if this is a repetition, but time constraints hamper me from searching this forum and using its full potential. If anyone can help me with references to other threads, thanks in advance, for that too.
:)
sysKin
12th February 2004, 16:06
http://www.cmlab.csie.ntu.edu.tw/cml/dsp/training/coding/jpeg/jpeg/encoder.htm
http://www.ece.purdue.edu/~ace/jpeg-tut/jpgquan1.html
http://www.mpeg.org/MPEG/MSSG/tm5/Ch7/Ch7.html
http://www.acm.org/crossroads/xrds6-3/sahaimgcoding.html
...and so on
atreya2011
13th February 2004, 16:06
Cool Thanx a lot, will look into those...
atreya2011
13th February 2004, 16:34
I seem to get it, I think, although I am more confused than before now. A more simpler explanation would help... Thanks to anyone who replies
mf
13th February 2004, 16:45
*VERY* simple explanation: the image is converted to detail signals (DCT), and then those signals are divided (coefficient cutting) to make it smaller. The more signal you cut off, the more detail you lose and more artifacts (blocks, ringing aka mosquitoes) you get. The quantizer is the detail removal factor (DivX3/Nandub thus calls quantizers DRF). The higher the quant, the more detail gets cut off, the lower quality.
atreya2011
13th February 2004, 16:54
That makes sense now. So DRF in DivX 3 is Quantizer in XviD. Thanks for the info. By the way, mfToon is amazing, all the animes I have ripped so far look damn good. Although the encoding process is going at 4 FPS!!! damn slow man... :(
crusty
13th February 2004, 20:57
http://www.cmlab.csie.ntu.edu.tw/cm...peg/encoder.htm
http://www.ece.purdue.edu/~ace/jpeg-tut/jpgquan1.html
http://www.mpeg.org/MPEG/MSSG/tm5/Ch7/Ch7.html
http://www.acm.org/crossroads/xrds6...aimgcoding.html
Damn, I think I'll add those to my FAQ. They're good.
Added c3a to my faq : what is a Quantization Matrix? :)
atreya2011
14th February 2004, 07:45
In Advanced Options....
Min I frame Quantizer=1
Max I frame Quantizer=31
Min P frame Quantizer=1
Max P frame Quantizer=31
31 gives the worst quality possible, so why let it be 31 when the codec is gonna choose only max quantiser=6 anyways?
Thats what I have noticed when I am ripping...
Neo Neko
14th February 2004, 08:26
It's quite simple really. On slow or static screens the video can be compressed with a quantizer of 31 for some frames with very little real quality loss. But only on relatively long sceens with almost no difference between frames. Like perhaps watching paint dry.
Prettz
14th February 2004, 08:26
Originally posted by atreya2011
In Advanced Options....
Min I frame Quantizer=1
Max I frame Quantizer=31
Min P frame Quantizer=1
Max P frame Quantizer=31
31 gives the worst quality possible, so why let it be 31 when the codec is gonna choose only max quantiser=6 anyways?
Thats what I have noticed when I am ripping...
Well for one thing, imagine if you have a few seconds of solid black in your video. If it uses quant 31, you lose nothing but gain a whole lot of space. I've seen the quant go all the way up to 15 and never noticed a single scene in that video where it looked like it was quantized too high. It's best just to leave the max quantizer alone.
sysKin
14th February 2004, 08:54
Originally posted by Prettz
Well for one thing, imagine if you have a few seconds of solid black in your video. If it uses quant 31, you lose nothing but gain a whole lot of space. I've seen the quant go all the way up to 15 and never noticed a single scene in that video where it looked like it was quantized too high. It's best just to leave the max quantizer alone. Nah, you wouldn't gain anything - black is black, not-coded blocks are not-coded.
The quants are not restricted *because* two-pass will use them wisely. Yes, they can be restricted and it wouldn't change much (for exaple, 2-10 restriction) but it doesn't mean we should restrict them.
atreya2011
14th February 2004, 09:02
Originally posted by sysKin
Nah, you wouldn't gain anything - black is black, not-coded blocks are not-coded.
The quants are not restricted *because* two-pass will use them wisely. Yes, they can be restricted and it wouldn't change much (for exaple, 2-10 restriction) but it doesn't mean we should restrict them.
Since it would'nt change much, why should'nt I restrict them. What do you mean by "two pass will choose them wisely"...
mf
14th February 2004, 10:48
If a frame is low complexity it will have a small size even at quant 2. Also, with watching paint dry it might be recommendable to watch it dry at quant 2 because of the above reason ;).
atreya2011
14th February 2004, 12:00
So its ok to restrict them??? I can use
Min I frame quantizer=2
Max I frame quantizer=5
Min P frame quantizer=2
Max P frame quantizer=5
without any dire consequences I hope...
:thanks:
mf
14th February 2004, 12:06
The question is, WHY do you want it. It won't have "dire" consequences (though limiting to quant 5 may give you quite an oversize) but rate control performs better without limitations. Why cripple it?
atreya2011
14th February 2004, 12:27
So... by limiting the range to 2-5, I am actually "choking" the rate control?? I have to check if I get an oversized file if I employ it
mf
14th February 2004, 12:54
Originally posted by atreya2011
So... by limiting the range to 2-5, I am actually "choking" the rate control?? I have to check if I get an oversized file if I employ it
Yeah. There is only one reason why you would want to restrict quants, and that's when RC goes crazy, but that hasn't happened since dev-api-3, so you're better off leaving it unrestricted.
atreya2011
14th February 2004, 13:00
But there is no harm in experimenting right?
atreya2011
14th February 2004, 13:06
One more thing I forgot to ask. How does the limiting factor actually choke the rate control function?
:thanks:
Koepi
14th February 2004, 13:21
atreya:
such things aren't meant to be asked (well, it sounds worse as I mean it now) - try for yourself and you'll very fast understand what happens (especially when you use the status window and look a bit into the internals and look at the quant distribution - and then at virtualdub's estimation in it's status window).
XviD is an educational project. So do what this implies - educate yourself with it!
:)
Regards
Koepi
atreya2011
14th February 2004, 13:30
SIR YES SIR :)
Luminaria
14th February 2004, 16:34
I read a while back that min quants of 1 were a bad idea, so ive been changing the to 2 in the RC builds. should I leave them at 1?
Koepi
14th February 2004, 16:56
Luminaria:
in RC2 sysKin added some more inteligence to the code. It's quite safe as it works now - you shouldn't have problems with it anymore.
(before RC2, using q1 could lead to serious size mismatches with default settings.)
Regards
Koepi
atreya2011
14th February 2004, 17:10
But what I heard is Quant 1 frames requires more processing power to decode and encode...
Koepi
14th February 2004, 18:13
atreya:
indeed. But that wasn't the issue Luminaria meant I think.
With a recent processor (i.e. >pII 400) there shouldn't be noticable problems with q1 frames - I only could produce that behaviour on a pII 300 with very slow memory.
Regards
Koepi
atreya2011
14th February 2004, 19:16
Oh ok, I will use the default range and see. It should'nt pose any problem for my rig
FuPP
20th February 2005, 14:26
With a recent processor (i.e. >pII 400) there shouldn't be noticable problems with q1 frames - I only could produce that behaviour on a pII 300 with very slow memory.
But what about standalone players ?
FuPP
Shinigami-Sama
21st February 2005, 07:31
Originally posted by Koepi
Luminaria:
in RC2 sysKin added some more inteligence to the code. It's quite safe as it works now - you shouldn't have problems with it anymore.
(before RC2, using q1 could lead to serious size mismatches with default settings.)
Regards
Koepi
iirc I heard someting about a quant of zero
if it;s real would the same hold true for quant zero?
~edit wrong quote
~edit fixed typos <.<
Manao
21st February 2005, 07:47
There's a quant 0 only in AVC / H264, not in mpeg4 ASP.
On a side note, could you, please, take care of the typos in your posts ?
Shinigami-Sama
22nd February 2005, 00:57
Originally posted by Manao
There's a quant 0 only in AVC / H264, not in mpeg4 ASP.
On a side note, could you, please, take care of the typos in your posts ?
ahh I wasn't sure bout that
and yeah I just put new battires in my keyboard that shuold help with the typos
dam student life making me do so manythings at once ><
anyways I'll try some tests about RC on quant zero if I get time this week
seems interesting
KaiserS
22nd February 2005, 01:04
Not to be rude, but to add could you not hit enter randomly as well and just type out full lines. Makes it alot more readable then these variable length lines you write. :)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.