Understanding a Quantization Matrix

[crusty]

Offcourse it would be suboptimal. It would be relatively easy to implement too. I'm no programmer, but I'd say that probably one experienced person could program something like this in a few days.
That's a lot quicker than getting it through a CVS thread in an Opensource project. And just because something isn't in the codec doesn't have to mean it's not good. Nandub SBC anyone? :D

You could indeed have two 1-pass files encoded at constant Quantizer or constant quality and then have the tool merge the best parts based on different assumptions. These could be PSNR, filesize, Quantizer, PSNR/Filesize ratio, etc, whatever you can think of basically.
You could even add intelligent filters that would base the decision on motion estimation or luminance variations, for instance to switch QM's intelligently between fast-motion and low-motion scenes.
You could also do this with 2-pass files. Or Nth-pass if you like DivX, except offcourse that you can't use different QM's with Divx. :D
Offcourse, the more files you have to merge from, the less mergable parts there will be because there will be less and less identical keyframes with every extra file.

You also do not necessarily have to go for the smallest filesize, but instead for a certain quantizer range or PSNR. Smallest filesize for the same quality or the best possible quality at a given filesize are however my greatest interests.

I have to think a bit about how this would affect the end result of pre-processing noise filters. Say for instance you used a different filter-set for two 2-pass files.
You could devise a way to take the best parts of both files, those parts with the fewest artifacts, and still use heavy filtering.
One point I often find is that you cannot set filters at the strenght you would like the most, without introducing horrible artifacts in some scenes in your movie. That's why I always encode end credits separately, even if it's just one minute, because you can use much heavier filtering on end credits.
You could take filtered and unfiltered files and simply take the best parts of both and merge them, if your decision algorithm is intelligent enough.
Maybe this is not possible, but maybe it is. A decision like that would probably not be based on PSNR because a filtered file would probably have a lower PSNR. Maybe if you could add a PSNR-offset to the filtered file and simply switch whenever the filtered file has the better PSNR(adjusted with the offset) than the unfiltered file.....everybody still getting this?? :D :D

You can even take this one step further and make it a kind of general multi-file merge tool, with plugin modules that add different merge-decision-algorithms into the tool. And in the end you could even try to merge this tool itself with VirtualDubMod. :D

[JimiK]

