Quantizers and matrices

[movmasty]

AIA(apologize in anticipation)
if i say some silly thing.....

As i understood, movies values are divided by a matrice multiplied for a given quantizers,
so if the matrice gives 8 and quant is 2, the frequency value will be divided by 16.

If the lead value of the matrice is 4 , you will need a quant 4 to get 16,
quant 4 will be equivalent to quant 2 in the matrice "base 8"
as well 3 would be like 1.5, and 2 like 1.

So, what is the point?
2=1
3=1.5
4=2
5=2.5
6=3
7=3.5
up to 62=31...

we will have a "finer" quantizers scale that wont jump from 3 to 2(around 50% more bytes)
no need to use wasteful 1, there would be a 1.5 too.

I remember the wef asking years ago for a quantizer 2.5,
would be this possible to do or is one thing totally out from video editing???(but i said AIA, remember.)

[Didée]

Hum. The XviD forum is full of threads about custom quantization matrices. And the so-called "high bitrate matrices" do exactly what you're describing.

For example (sorry for advertising my own stuff ;)), for the bitrate range where XviD with standard mpeg matrix would use quantizers 2~3, the SixOfNine matrices use quantizers 3~4~5, thereby offering the "theoretical" quantizer 2.5 through the finer quantization steps.

rule of thumb:

q2 ~~> 'q1.5'
q3 ~~> q2
q4 ~~> 'q2.5'
q5 ~~> q3
...

[movmasty]

Glad to hear, i've done an intensive read last few days but didnt find anything about this, i didnt search enough....give me a link to your matrices please.

Just one small question, how is possible to change the quantizer in 1st pass from 2 to 3?

[Mug Funky]

why would you want to do that? you'll probably get undersized files even on 1CD rips.

[movmasty]

Originally posted by Mug Funky
why would you want to do that? you'll probably get undersized files even on 1CD rips.
for a more realistic compression in 1st pass, closer to 2nd pass real quantizers,
but i said in another trhead that i would like a 1st pass at the real bitrate of the 2nd and not at fixed Q, like is for divx,

as im seeing that i always feel the need of a 3rd pass to optimize the second one that you cant precisely guess from 1st pass as it is now.

[movmasty]

Originally posted by Didée
Hum. The XviD forum is full of threads about custom quantization matrices. And the so-called "high bitrate matrices" do exactly what you're describing.

For example (sorry for advertising my own stuff ;)), for the bitrate range where XviD with standard mpeg matrix would use quantizers 2~3, the SixOfNine matrices use quantizers 3~4~5, thereby offering the "theoretical" quantizer 2.5 through the finer quantization steps.

rule of thumb:

q2 ~~> 'q1.5'
q3 ~~> q2
q4 ~~> 'q2.5'
q5 ~~> q3
... just a couple of things,
your matrices are not specifically designed to have intermediates quantizers x+0.5, and correspondig values are approximated.

and the max quant of xvid will remain 31, that would be in fact a 15.5,
not that Q above 15 are very used, just for precision.

[movmasty]

Originally posted by Mug Funky
you'll probably get undersized files even on 1CD rips.
hey,there is still someone ripping to CDs :confused:

[movmasty]

Still another thing Didée,

in all customizations the upper left value of intra matrice,8 ,the most important, is greyed out and could never be changed,
so how can you say that in your matrices q5 is equal to q3 when the most important value in fixed and get multiplied by 5 and NOT by 3????

in my idea of new quantization should be changed to 4, so it is something to hard encode in xvid,
and it is not a real customization because the "gradient" of all matrices will remain the same, just all values are to be divided by 2.

[movmasty]

then a request, im searching, but someone cold give me the link to a 3d about the difference between intra and inter matrice?

[movmasty]

if you choose custom and then edit matrix, xvid shows a default matrice, what kind of matrice is that?

Does the mpeg matrix in the XviD_Quant_Matrices.zip is the same as default MPEG compression?

why there is not a h.263 matrice in that folder??

[Manao]

Default custom mpeg matrix should indeed be the mpeg matrix ( you can check by yourself )

