Understanding a Quantization Matrix

[OUTPinged_]

@acaila:

In fact, it isnt any "clearer" or a tiny bit better-looking in any other frame.

The "regular encoding frame" used h263 and looked pretty much as it is supposed to. Use it as a reference.

"16-32" matrix uses same matrix koefficient scaling as your matrix does, it is just bumped up for 16 to be lowest koeff.

To me this proves that in certain scenarious matrixes with "under-16" koefficients may be buggy. Maybe it is that particular build of xvid i am using (22032003-1, by koepi).

@crusty:
Do you mean at every Key-frame?
Yes.

Was this distortion also present in the original? Please check.
Checked it several times.

You can try it yourself:

take 20-30 second clip with clean dvd source and high resolution. Let there be both slow and high motion scene (slo-mo after hi-mo in my case). enable chroma_me+bframes+vhq4+me6. First use h263 quantizer. make first pass. Now calculate a target filesize so that it would use about 35% first/second pass ratio. make second pass. Now make both passes with akaila's matrix and you'll get new clip with same size.

Zoom both of them in virtualsub and examine.

My point is that akaila's matrix provides better quality only in those "special" cases, and shouldn't be used in "high compression ratio" encodes.

[Didée]

OUTPinged_ ,

seems like your interpretation of what was said before is a little screwed.

1. Initially, I mentioned that my matrix SixOfNine was invented for high bitrate scenarios.

@ Acaila: SixOfNine, not Seven. For sure, that poor little matrix can't scope with the bombshell Jeri Ryan

When you are going to test things with a compressability in the range of 30-35%, which is pretty low, you should try to use a matrix that reduces bitrate, instead of raising it.
A screwdriver is pretty handy for screwing screws, but I'd not try to saw any wood with it!

But, perhaps my matrix is a ScrewHammerSeaSaw? Read on.


2. Looking at that one frame, your testing material seems ... funny. But just for completeness, you should repeat that test with my matrix instead of Acaila's:
In that frame, we see mostly high-blurry content, with no edges at all, plus that funny distortion consisting of very fine detail, almost like noise. Now, if you compare the matrices of Acaila and me, you will see that my matrix will keep high frequencies much longer, when they already will get zeroed by Acaila's. That could explain the bad result you got.
I'm not sure wether my matrix will perform better in your special tests, or not. But you should TRY it, since they both are different.

Just to repeat myself again:
SixOfNine was designed to behave very similar to the standard matrix, but with a smoother quantizer scaling. Thusly, it should perform not too bad even with your heavy compression tests.


3. Acaila spells Acaila, not Akaila.


4. I disagree with your

incompatibility with ffdshow is a big no-no

This is only true, of course, when it is important for you to spread your stuff all over the world. I don't.
My encodings are for me, and some very good friends, perhaps. Why should I rely on ffdshow for decoding when it is obvious that libavcodec is buggy. If it will be fixed - fine. As long as the bug is there, I feel very comfortable to let XviD itself decode its content.
Using coeffs < 16 is perfectly allowed. If ffdshow can't handle that, I don't care.


5. More citing:

... Last koepi's build is used ...
... that particular build of xvid i am using (22032003-1) ...
... VHQ4 ...

Now, if your "last Koepi's build" is from March 22: Welcome back on earth, OUTPinged_
In its early stages, VHQ > 1 often showed severe problems. But VHQ has been improved considerably in Koepi's 14052003 build. Perhaps you should upgrade.


6. Completely OT
Even if it is very, very late:
OUTPinged_, I still have to thank you for your elaboration on XviD's AltCC-settings. (Do you remember that monster-thread?) It was your detailed explanation that made me finally understand it


Regards

Didée

[OUTPinged_]

Initially, I mentioned that my matrix SixOfNine was invented for high bitrate scenarios
That wasn't it. I was testing if your "high bitrate" matrix is ok to use with medium/low bitrate encodes. If it would be performing as it was intended to (that means, perfectly compatible with near linear 8->20 scaling), it would give out similar picture.

If you use inter coefficients with 16 for matrix A and 32 for matrix B then identical frames with identical references will be same quality if matrix' A quantizer will be 2 times smaller than matrix' B one.