@Acaila
Did you compare the quality of the clips when you confirmed Didée's test? Because as we all know: higher PSNR does not necessarily mean better visual quality (that's why they used another method called JNI in a test by the german computer magazin c't. JNI should also consider the human visual system). Of course I know that Didée is here for a long time and I don't doubt that this matrix is great, but it just makes me wonder why.
@all
Some thoughts about different matrices:
1. you would no longer be able to use bframes (as you might know, Modulated and bframes don't mix). Do you really think you could achieve the same quality without bframes, by just using better fitting matrices? (I mean quality at low bitrates).
2. you would have to store all these matrices (the decoder has to know the matrix the encoder used). Then you would to set a flag which matrix is used. I don't know how modulated is implemented. But in the best case scenario, you would have to set a flag, everytime the matrix changes. In the worst case, you would need a flag for every frame that tells the decoder which matrix to use (well, worst case would be if the matrix would not be stored at a single point in the file, but would have to be there everytime it changes. But that is highly unlikely). Even in the best case, you would waste some bits. Say you have up to 256 different matrices. The flag would need 8Bit=1Byte to say which matrix to use.
@crusty
You don't have to encode your credits separately. Just use the trim command in avisynth and filter this section more than the other. Then you can also use the xvid credits section and compress this part more than the others.
Best regards,
JimiK

[crusty]

Some thoughts about different matrices: 1. you would no longer be able to use bframes (as you might know, Modulated and bframes don't mix). Do you really think you could achieve the same quality without bframes, by just using better fitting matrices? (I mean quality at low bitrates).

You're both right and wrong here.
Modulated and B-frames don't mix because the Xvid codec doesn't alter the QM only at keyframes in modulated mode. (this should be a quick fix for modulated BTW)
Xvid takes h263 when the average quantizer is under one value and mpeg when it is over one value. It doesn't do this just at keyframes but whenever it feels like doing that. So altering the QM at a B or P frame would break predictability in the codec. Ergo, no modulated QM with B-frames.

But the method I mentioned only alters the QM in complete I-B-P frame sequences, so there should be no problem.
So yes, you could still use B-frames. You could even alter all the B-frame settings (ratio, offset and treshold) for every separate clip because those are only ENcoding settings and do not matter when DEcoding.

@point 2:
Good question. I have NO idea how big a QM actually is inside a mpeg4 stream. Anyone got the answer? :confused:
Say you have up to 256 different matrices
A bit overkill probably, I doubt anyone would ever use more than 8 matrices. :D

I encode my end credits using separate avs files and the trim function. And I do filter them much heavier and I DO use the lowest bitrate without introducing too many artifacts. That's what I said. :)

[Acaila]

Originally posted by JimiK
Did you compare the quality of the clips when you confirmed Didée's test? Because as we all know: higher PSNR does not necessarily mean better visual quality (that's why they used another method called JNI in a test by the german computer magazin c't. JNI should also consider the human visual system). Of course I know that Didée is here for a long time and I don't doubt that this matrix is great, but it just makes me wonder why.
I quickly scanned through them and couldn't see any differences, however I doubt anyone could see the difference between e.g. a PSNR of 45 and a PSNR of 45.5 though (yes I know it's possible, but I couldn't do it). I did my tests at a compressibility of about 70%, so either will look great. And when both videos look great, I tend to label the one with the highest PSNR as the best.

Originally posted by crusty
Good question. I have NO idea how big a QM actually is inside a mpeg4 stream. Anyone got the answer?All I know is that QM values are 8-bit, so those 64 values would take up 64 bytes. I don't know if they have to be repeated at every QM change, or can be set with a flag with all matrices written out in a header somewhere.

[crusty]

I quickly scanned through them and couldn't see any differences, however I doubt anyone could see the difference between e.g. a PSNR of 45 and a PSNR of 45.5 though (yes I know it's possible, but I couldn't do it).
That's probably just a matter of training.
After ripping 400 Audio CD's I could differentiate easily between a 192 kbps mp3 and the original WAV...hell I could even hear the difference between CD's and records by then!
And I found lately when doing a lot of difficult audio syncing (enterprise serie from mpeg to xvid) that I could 'feel' the difference between 10 and 20 ms of delay. That's 1/100th of a second.
I guess that with enough training people would probably be able to see PSNR drops like you mentioned.All I know is that QM values are 8-bit, so those 64 values would take up 64 bytes. I don't know if they have to be repeated at every QM change, or can be set with a flag with all matrices written out in a header somewhere.
Well that would mean that at every QM change 64 bytes extra are used, because I doubt that this would be implemented by flags.

[mf]

Actually a .5 PSNR increase is quite much. It's noticable on a full movie.

[OUTPinged_]

That's strange. I am getting pretty bad results with the provided matrixes on test clip.

It is actually a "torture" one, the codec is expected to provide good-looking picture with ~30% 1/2_pass_ratio. Last koepi's build is used, vhq4+bframes+chroma etc etc.

new matrixes were working in quantization range of 4-10 while h263 was using 2-6 range. h263 was looking pretty good everywhere, while custom matrixes looked like shit on hi-motion scenes where quantizers jupmed up to 8 and beyond.

Interesting thing was that if i was using custom matrix with minimum value of 16 (increasing to 32 same way akaila's does), it looked ok again. Quantizer range used was 3-7.

So i picked a frame which was referred by KF and had practically same size for all matrixes.

it had: quant6 for h263, quant 7 for "16-32" matrix and quant9 for akaila's (i was using it since they both give pretty same results and incompatibility with ffdshow is a big no-no).

here are images that show this very well:

"http://www.mif.vu.lt/~dmku1330/lowkoeffbug-16-32 matrix at quant7.jpg"
"http://www.mif.vu.lt/~dmku1330/lowkoeffbug-akaila's matrix at quant9.jpg"
"http://www.mif.vu.lt/~dmku1330/lowkoeffbug-h263 matrix at quant6.jpg"

notice how 16-32 and h262 matrixes look pretty much the same when "akaila" shows up blocky.

screens were taken in vdub.

Does that occur everywhere where higher quantizer ranges are used? (literally,am i supposed to get crap quality with those low koeff. matrixes for low 1/2 pass ratios?) Maybe there is a bug someplace i missed?


Also, here is a small OT question: i thought that h263 was equivalent to "all 16" matrix but 16s are giving me higher compression ratio. Any ideas which matrix will represent h263 most closely?

[OUTPinged_]

@Acaila

i believe, QM is stored inside each intra frame.

[Acaila]

I don't know why these custom matrices performed bad in your high compression tests. The only reason I can think of is because they quantize low coefficients roughly the same way as high coefficients. Whereas the standard matrices quantize the high coeficients much stronger than the low ones. Once you get to high quants (>6) this could have a great effect on the image detail because you'll start losing a lot of low coefficients as well. But that's just a guess.

One thing I do noticed is that the picture from the frame encoded with my matrix looked a lot clearer (less blurry) than the other two. Was the rest of the video also like that or was it just that one frame?

[crusty]

i believe, QM is stored inside each intra frame.
Damn, I keep forgetting the difference between inter and intra frame :(
That's why I talk about Key-frames and B/P-frames, cause that's a lot clearer.

Do you mean at every Key-frame?

One thing I do noticed is that the picture from the frame encoded with my matrix looked a lot clearer (less blurry) than the other two.
Yeah I noticed that too. It also looks like most of this particular frame is ok but there is distortion in part of the picture, which gets amplified by Acaila's QM.
Was this distortion also present in the original? Please check.

Maybe if you could post a small clip (<250 frames) we could take a look at it.

EDIT: is it me or has this forum slowed down a bit the last few weeks?

[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-noThis 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]

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/dsp/training/coding/jpeg/jpeg/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]

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 ! :thanks:

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 :D

[n0an]

http://i49.tinypic.com/5yf6o1.jpg

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

http://i45.tinypic.com/a1pm5w.jpg

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?

[LoRd_MuldeR]

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

This cannot be explained easily. The effect of quantization matrices (positive or negative) may highly depend on the kind of content and on the target bitrate.

For example there are "sharp" matrices tuned to keep fine detail at high bitrates. Such a matrix will give horrible results at medium/low bitrates.

At the same time there are "smooth" matrices tuned to keep reasonable quality at low bitartes. Such a matrix won't give satisfactory results at medium/high bitrates.

In short: Don't use a custom matrix, unless you know exatcly what you are doing and why you need a non-standard matrix.

(Note: H.264 is known to give best results with the standard "flat" matrix. Psy optimizations, as implemented in x264, usually work better than custom matrices)

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?

Of course the resulting file size will always be the same, as long as you set the same target (average) bitrate. The following rule applies, no matter what:
size = bitrate * duration

Well, given that the rate control of your encoder works properly and doesn't fail with non-standard matrices ;)

[n0an]

I need to experiment to understand the usage. Practical knowledge and examples help me understand better. Anyway, I am wanting to have a low and medium bitrate based matrix. I am trying to understand each matrix in the CQM editor.

The higher the bar means all details below that threshold will not be encoded - that means they will remain as it is? You think you could help me understand it during your free time? I would really appreciate it. I won't take long to understand as I have been reading and grasping stuff for quite a while now :).

P.S. I am mainly looking for XviD and HD (x264) based matrix.

[LoRd_MuldeR]

The higher the bar means all details below that threshold will not be encoded - that means they will remain as it is?

No, it doesn't. Each coefficient in the DCT transformed macroblock will be divided through the corresponding entry in the quantization matrix. It's important to understand the DCT transform (http://en.wikipedia.org/wiki/Jpeg#Discrete_cosine_transform), before you try to understand what quantization matrices do! After division, the DCT coefficients are rounded - that's what causes loss! The higher the value in the quantization matrix, the higher the rounding error (loss) for the corresponding DCT coefficient. That's why we use high quantization values for the "high" frequencies: The coefficients for the "high" frequencies usually have low values anyway. If we divide that through a high value (from the quant matrix), it will be extremely small and thus rounded to zero, most likely. So after quantization (http://en.wikipedia.org/wiki/Jpeg#Quantization) we have a lot of zero coefficients in our transformed DCT block. This doesn't save us any bits yet, but it does in the next step, which is entropy coding (http://en.wikipedia.org/wiki/Jpeg#Entropy_coding)! At the same time the loss in the "higher" frequencies ("fine detail") isn't as noticeable as loss in the "lower" frequencies ("coarse" detail).

Furthermore it is important to understand that all this high/low frequency to fine/coarse detail mapping only applies to I-Frames. In P- and B-Frames the story is a bit different:
http://forum.doom9.org/showpost.php?p=318659&postcount=17

P.S. I am mainly looking for XviD and HD (x264) based matrix.

As said before: Most likely you won't ever need any custom matrices for x264. It works best with the default (flat) matrix. That's because most things people tried to achieve with custom matrices in the past is done by x264's Psy-optimizations nowadays, only in a better way. So again: Don't mess with custom matrices, unless you know exactly why you need them...

Anyway, I am wanting to have a low and medium bitrate based matrix. I am trying to understand each matrix in the CQM editor.

Look here for examples:
http://forum.doom9.org/showthread.php?s=&threadid=83125

[kool]

In short: Don't use a custom matrix, unless you know exactly what you are doing and why you need a non-standard matrix.


* a question, What is your opinion on Xvid? as you already know there is lots of custom matrix around and you also post a link at # 83.

* Will MPEG produce a good output result for larger file size and x263 for smaller 1 CD, for user which don't know what they are doing with matrix?

* Will matrix keep more detail than default MPEG and x263?

[LoRd_MuldeR]

* a question, What is your opinion on Xvid? as you already know there is lots of custom matrix around and you also post a link at # 83.

Well, Xvid is one of the best MPEG-4 ASP encoders (along with DivX). But it certainly can't reach the quality of a good AVC/H.264 encoder, such as x264.

* Will MPEG produce a good output result for larger file size and x263 for smaller 1 CD, for user which don't know what they are doing with matrix?

This question makes no sense. There is no such thing as "x264". You probably mean x264. But x264 is a MPEG-4 AVC (H.264) encoder, so you can't compare it to MPEG.

MPEG is standard that defines many things, such as MPEG-1, MPEG-2, MPEG-4 ASP (implementd by DivX/Xvid), MPEG-4 AVC (H.264) as well as various audio and container formats.

* Will matrix keep more detail than default MPEG and x263?

This question makes even less sense. Maybe you refer to MPEG-4 ASP quantization matrices ???

MPEG-4 ASP (as implemented by Xvid and DivX) supports two types of quantization. They are called "MPEG" and "H.263". Only the "MPEG" quantization type allows custom matrices.

Whether a custom matrix gives any benefit over the default matrix depend on what you are trying to achieve. But an unsuitable matrix can easily screw up your encode!

[n0an]

Okay, so I will try to understand DCT first. I will try to get a *study* partner for this as a few imp. things go over my head.

One question, I like the H.264 matrix a lot and I was wondering if there is a way to use that matrix for XviD encodes? I have read mixed reviews on H.263 for 1CD and MPEG for 2CD encodes, and someone said H.263 is way better than MPEG. If that is true then why not use H.263 for 2CD+ encodes as well?

How different is H.263 for H.264 and is there a method to incorporate the detail preserving matrices of H.264 in H.263?

[LoRd_MuldeR]

Quantization in H.264/AVC is completely different from MPEG-4 ASP. Therefore H.264 quantization matrices are not even comparable to MPEG-4 ASP matrices!

And to make this clear again: For MPEG-4 ASP (Xvid/Divx) the "MPEG" and "H.263" quantization types are not different quantization matrices. They are two different types of quantization.

Only the "MPEG" type can use custom matrices (as replacement for the default one). That's not possible with the "H.263" quantization type.

However the "H.263" type is known to create a slightly "smoother" image than the "MPEG" type (with standard matrix). Generally "H.263" seems to be preferable for low bitrate encodes.

[kool]

This question makes even less sense. Maybe you refer to MPEG-4 ASP quantization matrices ???

Yes :)

[n0an]

Quantization in H.264/AVC is completely different from MPEG-4 ASP. Therefore H.264 quantization matrices are not even comparable to MPEG-4 ASP matrices!

And to make this clear again: For MPEG-4 ASP (Xvid/Divx) the "MPEG" and "H.263" quantization types are not different quantization matrices. They are two different types of quantization.

Only the "MPEG" type can use custom matrices (as replacement for the default one). That's not possible with the "H.263" quantization type.

However the "H.263" type is known to create a slightly "smoother" image than the "MPEG" type (with standard matrix). Generally "H.263" seems to be preferable for low bitrate encodes.

Ah I see. My friend has created a custom matrix which preserves a lot of details on lower to medium bitrates. It smooths rough edges and preserves minute details as well. I am not sure, but I think it's a combination of H.263 and MPEG matrix.

Could you tell me how to understand the structure of a matrix in the CQME? I want to use it as a visual aid to learn better :p.

[LoRd_MuldeR]

...but I think it's a combination of H.263 and MPEG matrix.

Don't think that's possible. H.263 and MPEG are two different types of quantization. If you use a "custom" quantization matrix, then you definitely use the "MPEG" type, as the "H.263" type doesn't offer a way to use custom matrices. Also those quantization types cannot be "mixed", because you either use the one or the other...

[n0an]

Don't think that's possible. H.263 and MPEG are two different types of quantization. If you use a "custom" quantization matrix, then you definitely use the "MPEG" type, as the "H.263" type doesn't offer a way to use custom matrices. Also those quantization types cannot be "mixed", because you either use the one or the other...

Oh so matrices are only MPEG based. So is Sharktooth's E_3ULR_revision_2 is better than the H.263 for 1CD and the E_3UHR better than MPEG for 2CD?

I am currently encoding a 1hr 50min movie for 1CD at 780 kbps and a 2hr 50mn movie for 3CD at 1300 kbps. Would you recommend me using the default ones or Sharktooth's?

[LoRd_MuldeR]

Oh so matrices are only MPEG based.

For the last time:The MPEG-4 ASP standard allows two types of quantization, "MPEG" and "H.263". The standard allows custom matrices for the "MPEG" type only. Heck, the "H.263" type doesn't even have an equivalent to a quantization matrix! It's simply a different way of quantization. Or in other words: You can not make the "MPEG" type work like the "H.263" type just by using a different matrix.

And a quote from earlier this thread:
Yeah, the matrix is always included in the bitstream (in the case of MPEG quantization)... 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).

So is Sharktooth's E_3ULR_revision_2 is better than the H.263 for 1CD and the E_3UHR better than MPEG for 2CD?

That's impossible to answer for each an every source. Even the other Xvid settings you use may have an effect. But if you use an average bitrate higher than 1600 kbits, it may be worth a try. After all you must decide what looks better for your eyes. So either pick the easy way and go with the default matrix or do some testing!

[n0an]

okay, got it. Better to read basics than annoying you :P. Thanks for the help.

[henryho_hk]

Try reading the sticky "XviD Preset" thread. It describes the concept of choosing a custom matrix according to the compressibility of the material. It may give you further insight.