H263 works differently : the way of quantizing ( rounding ) is slightly different, and the matrice is uniform. That's why there are no matrices. The closer to H263 you'd get with a custom quant matrix would be a uniform one.

Intra DC ( up left coefficient ) is not quantized as the other coefficients. It roughly amounts to having it set to 8. Indeed, with the sixofnine matrix, the dc will be more quantized. The behavior of the intra DC is fixed by the norm, so there's no way XviD could come up with a workaround.

And there are still people doing 1-CD rip :)

[movmasty]

Originally posted by Manao
Default custom mpeg matrix should indeed be the mpeg matrix ( you can check by yourself )
H263 works differently : the way of quantizing ( rounding ) is slightly different, and the matrice is uniform. That's why there are no matrices. The closer to H263 you'd get with a custom quant matrix would be a uniform one.
Intra DC ( up left coefficient ) is not quantized as the other coefficients. It roughly amounts to having it set to 8. Indeed, with the sixofnine matrix, the dc will be more quantized. The behavior of the intra DC is fixed by the norm, so there's no way XviD could come up with a workaround.

And there are still people doing 1-CD rip :)
Thanks, just saw that mpeg and default custom matrix are the same, test clips were same size at the byte,
the one called MPEG.txt in XviD_Quant_Matrices gives a bigger result,8% more
About 1% less using default H263.

Still one thing Manono please, why inter frames have a different matrice?
the upper left values are higher and the down right are lower, the opposite of the intra matrices ehaviour.

[Manao]

Intra and Inter matrices don't compress the same kind of data.

Inter matrices compress the DCT of difference between the frame and the compensation, which is roughly made of white noise ( roughly... ), hence which has a lot of high frequencies. These frequencies are more important that the DC ( which is often null anyway )

Intra matrices work as in JPEG : they compress the DCT of the block uncompensated, hence the importance of the coefficients goes from upper left to down right

[movmasty]

White noise, interesting, thanks

[movmasty]

there are two ways to compress an image, smoothing and blocks,

in your opinion, what are the smooth matrices, and what those that produce blocks instead?

i think that this have to do with the different "gradient" of matrices,
i mean matrices beginning with low values then rapidly increasing, as opposite to high values at the begin but only slight increase at the down right, more uniform.

[Manao]

I have no opinion on that subject. For gradients, the most important coefficients are the first four ( 2x2 upperleft square ), followed by the first 16. But often, blocking in gentle gradients is due a quantizer too high which creates two neighbours block having a different DC ( often in such cases, the other coefficients are null or zeroed by quantification ). There's almost nothing you can do in such cases ( except deblock your video at playback ), because if you try to lower the first 4 coefficients, you'll end up with a larger filesize at same quant, which in a two pass situation will raise the average quantizer, and finally you'll end up with the same blocking because the quant will be higher.

Edit : and "white noise", it's more theoritical than practical. In fact, what you get is that kind of picture :

http://jourdan.madism.org/~manao/compensation.png

So you can spot some edges, which are due to a motion compensation not precise enough ( precision is only half or quarter pixel, and compensation assumes that blocks move along vectors )

[Koepi]

Where we start talking about vectors...

[Koepi]