For some strange reason that wasnt' true for any matrixes that were using coefficients under 16 when i tested - first, the rate control algorithm went nuts and wasn't hitting frames at desired sizes - i had to tweak "overflow improvement/degradation" settings in order to get same results (which i don't usually have to). Second, the output came out looking far worse than it should.

The worst thing was that when i updated to later xvid version, the difference decreased. Crap. :/

Anyway, for myself i decided that matrixes with under-16 coefficients are not 100% safe to use with xvids and playback software. I want to use them to encode releases so it has to be compatible :-(

Also, i would like to state this thing:

for "better-than-quantizer2" quality it is useless to futher reduce high frequencies - they are always encoding perfectly with quant2 with most matrixes and i never seen any movie where i would be able to say "this high-frequency part doesnt look good enough with quant2. The scenes that dont look good are all foggy/dark/low frequency ones. But the interesting thing is, that your matrixes dont provide much lower low-freq. coefficients than h263 does!

Simple as that: let's imagine, we have foggy scene with low details behind fog, and it gets smeared even if we use quant2 for it. Unforgivable! Now look what coefficients we will have for 4 last digits with diferent matrixes:

h263             48 
akaila           66-80 
didee            40 
mpeg***          112-166 
cg-animation*    32
low bitrate*     60-200
very low bitr.*  200-200
ultimate*        64
hvs-best**       80-260
hvs-better**     166-234
hvs-good**       176-288

*-were in "xvid custom quantization matrices.zip" file that was posted on this forum long ago
**-was posted on this forum as "HVS matrix pack" or something like that.
***-values were taken from some smart paper.

No comments on that. The thing i wanted to ask was, how large coefficients are enough for low freq., what do you think?


(oh dear, this post is gonna be long..)

When you are going to test things with a compressability in the range of 30-35%, which is pretty low, you should try to use a matrix that reduces bitrate, instead of raising it.
Matrixes dont "reduce" bitrate. To check that, make one matrix with all 16s and one with all 64s. Now encode first with constant quant8, second with constant quant2 and check for differences.

A screwdriver is pretty handy for screwing screws, but I'd not try to saw any wood with it!
You are telling that to a wrong person :-)

In that frame, we see mostly high-blurry content, with no edges at all, plus that funny distortion consisting of very fine detail, almost like noise.
Yes, that is what makes it perfect for testing things like that. I can very easy tell if low/high frequencies are cut out by quantization. Other part of a clip has a couple of seconds where heavy mosquito noise pops up.

Now, if you compare the matrices of Acaila and me, you will see that my matrix will keep high frequencies much longer
I am amused to say that, but for some reason i thought that your matrix scales up to 40 too. Some of my sentences dont apply to your matrix then. But again, it was buggy as hell with that build of xvid i used.

3. Acaila spells Acaila, not Akaila.
roger that sir <o.


Why should I rely on ffdshow for decoding when it is obvious that libavcodec is buggy
For release encodes that is essential - too much linux pcs around.


In its early stages, VHQ > 1 often showed severe problems
No, VHQ wasn't guilty in that case.

It was your detailed explanation that made me finally understand it
Well thank you for that, but i am sad to see that it is now officially recommended to use regular CC algo to not confuse newbies :-( Sheesh, even doom9 used it in his test encodes. Crap.

[Arcon]

just a short question: is the decoding of mpeg4 material generic or does the decoder need to have the same QM that has been used for the encoding?

and is every mpeg4 video encoded with a custom matrix mpeg4 compliant or is only h.263 allowed to claim full mpeg4 compatibility?

[bond]

Originally posted by Arcon
just a short question: is the decoding of mpeg4 material generic or does the decoder need to have the same QM that has been used for the encoding?

there are 3 possibilities
1) h263, which every mpeg-4 (advanced) simple profile decoder handles
2) mpeg, which every mpeg-4 advanced simple profile decoder handles
3) custom matrix, which every mpeg-4 asp decoder should handle too (to answer your question: no, it doesnt matter which custom matrix was used)

and is every mpeg4 video encoded with a custom matrix mpeg4 compliant or is only h.263 allowed to claim full mpeg4 compatibility?

all 3 possibilities are compliant to the mpeg-4 standard

[Arcon]

Originally posted by bond
3) custom matrix, which every mpeg-4 asp decoder should handle too

is the matrix included in the video-stream in this case or is it indifferent to know the exact matrix just for decoding purposes?

[RadicalEd]

Yeah, the matrix is always included in the bitstream (in the case of mpeg quantization).

[Arcon]

Originally posted by RadicalEd
(in the case of mpeg quantization).

and if it's not mpeg quant? h263 does not need to be included but everything else?

[crusty]

AFAIK, the QM is always contained in the file, no matter if it is a custom one or a standard one.

And even though things like modulated QM are not MPEG-4 compliant, they do seem to work more often than not. So, within one videostream it is possible (but not up to spec!!) to use different QM's.

Because these streams get decoded (played) correctly most of the time, I would deduct that the QM is stored in the stream.

I have no idea how, or if this even correct. Perhaps some dev could shed some light on the subject....

[RadicalEd]

Originally posted by Arcon
and if it's not mpeg quant? h263 does not need to be included but everything else?

H263 quantization is not actually a matrix, nor can it be directly compared or converted to one. It's just a method of quantizing that doesn't use weights (which MPEG does, and those are the quant matrix elements).

[Shinigami-Sama]

wow
if Iwasn't so dizzy from readign all of this I would form a corheant commet but untill them if for nothing moe than geting e-mail notifacations for later
wow
everything makes a small amount of sense now
I can now understand why a quant matrix is as inmporant as it is
and the basics of how they work
this is probl;y full of horribale typos
but I can't see them yet
so from what I understand and from serious thikning fom an overloaded mind*looks at his title so you know in advance*
useing more than one QM breacks mpeg4 specs
and if you don't care about spec this has little affect on you
so encoding with moer than one QM can be good if you;er planing to watch with a s/w player
how could I go about making it use two or more QM I may have read it I'm not sure
but is it possible to specify wher I want it to use differant QM if at all?
before I confuse you more with my bad typing and confused post I'll finish it here
p.s
thanks crusty for making this thread

[Sharktooth]

Actually XVID does support only 1 quant matrix. "Modulated" feature was removed coz it was not MPEG4 compliant.

[Shinigami-Sama]

ahh
well I don't caer abut complancy anyways
just as long as it wil play on Pc thats all that matters for me
now I understand hte basics I think
only took a day and a half for it to sink in
crusty is good at explaining things it seems
hopefully in a few days I may be able to put together a nwebish CQM myself

[samo_jurdik]

Originally Posted by crusty

Ok Folks, here is an explanation of what a matrix really does.

Guys, this is my first post in this forum....and I have a question. Apologies upfront in case it is a stupid one...

I dont understand the relation between the 'quantizers' and the 'quantums' in the q matrices. I will narrow my focus down to iframes (needed at all?).

Quote:
http://www.ece.purdue.edu/~ace/jpeg-tut/jpgquan1.html
"The quantizer divides the DCT coefficient by its corresponding quantum, then rounds to the nearest integer. Large quantums drive small coefficients down to zero. The result: many high frequency coefficients become zero, and therefore easier to code."

MY QUESTION: is 'quantizer' the name of the result of the division of the DCT signal by the corresponding quantum from the q matrix??? ie quantizer = round (DCT / quantum) ???

I hope the answer is yes, but the following quotation makes me doubt:
http://www.cmlab.csie.ntu.edu.tw/cml...eg/encoder.htm
"Quatization is defined as division of each DCT coefficient by its corresponding quantizer step size, followed by rounding to the nearest integer"

In here, 'quantizer' is what I believe should be 'quantum'.

I would greatly appreciate if you guys could shed some light into this wording mess (as it appears to me at least). Thank you!

Samo

[foxyshadis]

Result[x] = pDCT[x] / (Matrix[x] * Quantizer)
All results are rounded down (never up) to a minimum of 0. You can rearrange the algebra to find the meaning of Quantizer. The exact terminology is a little... malleable, and some researchers will use terms to mean different things than others.

It doesn't actually code the raw DCT, but rather a predicted DCT based on previous DCTs.

Note that AVC's equation is more complex, because the Quantizer scale is logarithmic.

[samo_jurdik]

Originally Posted by foxyshadis

Result[x] = pDCT[x] / (Matrix[x] * Quantizer)

Contemplating what this means....

In the 1st pass, the codec sets the quantizers to values of 2, 2 and 4 for the respective frame types and runs the source movie through to get the bit rate picture.

In the 2nd pass then the codec dynamically changes the quantizers in order to get close to the requested bit rate / file size (considering the additional 2nd pass settings - iframe tunning, overflow, curve comp and possible quantizer limitations set in Advanced options).

Can you please confirm if this approximately correct or not. Thank you !

Samo

[Poutnik]

You have got it.

[omega6666]

I also found this article to be very informative about the way quantization works; http://direct.xilinx.com/bvdocs/appnotes/xapp615.pdf

"Quantization is done to achieve better compression. Quantization reduces the number of bits needed to store information by reducing the size of the integers representing the information in the scene. These are details that the human visual system ignores. This step represents one key segment in the multi- compression process. A reduction in the number of bits reduces storage capacity needed, improves bandwidth, and lowers implementation costs."

[BluDRed]

Here's a bit of a noobish question.
With some of the videos I compress, I find that dark scenes tend to come out blocky, whereas the light scenes are coming out good with no blockiness. Now, I think I understand that a dark scene is defined as being particularly low frequency detail. This is when using the default XviD matrix H.263, would I be better off customising a matrix with a higher starting figure then continuing with less of a margin until reaching medium frequency detail for such scenes? ack I hope I'm not coming across as hopeless

[n0an]

For example, this is the ultimate matrix. Could anyone kindly explain me how it will work on the quality?



One more thing, if I set bitrate of 1200 kbps and use this matrix, will the ultimate matrix increase the file size or all matrix work within the fed bitrate?