(I want to make a senseless 1 sentence-post for everything too now! that'll increase my post counter. And is SO much against our rules here...)

[Koepi]

Ok, vectors and quantisers:

With rising quantizer not only the matrix values get multiplied and thus cut off frequencies "sharper", but also the possible vector length gets shortened.

So even if you use a matrix which allows you a finer quantiser distribution, you still have the problem that motion vectors can't be as long as with a higher quantiser.

Since that most likely doesn't give the smallest possible size for a given frame at a defined quality, you'll end up spending some (unneccessary) bits.

In the end it's a matter of taste, if the matrix itself can compensate for that (very possible in high bitrate scenarios).

I just wanted to add that quantisers aren't as simple as they seem on first sight ;)

Regards
Koepi

[Mug Funky]

hey,there is still someone ripping to CDslay off! my DL burner got stolen the day i was returning it to the shop (it couldn't read discs...). i haven't scrounged up the moolah to get a new one yet.

Koepi: could you elaborate on that? i'm not seeing the connection between quants and vector lengths. i know quants will affect where the vectors point to, but i didn't think vector lengths would be limited by quantizers.

[movmasty]

Originally posted by Manao
I have no opinion on that subject. For gradients, the most important coefficients are the first four ( 2x2 upperleft square ), followed by the first 16. But often, blocking in gentle gradients is due a quantizer too high which creates two neighbours block having a different DC ( often in such cases, the other coefficients are null or zeroed by quantification ). There's almost nothing you can do in such cases ( except deblock your video at playback ), because if you try to lower the first 4 coefficients, you'll end up with a larger filesize at same quant, which in a two pass situation will raise the average quantizer, and finally you'll end up with the same blocking because the quant will be higher.

Edit : and "white noise", it's more theoritical than practical. In fact, what you get is that kind of picture :

http://jourdan.madism.org/~manao/compensation.png

So you can spot some edges, which are due to a motion compensation not precise enough ( precision is only half or quarter pixel, and compensation assumes that blocks move along vectors )
i know that kind of images, but it is just an example, because forgets keyblocks, new blocks not in the keyframe,
so a delta will be composed of blocks of normal image immerged in the motion extimated blocks,
then you cant predict what kind of frequencies will have a delta frame, normally will be a mix of low freqs,typical of images, and medium freqs of the motion extimation.
If delta frames were only as in your image, the default mpeg matrice would have no sense, because it is quite similar to the intra one.

I just made a test where the coefficents of the first 6 diagonal linees of the inter were all 255, this would have produced all blocks in a intra matrice, but the delta frames of the clips were no affected from that "brutal" matrice,
but the test clip was a very static scene, i built it to check for lost details, then no keyblocks were in it i presume.

You speak about "squares" in the matrices, not sure that is mathematically correct, as the down right corner of the 2x2 rather belongs to the 3rd diagonal line values.
I saw some low bitrate matrice were all the values beyond the 4th column were 99, forgetting that also rows 5-8 should have the same weight.
I am talking about coefficents distribuited in rectangles and squares instead that in "diagonals",
see "Ultra Low Bitrate Matrix.txt" for the first kind and "Bulletproof's Heavy Compression Matrix.TXT" for the second one.

A frequecy should be a one dimension number, while the original 8x8 pixels block,always natural numbers, has at least 2 geometric dimensions,
and in fact you could see a matrice like a bidimensional number.

Now, if freqs is a simple number, what difference there is among a coefficent in the "n" colums respect to one in the "n" row?
unless there is a difference between orizontal and vertical frequencies,

we would need some matrician math to know the exact meaning of the spatial distribution,
eg. the difference between orizontal and vertical "distance"

[movmasty]

Originally posted by Mug Funky
Koepi: could you elaborate on that? i'm not seeing the connection between quants and vector lengths. i know quants will affect where the vectors point to, but i didn't think vector lengths would be limited by quantizers. Originally posted by Didée
E.g. speaking of SixOfNine again: filesize at q2 is much higher than standard, yes. But so is the quality. As rule of thumb for SixOfNine, its about

q2 [std] == q3 [6of9]
-- [std] == q4 [6of9]
q3 [std] == q5 [6of9]

So, (one) trick there is simply to make an additional quantizer available, where the std matrix would always have to do the "big jump" between q2 and q3....

....AFAIK XviD makes changes within the motion estimation for higher quants to accomodate somehow for the expected high quantization. But this seems to be hard-fixed to certain quantizers, not to resulting bitrate (that algo simply doesn't have high-bitrate matrices in mind... ).
Therefore, if you make a matrix out of the standard matrix with all values just halfened, that matrix *should*, at doubled quantizers, behave almost exactly like the standard-matrix. Or: at quant-16, it *should* behave just like standard-matrix at quant-8.
But it does not, because the motion estimation gets changed with those higher quantizers, and your "halfened" matrix will deliver worse results then. That's also why my encodings with SixOfNine will hardly ever use higher quants than q6 for P's and q8 for B's *at max*, at least not for archiving stuff.

(Could that perhaps be something for past-1.0 XviD ?)

[Manao]

movmasty : for the custom matrices not symmetric : there are people who encodes in anamorphic. In such a case, frequencies are not distributed symmetrically after the DCT, so an unsymmetric matrice can make sense.

For the intra / inter blocks in a P frame : indeed, there are intra blocks, but they are often not numerous ( else, it should have been a i-frame instead of a p-frame ). Moreover, and more to the point, when speaking about frequencies, we don't consider the whole picture, but only a 8x8 block which is either intra or inter, not both.

For the 'squares', have a look here (http://www.cs.cf.ac.uk/Dave/Multimedia/node231.html), and check the example of a line being fed to the dct. That example is in one dimension, but it can be extended to two dimension. Of course, the DC and the first two AC will be more important for gradients, but the fourth coefficient of the 2x2 square will kick in if your gradient is not either horizontal, vertical or perfectly diagonal.

Anyway, the coefficients should be grouped along arcs of circle, not along square or diagonal lines.I just made a test when the coefficents of the first 6 diagonal linees of the inter were all 255, this would have produced all blocks in a intra matrice, but the delta frames of the clips were no affected from that "brutal" matriceI don't understand exactly what test you did here.

And finally, the the vector / quantizer relation : when searching the motion vector, instead of minimizing the SAD, XviD tries to minimize the value : SAD + lambda * (bits needed to write the vector). Because at high quantizer, a long motion vector can takes far more bits than the texture itself, you have to make the lambda vary accordingly to the quantizer ( it raises when the quantizer raises ).

[movmasty]

So intra blocks in a D frame are quantized with the intra matrice?
then is to explain why the dafault mpeg inter matrice is so similar to the intra, only with a "more gentle" gradient.

the test i made was to raise at 255 all the upper left corner of the matrice, key frames in the clip were totally made of blocks, P frames were almost unaffected, thus all P frequencies were in the centre and in the down right corner,
but was a static clips, with no intra blocks in the P frames.

About anamorphic encodes, that does not mean to compress all the right part of the matrice,
and i am not convinced that the matrice is then asymmetric, anamorphic picture is a normal picture also if distorted

The picture of the DTC shows what i guessed, vertical high freqs on the right,
horizontal hfs dows
"crossed" hfs in the down right corner.

Since in my experience noise in movies is more horizontal than vertical,
you should compress more the down part respect to the right part,
the contrary that is made in some matrice i saw.

[Manao]

Yes, intra blocks in pframes are quantized with the intra matrice.

You modified only the intra matrice, right ? You didn't change the inter matrice ? So the results you're obtaining are perfectly normal.

[movmasty]

Originally posted by Manao
Yes, intra blocks in pframes are quantized with the intra matrice.

You modified only the intra matrice, right ? You didn't change the inter matrice ? So the results you're obtaining are perfectly normal.
obviously, talking about P frames, i modified in the same way also the inter matrice, except the 1st box with a value of 16,

16, 255,255
255,255,
255, ..............ecc,

no blocks at all, or better, there were blocks just after the I frame,
then blocks progressively disappeared, no more blocks 7-8 frames after the I.
(clip was 10fps with max I frame interval set to 30)

[Manao]

movmasty : before a DCT / quantification in an inter block, there is a motion compensation. Vectors are not all null, hence, when your picture on the I-frame was totally made of blocks, on the next p-frames, there will be blocks that are predicted not from a uniform block, but from the intersection of 4 uniform blocks. Such a process, even with a residual totally zeroed ( except the DC ) by the dct, you can obtain a picture which is not blocky, provided vectors are not all null ( the result won't be pretty either, it will be overly blurred )

[movmasty]

Originally posted by Manao
movmasty : before a DCT / quantification in an inter block, there is a motion compensation. Vectors are not all null, hence, when your picture on the I-frame was totally made of blocks, on the next p-frames, there will be blocks that are predicted not from a uniform block, but from the intersection of 4 uniform blocks. Such a process, even with a residual totally zeroed ( except the DC ) by the dct, you can obtain a picture which is not blocky, provided vectors are not all null ( the result won't be pretty either, it will be overly blurred )
a little blurred, but not so much, medium quality.