Custom Quantization matrix

[ReferenceDivx]

I was wondering if anyone had experimented with using different matrices.

I just tested a HVS (Human Visual System) luminance matrix i read about in an IEEE paper. I ran it through my image quality metrics program that i wrote and noticed that its claim of about .2db psnr was indeed true(which does not necessarily guarntee a better picture).

the matrix is as follows

16 16 16 16 17 18 21 24
16 16 16 16 17 19 22 25
16 16 17 18 20 22 25 29
16 16 18 21 24 27 31 36
17 17 20 24 30 35 41 47
18 19 22 27 35 44 54 65
21 22 25 31 41 54 71 88
24 25 29 36 47 65 88 115

mpeg amse = 4.66611 apsnr = 41.5306
custom HVS matrix amse = 4.47718 apsnr = 41.7052
amse is average mse
apsnr is average Peak Signal Noise Ratio

I just tried the best setting in Divx 5.02
and got amse = 6.46222 apsnr = 40.1583

[SirDavidGuy]

Once I made one for very low bitrate encoding, but it has since been deleted. Beyond that, I didn't do much with it, because I was experimenting with different aspects of XviD the source.

[rui]

I would like to know if someone already tested this new matrix.

I would do it myself (those who know me know that i don't have problems in testing), but since several days back, i am having computer problems (hard drive failure, still waiting for the replacement), and my testing is reduced to almost zero :( (can't stress the hard drive much or it will failure completely)

But i believe that, if this costum matrix is good, it could represent a step foward in encoding. I mean, look at the diference between h.263 and mpeg (some like h.263 more, others, like me, mpeg, but all see the diference).

ReferenceDivx: did you experienced any diferences visually between a encode made using your matrix and the default mpeg?

[sierrafoxtrot]

@rui

i've tested it :D , and it seems to reduce some of the ringing artifacts caused by the default MPEG matrix. still, i'd like to experiment more with tweaking the H263 matrix than tweaking the H263 matrix. does anyone know if the differences between MPEG and H263 quantization are solely due to their different matrices or are the DCTs done differently?

also, reading up several older threads, i think koepi mentioned that inter H263 quantisation matrix was closer to 32 for all values (all frequencies get equal weight). what values are used for the intra matrix? if someone could post defaults, i can have a starting point to experiment ...

thanks again.

ps: i've done several google searches for H263 and MPEG matrices, but not much relevant info ...

[rui]

Hi sierrafoxtrot :)

It's good to see that you still hang around here. I am starting to feel a little "old", seeing all the new people that comes here :D

But it's a good sign, meaning that xvid is getting bigger and bigger.

Thanks for the test, i can't wait to make some of my owne. :)
That "ringing" efect is the only downside of mpeg, IMHO.
That's why i like the new HQ mod. that Koepi introduced in his latest builds. By using h.263 in quants 2 and 3, it keeps the ringing in edges smaller, and the image is almost as good as using mpeg. (This is the efect that you mean, right?)

[Koepi]

Hehe, still it's better to tweak a matrix to behave that way like mod. HQ or new mod. HQ.

I think I'll test drive that quant. matrix in some days :)

Best regards,
Koepi

[Dali Lama]

Hello,

Well I have tried that custom matrix at high quantizations ~8, and I can say it underperforms h.263 in blocking and ringing artifacts. Also, some disformity of shapes are evident. h.263 is surprisingly good at retaining proper object shape at high quants.

That's all for now, maybe more testing is needed...wait a minute of course more testing is needed :sly:

Dali

edit: sierrafoxtrot compared custom vs. mpeg, while I compared custom vs. h.263...just to clarify.

Also, I agree with sierrafoxtrot about trying to base our custom matrices off of h.263.

edit again: Thanks ReferenceDivx for starting a cool thread.

[Rrrough]

Hi, I tested it with quantizers >5 and it looks great, I think.

@koepi

is it possible to change the behaviour of modulated quantizer mode to alter between h263 and MPEG-custom quantizers instead of the build in matrix???
don't know if it's worth it, just an idea...

cheers

[rui]

Ok, after reading Dali Lama's experiments, this is what i think:
maybe we can use this costum matrix in those movies that we know will use low quantizers, like 2 cd movies, or very compressible movies.

In this cases i always used mpeg because i like a lot the "detail" it keeps (the most relevant experience i have are the wrinkles in peoples faces, they are more visible when using mpeg than h.263).
But lately i noticed that mpeg has more "ringing" efect in edges than h.263
So, i started to use Koepi's HQmod to try to avoid that (by using h.263 in very low quantizers). But, if the new costum mpeg is better at that, in low quantizer movies we can start using that.

In those movies we know that probably will have higher quantizers (1 cd or hard movies, like LOTR, we can continue using either h.263 or the old modulated option.

Or better yet, a costum h.263 matrix, like you two said ;)

EDIT: i was typing this before reading Rrrough experience. His idea is not bad IMHO
But the problem is that new costum matrixs, even better than this one could appear, andn Koepi would have to adjust everytime his builds to them. On the other hand, look at the time it took to appear a costum matrix ;)

[Rrrough]

well, actually I was thinking of a new modulated mode wich is using the custom-matrix as entered in the dialog-box, not the hardcoded one. That way, whenever there's a new (better) matrix, you enter/load it and it's being used in modulated mode as well, and hasn't to be hardcoded by Koepi. That way you could also use the default matrix with modulated mode just by entering/loading it, if that's preferred.
I guess my explanation sucks big time, but I hope someone (esp. koepi) gets the point... :p

cheers

P.S.: taking Dali's experiences into account, I guess taking this idea into new modulated HQ would be counter-productive then, so I'm referring to "classic modulated"

P.P.S.: I was using it in combination with Lanczos Resize and the visual result was astonishing, to say the least

EDIT : Oops, sorry, I was using quant 2-4...:o sorry for the confusion from first post : it's quantizers < 5... :rolleyes:
I will try higher quantizers later...

[sierrafoxtrot]

hello all!

@rui, i know what you mean by all these new faces. i feel like an old-timer ... :D

anyway, went and re-read some old threads and it looks like we can only customize MPEG quantization because H263 is done differently. i guess i really like H263 quants, because of fewer ringing artifacts, and if we can find values for MPEG quant tables that gets rid of that, i'm all for it.

one of koepi's old posts suggests that sticking 32s in the inter-frame matrix will give quantisation similar to that of H263, so i might try that. i just got shakespeare in love R2, and it's fairly difficult to fit on 1CD, so i might try the "all-32" matrix to see if it helps.

just a thought, has anyone tried changing the values in the intra-frame matrix? because that is frame from which other subsequent frames are "predicting", would it be worthwhile finding an intra-quant matrix that reduces ringing noise?

another question ... where does ringing noise come from? i know -h said that MPEG quantisation introduces noise but can it be gotten rid of by changing the matrix so that the frequencies that give rise to it are compensated for? (i'll try this tonight when i get home ... so many tests so little time!)

sorry bring more questions than answers (and not being able to express myself well enough), but i want to spark some sort of debate.

here's a couple of useful threads:

http://forum.doom9.org/showthread.php?s=&threadid=18938&highlight=custom+matrix

http://forum.doom9.org/showthread.php?s=&threadid=22805&highlight=custom+matrix

@rrough: that's a really good idea, hope koepi's listening ...

[rui]

Well, first i must confess that i didn't got Rrrough idea correctly. You are correct when you said i was thinking that you wanted Koepi to hardcode the costum matrix.

But now that he explained, i agree with him ans sierra, it seems good.

But the point is to know if the new costum matrix is better at lower quants than h.263 (i mean keeping those details and not introducing noise in edges). If the answer is yes, then maybe it would make sense to trade the h.263 for quants 2 and 3 in the new HQ modulated mode for the costum matrix, but letting the user decide what that costum matrix is, like Rrrough said very well.

Koepi, this is just a thought, i am not asking for new features :) Is by trading this ideas between us that xvid goes ahead.

I for one, like mpeg all the way, the only reason that i sometimes use HQ mod is for the noise part. If the costum matrix eliminates that, i probably would use it all the time.
But others, like Sierra and Dali think otherwise.

[iago]

Originally posted by rui
I for one, like mpeg all the way, the only reason that i sometimes use HQ mod is for the noise part. If the costum matrix eliminates that, i probably would use it all the time. Well, I just wanted to say that I agree with rui on MPEG quantization. In my experiences so far, it results in less blockiness and better color representation than h.263, though producing more edge noise/ringing artifacts (depending on the resize filter as well).

regards,
iago

[Rrrough]

@Dali Lama

I can confirm that it doesn't really perform very well on quant 8 and above... :(

@SirDavidGuy

Once I made one for very low bitrate encoding, but it has since been deleted. Beyond that, I didn't do much with it, because I was experimenting with different aspects of XviD the source.

how was it performing @ low bitrates ??? Any good ?
that would lead me to an even nastier idea, which I will tell as soon as Koepi is responding...

cheers

[SirDavidGuy]

how was it performing @ low bitrates ??? Any good ?

Relatively good, I'm working on ways of optimizing them for low bitrates as I type (Low as in 300 kbits a second).

[Belgabor]

Has anyone ever thought about modulating between more than two matrixes? like

quant 2-5: new matrix
quant 6-10: h263
quant >10: low bitrate matrix

Cheers
Belgabor

[Koepi]

We even thought about a quantizer matrix for every quant from 1-16 (and some even up to 32).

Regards,
Koepi

[Rrrough]

@Belgabor
yep, that would have been my nasty idea...

@Koepi
do you think that's within the reach of reality ???
something like a quantizer-matrix config file...???

cheers

[SirDavidGuy]

Testing goes slowly;

Which ever build I was using at the moment didn't work 100% with the settings I was using; I had to use my own.

[Dali Lama]

Hi guys,

Don't have much time, but wanted to share some testing I did last night.

After performing quant 2-8 tests using 4 matrices, I have come to this conclusion:

h.263 quants 2-3
mpeg quants 4-5
low quants 6-8
ultralow 8+

I have attached the low and ultralow matrices for those who wish to test also.

Note: Those matrices were taken from CCE SP Custom Matrices.

Take Care,

Dali

[Dali Lama]

Hi guys/gals,

Don't have much time, but wanted to share some testing I did last night.

After performing quant 2-8 tests using 4 matrices, I have come to this conclusion:

h.263 quants 2-3
mpeg quants 4-5
low quants 6-8
ultralow 8+

I have attached the low and ultralow matrices for those who wish to test also.

Note: Those matrices were taken from CCE SP Custom Matrices.

Take Care,

Dali

[Dali Lama]

Here is the Ultra Low Bitrate Matrix

[Rrrough]

@Dali Lama

great news :D:D:D can't wait until your attachments appear, thanks for posting them !!!
which build did you use ?

@Dave

what kind of problems did you run into with "regular" builds ???

@ReferenceDivx

could you please post your image quality metrics program or a link for it ? I would like to test Dali's matrices both visually and objectively.

cheers

[ReferenceDivx]

I don't exactly know what i want to do with the program i'm developing. I've been doing research into video quality metrics and the Human Visual System. I've been working on a program for the last few months that include ideas from the most recent papers and my own ideas about HVS. I'm wondering if i should make the program open source, or make it closed source. I've also been debating if i should make the web site into a research site that has papers on the newest ideas and trends in HVS. My goal is to design a new quality metric that is within 85-95% of how human perceive the quality of video. I am only really interested in mid to high bitrate video streams. Once i have my video metrics i will use some Neural networks or some fuzy logic to find the best ratios and weights for the metric's values. My final goal would be to make a new "psnr" that is almost as fast but would judge the "true" quality of dct based video streams. Finally, I would like to come up with a numbering system that would give a quality metic number to the overall video(taking into consideration many factors). My new site lives at http://www.hvsmetrics.com (however there is only an apache page up now)

Oh ya i would like to get a computer programming job someday too.

[Rrrough]

@ReferenceDivx

:o sorry, didn't intend to sound demanding in any way, didn't know it's that complex. I deeply respect your decision if it'd be keeping it closed-source (of course an open-source version would be nice as well:)). I just thought it could be a valuable tool for testing different matrices and thus maybe improving xvid's already perfect visual quality a bit more...
that's definetly an eager project you're working on, I wish you good luck with it (as well as with the job)

cheers

[Dali Lama]

Greetings,

Whoever is interested in this thread needs to see the thread about DCTune in the General Forum. Exciting stuff could happen.

Bye,

Dali

Edit: @ReferenceDivx, DCTune has a Quality metric. I think you might be interested in that.

[SirDavidGuy]

@Dave

what kind of problems did you run into with "regular" builds ???

It crashed at the beginning of the encoding.

For what reason, I am uncertain of.

[iago]

@all

Though keeping a close eye on this thread for a while, I've just found the time to start a test encode with the new matrix that ReferenceDivx posted. The movie is Salvador (1hr-57min), somewhat hard to compress I guess ;), 512*272, SimpleResize, aiming for 666000kb to fit on 1CD (700mb) with ogg audio. Using Koepi's 04092002-1 build, no lumi, max-min I-frame intervals: 300-5, credits 20quant, (and external cc, quants 2-6/2-16, payback proportionally, payback delay:300 for the second pass). BTW, I'll have the chance to test Statsreader 1.9 for the first time as well, Koepi; besides seeing how the matrix behaves with high quantizers in a full 2-pass encode ;).

And I really wonder how the result will be...

best regards,
iago

EDIT: Unfortunately I couldn't linear-scale the curve for external cc, since statsreader 1.9 crashed and refused my stats file; so I'm going for internal cc with altCC defaults. And average quantizer will really be pretty high with the above target size I guess, since the first-pass size is ~2150 mb ;)...

[SirDavidGuy]

My low-bitrate matrix is going well, but I am occasionally getting a purple macroblock jumping out of no where, any ideas?

[-h]

Purple! Goodness I haven't seen anything like that for a while.

Are you using B-frames? Lumi-masking? What are the lowest/highest values in your matrix? Does the lumi component appear correct, and it's just the colour that's wrong?

-h

[SirDavidGuy]

Are you using B-frames? Lumi-masking?

Nope.

What are the lowest/highest values in your matrix?

(Going From Memory) 12, 99.

Does the lumi component appear correct, and it's just the colour that's wrong?

It too appears incorrect. I'm still looking for a reason.

[-h]

It too appears incorrect. I'm still looking for a reason.

How very curious. Do the artifacts still appear when decoding with ffdshow? It seems we have a bug in custom-matrix quantization.

The only other thing I can suggest is disabling MMX optimizations and trying again.

-h

[iago]

hello again,

With the encoding parameters given in the above post, the second-pass results are as follows:

Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 131 Times, Percentage Used : 0.08%
Quant 3 Used : 3736 Times, Percentage Used : 2.19%
Quant 4 Used : 44102 Times, Percentage Used : 25.86%
Quant 5 Used : 73548 Times, Percentage Used : 43.12%
Quant 6 Used : 40827 Times, Percentage Used : 23.94%
Quant 7 Used : 7415 Times, Percentage Used : 4.35%
Quant 8 Used : 699 Times, Percentage Used : 0.41%
Quant 9 Used : 72 Times, Percentage Used : 0.04%
Quant 10 Used : 28 Times, Percentage Used : 0.02%
Quant 11 Used : 1 Times, Percentage Used : 0.00%

Average Quantizer Used for Movie : 5.036

Quantizers Used For Credits :
--------------------------------
Quant 20 Used : 5964 Times.

MPEG Quantization Type Used 176523 timed, Percentage Used : 100.00%

Quantizers prevented from rising too steeply 68 times


Intra-Frame (Key-Frame) Quantizers
------------------------------------

Movie
-------
Quant 6 Used : 1304 Times, Percentage Used : 98.56%

Credits
---------
Quant 20 Used : 19 Times, Percentage Used : 1.44%

Inter-Frame (P-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 131 Times, Percentage Used : 0.07%
Quant 3 Used : 3736 Times, Percentage Used : 2.13%
Quant 4 Used : 44102 Times, Percentage Used : 25.17%
Quant 5 Used : 73548 Times, Percentage Used : 41.98%
Quant 6 Used : 39523 Times, Percentage Used : 22.56%
Quant 7 Used : 7415 Times, Percentage Used : 4.23%
Quant 8 Used : 699 Times, Percentage Used : 0.40%
Quant 9 Used : 72 Times, Percentage Used : 0.04%
Quant 10 Used : 28 Times, Percentage Used : 0.02%
Quant 11 Used : 1 Times, Percentage Used : 0.00%

Credits
---------
Quant 20 Used : 5945 Times, Percentage Used : 3.39%

Frame Analisis
----------------

Number Of Intra-Frames (Key-Frames) : 1323
Number Of Inter-Frames (P-Frames) : 175200
Total Number Of Frames : 176523

0.75% of the Movie is Intra-Frames (Key-Frames)
99.25% of the Movie is Inter-Frames (P-Frames)

Size Analysis
----------------

1-Pass Size : 2270629239 Bytes or 2217411 KBytes or 2165 MBytes
Scaled Size : 676026371 Bytes or 660182 KBytes or 644 MBytes
Actual Size : 675989793 Bytes or 660146 KBytes or 644 MBytes

Usefull Statistics
------------------
Compressibility : -33.39%
Relative Quality of XviD avi : 39.71%
Absolute Quality of XviD avi : 90.89%

---------------------------------------------------------------

Doesn't seem very bright, yes? ;)

But surprisingly the encode looked pretty good to my eyes and it is very watchable imho. A very subjective view of course, but I really liked the result I got with that custom-matrix, though I couldn't linear-scale the curve (due to statsreader 1.9 crash), which I guess would improve the result even more...

best regards,
iago

[Koepi]

There's something wrong with cust. quant matrix in XviD, I can confirm that. The min. frame size rises from 107 bytes @880 macroblocks/image to 189bytes(!!!) - 82bytes per frame...

~10.4MB lost for my movie... back to MPEG quant type...

Regards,
Koepi

[iago]

@Koepi

That's really bad news :(. I'd started to like the results it gives... Yeah, too many bytes lost then.

thanks,
iago

[-h]

There's something wrong with cust. quant matrix in XviD, I can confirm that. The min. frame size rises from 107 bytes @880 macroblocks/image to 189bytes(!!!) - 82bytes per frame...

Sounds like it's forcing a VOL header every frame. I don't think that's desired behaviour..

-h

[rui]

I made a test using constant quant 4 with normal mpeg and costum mpeg, and the costum mpeg one was bigger by about 500 Kb.
The test was The Replacements trailer, so 500 Kb is significative here.
In a limited size test, i assume that costum matrix would give me higher quantizers.

[Dali Lama]

Ok Guys/Gals, here it comes...

CG/Animation Matrix (requires very low noise source)
MPEG (used to define the MPEG-2 Standard, sharp @ high bitrates)
Standard (a general purpose matrix designed for natural film sources)

[list=1]
CG/Animation - (requires very low noise source)
MPEG - (used to define the MPEG-2 Standard, sharp @ high bitrates)
Standard - (a general purpose matrix designed for natural film sources)
Low Bitrate - (inter and intra frame smoothing)
Very Low Bitrate - (more inter and intra frame smoothing)
Ultra Low Bitrate - (high inter and intra frame smoothing)
Ultimate - (sorry couldn't help myself :D This is my custom matrix that I like a lot for clean sources)
[/list=1]

Note: All matrices come from CCE SP, except for Low Bitrate (which I modded from Very Low Bitrate) and Ultimate...:sly:
File is attached as zip. All matrix text files are there.

Note again: I am disappointed by the news of larger filesizes with Custom Matrices, but I am sure that will be resolved.

Now lets test!

I'll post my experiences later,

Dali

[Rrrough]

@-h

didn't you look up the size difference between VOL and VOP header and found a value about 35 bytes ???
if so, where could be the difference coming from ???
(edit : the difference between 35 and 82, of course :sly: )

@Dali

I like the low bitrate matrix for quants ~5-7 from visual experience, but still struggling with DCTune to give me reliable results...

cheers

[-h]

didn't you look up the size difference between VOL and VOP header and found a value about 35 bytes ???
if so, where could be the difference coming from ???
(edit : the difference between 35 and 82, of course :sly: )

The quantization matrix requires 64 bytes, one of them is probably being written for some odd reason.

-h

[Koepi]

-h,

as you're much more firm with the core code, can you look into the cust. quant matrix code and see if there's a simple fix for this issue? Or should I send out a bugreport to the devel-list?

Thanks,

best regards,
Koepi

[-h]

as you're much more firm with the core code, can you look into the cust. quant matrix code and see if there's a simple fix for this issue? Or should I send out a bugreport to the devel-list?

Yep, I'll have a look when I wake up tomorrow. 4 AM is a tad late for me :)

I spent tonight working on a faster set of bitstream functions. They should speed up encoding and decoding, especially when low quants are used. I haven't benchmarked it naturally, but there are half as many branches and instructions.

It's fun working on this stuff again :)

-h

[Rrrough]

@-h

I spent tonight working on a faster set of bitstream functions.
Hooray !!! sounds great.
Sorry for asking trivial questions, but that'd mean 35 plus 64 bytes for VOL header for both intra and inter matrix ??? aren't they 64 bytes large each one ??? that'd come close to the once proposed 140 bytes overhead for those headers then for a matrix-switch, right ? Are they stored in combination or seperately then ?
:confused: ??? confused ??? :confused:

sleep well

[iago]

@all

As the problem with custom-matrices is detected, I'm very hopeful that it will be resolved eventually ;). So we can begin to experiment with them with more reliability. Currently I'm waiting for this issue to be resolved.

P.S.: I'm really looking forward to try especially your "Ultimate Matrix" Dali! ;)

regards,
iago

[MfA]

When you benchmark the code could you post the results -h? I found a pretty nice adaptive quantization method which Id like to try out, but given how fast DQUANT bits start dominating any savings Id like to put in an explicit check against that. Of course at the cost of repeated quantization and bitstream coding, just wondering how much the costs would be.

It's a paper called "A perceptual model for JPEG applications based on classification, texture masking, and luminance masking" BTW. It is totally ad-hoc and empirical, or in other words actually usefull :) (Unlike say Watson's stuff, which I am ashamed to admit I was totally unfoundedly fond of in the past.) It will require DCT coefficients from the original frames, but coded right that should only take about 1-2 millisecond extra per frame on a fast machine (DCT takes about 250 cycles from cache, memory bandwith wont be the limitation ... so with prefetch on a 1+ GHz that should be possible).

[Koepi]

Did you write gruel about that already? He is trying to implement something like that, and I don't know if he knows about your paper.

Regards,
Koepi

(yeah, the one who produces coal...)

[MfA]

It was just a jibe Koepi, I thought your answer in the thread was counterproductive. I tried to indicate the impression you make on me in as an unconfrontational way as possible. Yes, sure it was criticism ... but there was no spite there.

I think Gruel is more interested in standard rate-distortion, with MSE or the like, he also wants to requantize/encode to find real bitrate costs ... but that is pretty much tangential to the perceptual metric in this paper.

[-h]

I just patched core in both branches to prevent all the VOL headers being written. Decoding the new (smaller) streams works with both XviD and DivX 5.x, so all appears well.

-h

[iago]

->I just patched core in both branches to prevent all the VOL headers being written. Decoding the new (smaller) streams works with both XviD and DivX 5.x, so all appears well.

That's really great! Thanks a lot -h!
So I'm sure we'll have a new build by Koepi very very soon ;)...

best regards,
iago

[-h]

Sorry for asking trivial questions, but that'd mean 35 plus 64 bytes for VOL header for both intra and inter matrix ??? aren't they 64 bytes large each one ??? that'd come close to the once proposed 140 bytes overhead for those headers then for a matrix-switch, right ? Are they stored in combination or seperately then ?
:confused: ??? confused ??? :confused:

I didn't notice your question before, sorry!

If a custom matrix is used, the VOL header will grow by 64 bytes for each matrix which differs from the default, otherwise a bit is set that says "just use the default matrix for intra or inter".

If you want to change a matrix mid-stream, a new VOL header must be written which will bring about an additional 35 or so bytes for the header and 64 bytes for each matrix you've customised. So if it's a P-frame, you'll have 100 bytes of overhead if you specify only the inter matrix, or 164 bytes of overhead if you specify a custom intra matrix as well.

-h

[-h]

When you benchmark the code could you post the results -h? I found a pretty nice adaptive quantization method which Id like to try out, but given how fast DQUANT bits start dominating any savings Id like to put in an explicit check against that. Of course at the cost of repeated quantization and bitstream coding, just wondering how much the costs would be.

They're not terribly significant, I only rewrote the Bitstream* functions, not mbcoding() itself:

Tested with a 45 MB buffer on my K7:

Read test - read 1 bit then 2 bits then 4 bits then 8 bits, 25,000,000 times:

Old: 1172 ms
New: 741 ms

Skip test - skip 1 bit then 2 bits then 4 bits then 8 bits, 25,000,000 times:

Old: 351 ms
New: 300 ms

Write test - write 1 bit then 2 bits then 4 bits then 8 bits, 25,000,000 times:

Old: 1852 ms
New: 1382 ms

I actually didn't think a 47 MB bitstream could be read or packed that fast, so realistically this won't help much. The rest of mbcoding seems much more important, but that will be a much bigger headache to optimise. I'll see what I can do.

It will require DCT coefficients from the original frames, but coded right that should only take about 1-2 millisecond extra per frame on a fast machine (DCT takes about 250 cycles from cache, memory bandwith wont be the limitation ... so with prefetch on a 1+ GHz that should be possible).

Perhaps it would be better to guesstimate the bitcosts with a zero-count of the quantized coefficients. Or even the sum of unquantized DCT coefficients minus DC. How precise do you want this? :)

-h

[Dali Lama]

Update on Custom Matrices

Movie: Rush Hour on 1-CD

Quantization Matrix: Ultimate

Resolution: 640x272 w/ Lanczos

I frame = 2-5
P frame = 2-10

Visual result is outstanding. Crispness like I've never seen before. The great thing is that when artifacts appear, they show up as graininess instead of blocks or ringing(very little shows up). This is most likely due to the combination of Lanczos Resize and Ultimate Matrix. This graininess is actually pleasant when viewed from a normal watching distance.

----------------------------------------------------------------

Movie: Monsters Inc. on 1-CD

Quantization Matrix: CG/Animation

Resolution: 576x320 w/ Lanczos

I frame = 2-5
P frame = 2-10

With such a clean CG/Animation source as Monsters, these settings did not generate ugly artifacts. Instead, they brought out all the detail. Once again, little or no blocks or ringing, mostly graininess.

------------------------------------------------------------------

All I can say is that the Custom Matrix really plays a crucial role in creating a quality encode, because it determines how compression artifacts if present will appear.

To my understanding, Quantization Matrices are designed to tell the codec how to display the compression artifacts. For instance, at Quant 1, all Matrices look good, because there is little or no compression taking place. However, at Quant 5 each displays its unique compression artifacts.

Each codec how its own range of values for the matrices, but I think the DCT range is 0-255. Xvid support 8-99, I believe. As you increase the values you increase the filtering effect of the matrix. As you shift the values placement in the matrix, you change the type of compression artifact.

Inter frame matrices spatailly quantize the frame
Intra frame matrices temporally quantize the frame.

-------------------------------------------------------------------

H.263 Matrix - adept at smearing the image, instead of blocking or ringing. This isn't such a bad thing at high quants, but at lower quants watch out. It seems like a "safe" choice for just about any movie type. Hides source artifacts very well.

Experiences:
1-CD you will see smearing and some blocks. Image is very smooth
2-CD you will see a beautiful image that has a filtered look.

Reccomendation: If your source is not clean and do not wish to removie artifacts in fear of ruining the source, use this matrix to cover it up and provide pleasant overall compression artifacts. 1 or 2 CD reccomended.

MPEG Matrix - strengths include high detail preservation wtih little filtering. Weakness include ringing artifacts even at high quants and image breakup at low quants. It has been accepted as a good choice for achieving sharp images at the cost of high bitrate and possible ringing. Suitable for almost all movie types.

Experiences:
1-CD you will see lots of ringing and bright color artifacts at edges. Image is very crisp
2-CD you will see a beautifully sharp image with some ringing

Reccomendation: If your souce is clean and you don't mind the rining artifacts, I would use it for a 2-CD encode if sharpness is a must.

Low/Very Low/Ultra Low Bitrate Matrix - able to reduce visual perception of high quantization artifacts on many source types. Retains shape and prevents ringing and blocking at the cost of sharpness and detail. However, sharpness and detail is lost already at the low quants, which these matrices are designed for.

Experience:
1-CD/2-CD will simply not look good, due to heavy filtering.

Reccomendation: Not ready for use in a wide range of quants. Designed for particularly high levels of quantization. Do not use for 1 or 2 CD encodes. Most suitable for a modulated or frame based quantization implemenation in Xvid (see General Forum under DCTune for more info on frame based quantization matrices).

CG/Animation Matrix - Desinged specifically for Computer Graphics or Animation encoding. Requires a very clean source for optimal compression artifact reduction

Experience:
1-CD you will love the sharpness and detail and marvel at how low the ringing and blocking artifacts are. Amazing.
2-CD N/A Should be similar to 1-CD, except even less ringin and blocking

Reccomendation: Ready for use on CGs such as Monsters or Anime with low noise or filtered out noise. Either 1 or 2 CD reccomended.

Ultimate Matrix - Designed to handle natural film sources by equally filtering the intra (temporal) frames and progressivly increased filtering the inter (spatial) frames. Concept adapted from CG/Animation. Designed for clean sources.

Experience:
1-CD you will love the detail and sharpness and strain to find any rining artifacts or blocking artifacts. Backgrounds are stable and clean. Artifacts will appear as graininess...What's there to complain about :sly:
2-CD N/A expect results similar to 1-CD, but with less graininess artifacts.

Reccomendation: Ready for use on clean natural sources such as Rush Hour or Matrix. Clean, crisp unfiltered look and disguised compression artifacts bring me to reccomend for either 1 or 2 CD encodes.

-----------------------------------------------------------------

Note: I am still experimenting with DCTune to achieve either source based or frame based Quantization Matrices. Of course the frame based Quantization Matrices will require the Xvid team to implement.

Keep up the good work guys,

Dali

[MfA]

Originally posted by -h
It will require DCT coefficients from the original frames, but coded right that should only take about 1-2 millisecond extra per frame on a fast machine (DCT takes about 250 cycles from cache, memory bandwith wont be the limitation ... so with prefetch on a 1+ GHz that should be possible).

Dunno why you quoted this part, I was just talking about the MB classification. It works in the DCT domain, so it needs the coefficients from the original frame for that.

Perhaps it would be better to guesstimate the bitcosts with a zero-count of the quantized coefficients. Or even the sum of unquantized DCT coefficients minus DC. How precise do you want this? :)

As precise as makes sense :) Hard to tell without knowing how much time stuff takes.

[MaTTeR]

Great thread here guys.

@Dali Lama
In your testing...was any type of noise filters used(eg.TemporalSoften)? Thanks for the helpful post. I'm trying the "Ultimate" matrix right now with the LadyHawke DVD source. The source isn't the cleanest but should be interesting to compare.

[-h]

Dunno why you quoted this part, I was just talking about the MB classification. It works in the DCT domain, so it needs the coefficients from the original frame for that.

I don't understand a lot of things I do. Tis more interesting.

As precise as makes sense :) Hard to tell without knowing how much time stuff takes.

Here's some output from a 1000-frame 320x240 RGB sequence at quant=3, all other settings vfw defaults:

DCT: Total time: 678.348648 ms (7.394761 percent of total encoding time)
Quant: Total time: 277.783923 ms (3.028156 percent of total encoding time)
IDCT: Total time: 290.378810 ms (3.165455 percent of total encoding time)
IQuant: Total time: 204.797511 ms (2.232523 percent of total encoding time)
Mot estimation: Total time: 3737.099173 ms (40.738573 percent of total encoding time)
Mot compensation: Total time: 975.475832 ms (10.633781 percent of total encoding time)
Edges: Total time: 234.381983 ms (2.555027 percent of total encoding time)
Interpolation: Total time: 921.709852 ms (10.047671 percent of total encoding time)
RGB2YUV: Total time: 462.702356 ms (5.043975 percent of total encoding time)
Transfer: Total time: 54.025131 ms (0.588935 percent of total encoding time)
Prediction: Total time: 6.824087 ms (0.074390 percent of total encoding time)
Coding: Total time: 1048.388421 ms (11.428610 percent of total encoding time)
Interlacing: Total time: 16.295438 ms (0.177639 percent of total encoding time)

Overall encoding time: 9173.367969 ms, we measured 7979.936375 ms (86.990257 percent)

I think the internal profiling could use some work, but it's a nice guide as to how effective specific optimizations are.

-h

[rui]

I tried in a very quick test Dali's Ultimate costum matrix, and it managed to lower the average quantizer by TWO points, in comparison with mpeg :)
The image quality was very similar with mpeg.

[Koepi]

XviD-23092002-1:
- Fresh CVS checkout - many cleanups.
- New mod. HQ quant type reimplemented.


included is the bugfix from -h for custom quantization matrices :)

Regards,
Koepi

[iago]

Wooooowwww! That's what I'd been expecting! Thanks a lot Koepi!.. ;)

with my best regards,
iago

EDIT: First I'll make a few tests (with constant quant 4, lanczos resize, 512*272, on a PAL progressive source) with the "Ultimate Matrix" and the "matrix posted by ReferenceDivx". Then I'll compare the results, before I shoot a full twopass with one of them ;). Coz I've been expecting a good custom matrix not to give less-than-ordinary results with a quant of 4. In other words, it must prove itself with quant 4, or maybe with 5 and 6 as well, to be used in a full encode ;)...

[Dali Lama]

Originally posted by rui
I tried in a very quick test Dali's Ultimate costum matrix, and it managed to lower the average quantizer by TWO points, in comparison with mpeg :)
The image quality was very similar with mpeg.

That's really nice to hear. I never actually checked to see if it lowered the quants or reduced filesize, but suspected it to do so since artifacts were reduced with it.

@ Iago, That is exactly how I tested out my matrix. Using constant quant at 4 or 5, since that is the most used quant for 1-CD. I hope you find excellent results.

Big thanks to -h for the custom matrix fix. Doh, now I have to re-encode Rush Hour and Monsters :sly:

Of course thanks to Koepi for the build.

Take Care,

Dali

[iago]

Hello all,

After some short constant quant 4 tests with Koepi's 23092002-1 build on a 512*272 lanczos resized PAL progressive source, with first 5081 frames of the movie, below are the test results in terms of compressibility:

h263: 11876kb
mpeg: 12702kb
mpeg-custom (posted by ReferenceDivx): 13828kb
mpeg-custom (Dali Lama's Ultimate Matrix): 8186kb

Regarding visuals, I can say that I liked the h263 best. mpeg and mpeg-custom (posted by ReferenceDivx) are very similar to each other actually (a bit more detailed and a bit blockier than h263). Dali Lama's Ultimate Matrix was the worst performing one "with constant quant 4", obviously blockier and poorer in quality than the previous three, also producing some greenish artifacts with close-ups in the faces. However, in a full 2pass encode, if it doesn't reach quantizers as high as 4, as a result of its compressibility advantage it may of course be performing much better. (Which I doubt when going for a 1CD encode especially, but of course it requires some 2-pass full-encode testing and it may be possible as well ;))

best regards,
iago

EDIT: Oh Dali, we have posted simultaneously! ;) Unfortunately I couldn't get the expected results with Ultimate Matrix "using constant quant 4". But I'll try it again with different sources, lower quantizers and in a full-movie two-pass encode too. Kindest regards.

[sierrafoxtrot]

looking at rui's observation that Dali Lama's Ultimate Matrix lowers average quant by 2 (!) tends to back up iago's constant quant encodes where the it produced the smallest filesize ...

... bottom line is that i can't wait to get home to start encoding ...

PS: thanks for the new build koepi and -h :)

[rui]

Well, my small test was made using the usual "The Replacements" trailer. It was made using 2-pass internal.
I don't have the data here now (was made at home, because here i still have comp problems), but i remember ultimate matrix was getting a lower quantizer average by those 2 points. The most used quantizers were much lower than using mpeg. But i noticed that mpeg used more value 2 quantizers than ultimate matrix. But in all, ultimate used more lower quantizers than using mpeg.
I also made the same test using h.263, and visually speaking, i liked much more ultimate matrix than h.263, also got lower average quantizer (h.263 got almost the same value as mpeg).

But this was a small test (trailer), so for much more definitive conclusions i advice all to wait for iago's tests ;)

EDIT: and for Sierrafoxtrot tests also. Sorry Sierra :)

[iago]

hello again, "serial tester" back ;)
(I've got a new alias btw, thanks to vlad59 ;))

Well, unfortunately I cannot provide any good news in my tests with the Ultimate Matrix. I have just run a short test again, this time with constant quant 2, using which any matrix is supposed to perform its best with minimal artifacts imho.

First 4000 frames of the same PAL progressive source, 512*272, this time with BicubicResize (0,0.5) -since I was inclined to blame LanczosResize for the edge-noise and ringing artifacts in the previous quant 4 test-, and comparing only h263 and Ultimate Matrix.

The results are as follows:

compressibility:
----------------
h263: 22670kb
Ultimate Matrix: 15286kb

Well, so far OK, compressibility is great. But... here comes the bad news...

visuals:
--------
Even with "quant2", Ultimate Matrix generated noticable blockiness (much more than h263), and the worse, proved to be the cause of those annoying edge noise/ringing artifacts.

As a result, as long as the great compressibility advantage isn't accompanied by a pleasing visual quality, unfortunately it is not preferable imho. With the help of compressibility, OK, you can even have almost all your quantizers ~2-3, maybe even you can get the codec saturated in most encodes ;), but I'm afraid that even the best possible quality (which means quant2) encode will come with these disturbing artifacts when using the Ultimate Matrix...

Attached in the below zip file, you can find two PNG screenshots for comparison: One with h263 the other with Ultimate Matrix (quantizer 2).

kindest regards,
iago

EDIT: However, since the custom-matrices are based on exploiting ;) HVS to provide a better "looking" picture, either still or moving (though I haven't achieved this "perceptually better" result with Ultimate Matrix so far), as long as you're pleased with the video "playback" when watching, and as long as you won't compare that result with what other quantization types produce, then of course it can still be used imho.....

[MfA]

Quantizers are meaningless, you can make a custom matrix which at quant 4 gives near identical result to the standard matrix at quant 2. Just scale it by 2 and hey presto.

Just use fixed size encoding for comparisons.

[wotef]

hm, i've done a slightly different test today (koepi's 23/09 build), which is the bank robbery scene from heat

first i cropped, lanczos resized to 640x272 and saved the sequence to huffyuv -- this way, i've got a resized "source" where i can distinguish purely codec-specific artifacts later, p.s. i didn't see any such edge-noise introduced by lanczos

then i did some 2-pass internal h263, modulated, modulated experimental, mpeg and dali's "ultimate" custom matrix runs

i specified a desired video filesize of 72283 kb, as i was trying to stretch the codec ability as you would likely do with a real-world rip

right away, i have to say i prefer mpeg quants to h263 for that filmic quality

now, key-frame-wise, ALL the xvid outputs had some minor but discernable blocking that wasn't there on my huffyuv sample --

quality-wise, modulated experimental came out very, very close to straight mpeg, too close for me to see any material difference, in fact

what i found most interesting was that dali's "ultimate" matrix consistently distributed the blocks in a pleasing way, or rather, in a way that is less obvious to the eye - they're still there, but i found i noticed the mpeg artifacts quite a bit less using the ultimate matrix!

probably 640x272 for 70mb was too aggressive for this scene, but it was suprising to see the difference in how the "ultimate" matrix seems to euphonically manage any block artifacts that get through

look around the lock, the handle and the background areas, you'll get the idea

http://www.zenadsl5618.zen.co.uk/doorknob.htm

motion-wise, all the outputs looked real good to me, but then, that is an exciting scene to watch!

[Defiler]

Originally posted by wotef
look around the lock, the handle and the background areas, you'll get the ideaWhoa! Huffyuv smoked everything else in that test! I'm going to start using it for my 1-CD rips. :D

[Rrrough]

Hello fellowship of the custom-quant-matrices !

I've been testing some matrices by computing the perceptual error with DCTune between the avisynth-output and the decoded picture using quants 2-9, because those are the most used by me. I compared 5 randomly chosen pictures from a randomly chosen movie (:) Tomb Raider) per quantizer and matrix and calculated the mean value. A value of 1.0 is regarded lossless. No filtering was used (except postprocessing of the source with MarcFD's MPEG2DEC, using cpu=6), only cropping and Lanczos-resize. Find the results attached as a textfile.
Obviously DCTune likes the HVS-matrix most, whereas ULTIMATE has the poorest result. Now that the code is fixed thanks to -h(ero :)), I will take filesize into account as well, and try to find a "perceptual-error/filesize ratio". Maybe that can indicate the best matrix for each quant... as always, just an idea...

cheers

[iago]

@Rrrough

Good work pal, please go on with it ;). Possibly a technical confirmation of my visual observations on the above mentioned tests. So far I have only tested Ultimate Matrix (short tests as stated above) and Custom HVS matrix (a full 2pass 1CD encode and it "looked" ;) really great to my eyes, but unfortunately that was before the code was fixed so it could have been even better imho). I'm considering to test custom HVS matrix in a full 2pass encode again.

regards,
iago


@MfA

Btw, thanks for your suggestions, but I couldn't get your point and what the relation of your reply with my above posts is. Sorry for my lack of understanding.

[MfA]

My only point was that comparing results of a custom matrix at the same quantizer with the normal matrix is perfectly meaningless, unless it happens to give a file the same size, nothing more to read into it. Wasnt aimed specifically at you.

[Dali Lama]

MfA, I understand exactly what you are talking about. Using Ultimate Matrix @ quant 5 gave me a much lower filesize than MPEG @ quant 5.

Iago, this means that quantization matrices have to be tested out in full 2-pass mode. Using two-pass, the codec will specify the quant it needs to achieve the quality/filesize which changes for each matrix.

Rui pointed this out when he said that the Ultimate matrix gives 2 lower quants. At first, I was skeptical, but now I believe this can happen.

Still testing,

Dali

[Rrrough]

@MfA,Dali

thus the idea of the "perceptual error / filesize" ratio. I didn't try that yet because I only had a build with the broken core, so that'd been senseless.
as for interpretation : ULTIMATE has the poorest results doesn't mean that ultimate is the worst matrix, it has to be interpreted with the filesize in- resp. decreases it gives. sorry if I didn't make that clear. I'm just trying to do a more objective approach. don't know if that'll work out.

@Dali

did you try DCTune-generated matrices yet ???

cheers & happy testing

[iago]

@Dali Lama

Originally posted by Dali Lama
@ Iago, That is exactly how I tested out my matrix. Using constant quant at 4 or 5, since that is the most used quant for 1-CD. I hope you find excellent results. ??? ;)

My tests were not much different from those you mentioned I guess...

[Dali Lama]

Iago, I know, we both were testing wrong. At first, I used that method, but when I performed 2 full length encodes the performance of the matrix is more clearly shown.

Take Care,

Dali

Edit: Rrrough I did get a chance, but still need time to interpret how to use those matrices.

[iago]

@Dali,

OK, man ;). I know what you mean, and what mFa means as well; in a different thread a while ago we had discussed the same things with Koepi... I just wanted to see the "best possible" performance of the matrix at quant2, lets say for a very well compressible movie ;).

And I'd told you, I haven't tested it in a full 2-pass encode and I will do that very soon too.

best regards,
iago

[sierrafoxtrot]

i seem to have problems with dali's ultimate matrix using 2-pass. i got back home and decided to re-encode lola rennt (run lola run) with koepi's 23092002-1 build, and dali's ultimate matrix with lanczos resizing.

my previous encode with H263 and linear scaling gave a compressibility value of 57% and this encode gave a value of 85% (!). However, it looked horrific, with giant macroblocks everywhere. then i tried encoding at constant quant 2, 3 and 4 and these macroblocks just keep appearing everywhere, even at quant 2 for fairly demanding scenes. i haven't had any more time to try the custom matrix with previous builds, but i'll give that a shot tonight.

has anyone else had this kind of problem?

[Koepi]

I tried monster's inc. with the cg matrix and my latest build and honestly speaking I didn't like the result :-/ I'm trying with HVS matrix now, it seems to produce a compressability closer to h.263 than to mpeg, but since I'm on the second pass now I still don't know about the visual result.

Maybe I should keep my hands from lanczos in this case and use neutral bicubib instead as in that particular movie you can see the quantization effects very fast (because the "main monster" sullivan has plenty fine rendered hairs which are smoothed into a even level without details often).

Maybe this is a side effect of the mpeg2dec+PP, I've to recheck the source material after encoding as this effect is visible in all encodes I tried - but it's strength is always different and thus is influenced by quantization. Maybe I should switch off lumi masking as well, in this movie it might do more harm than good.

Don't get me wrong, I like the attempt of new custom matrices and I appreciate all your work here, I just wanted to write down that my "first" attempt failed, which just means that I need to tweak around :)

I have to make clear as well that the fact that quantizer levels rise or fall between different matrices doesn't mean anything. Looking at the CG matrix e.g. I can double the quantization level and the results should still be close to h.263 at half the quantizer...

Maybe it's really just the lumi masking effect, I'll reencode without lumi masking and with CG matrix later today again!

Thanks for all your efforts! :)

Best regards,
Koepi

P.S.: I plan on hacking in a cust. mod quant mode which takes a (hardcoded) file like "C:\cumodqu.txt" as input and modulates matrices like:
1 D:\video_ts\CG_matrix.txt
4 h.263
6 mpeg
...
which would be interpreted as quant 1-3 CG matrix, 4-5 h.263,...
Would that be useful?

[iago]

@sierrafoxtrot

Actually I didn't want to make any more comments on Ultimate Matrix until I did a full-movie 2-pass encode, but exactly that was what I expected and what I was trying to remark. Unfortunately, I guess your results support all my above tests and the arguments put forward in my posts.

best regards,
iago

----------------------------------------------------------------
-> I plan on hacking in a cust. mod quant mode which takes a (hardcoded) file like "C:\cumodqu.txt" as input and modulates matrices like:
1 D:\video_ts\CG_matrix.txt
4 h.263
6 mpeg
...
which would be interpreted as quant 1-3 CG matrix, 4-5 h.263,...
Would that be useful?
(Koepi)
-----------------------------------------------------------------
That would absolutely be great Koepi!
I guess this hardcoded matrix determination file will be configurable to use the desired matrix for desired quantization? Is that what you mean?

many thanks,
iago

[Didée]

Originally posted by sierrafoxtrot
i seem to have problems with dali's ultimate matrix using 2-pass. i got back home and decided to re-encode lola rennt (run lola run) with koepi's 23092002-1 build, and dali's ultimate matrix with lanczos resizing.

my previous encode with H263 and linear scaling gave a compressibility value of 57% and this encode gave a value of 85% (!). However, it looked horrific, with giant macroblocks everywhere. then i tried encoding at constant quant 2, 3 and 4 and these macroblocks just keep appearing everywhere, even at quant 2 for fairly demanding scenes. i haven't had any more time to try the custom matrix with previous builds, but i'll give that a shot tonight.

has anyone else had this kind of problem?
Yes.
A few days ago, I tried the "Ultimate Matrix" the very first time (on the Neo-vs-Morpheus-KungFu-Scene), with const.quant 3 / mpeg.

Result:
*Everything* looked like "Div3-shit-frames", throughout the whole scene.

That day, I still was using koepi´s XviD-04092002. I have to repeat the test with the actual build.
The result of the above was completely unusable, more like a bad joke.

[Defiler]

Didée: I had the same experience with the Ultimate Matrix.

Some of the DCT documentation I read yesterday talked about how useless it was to put large values in the high-frequency section of the quantizer matrix. Perhaps it's best not to make changes that are quite this drastic.

[JimiK]

@Koepi
Wouldn't such a custom modulation be hard to realize? You stated that different matrices would use different quantizers for a fixed filesize (2pass). If one assumes that matrix XY would use lower quantizers than the mpeg matrix, couldn't that screw up two pass encoding? I mean, the size predictability would no longer be given, because for the first pass was done with mpeg. Then you say for quantizers >3 use matrix XY. But this matrix "compresses" better at these quantizers and needs less bits. Most likely the visual quality won't be so good because for example it compresses at quant 2 with almost the same quality as mpeg at quant 4, but now the higher quantizer is being used.
I hope I could make my point clear (fear not). I don't know much about how the codec compensates for the "underuse" of bits in the 2nd pass. Maybe all my fears are in vain. But if this is not the case, then all matrices would have to be modified to "perfectly" play together.

sincerely,
JimiK

[Koepi]

JimiK,

now that you state that, you're right, I didn't think about it that way :/
It's not that easy... we would hit our size as the overflow gets redistributed, but the quality would severely suffer. So it _is_ a bad idea to do that. Damn.

Maybe we come up with a more intelligent solution ;)

Thanks for reporting this! :)

Best regards,
Koepi

[Rrrough]

Koepi,

doesn't it depend on what kind of and how many matrices are involved ?
e.g. using MPEG HVS and h.263 only (similar to normal modulated or modulated HQ), shouldn't be too bad as you state yourself that HVS seems to produce compressability closer to h.263 than to mpeg in your trial. As you surely know, I would especially like to test this combination as modulated...
Of course it can do more harm than good, depending on the settings that (Joe;)) user is trying, but to my understanding, custom matrices are highly experimental anyway, and there are a lot of test'n'tweak-minded people here (we even have a serial-tester:)). You also remarked your modulated HQ-mode experimental.
I for one wouldn't blame or sue you, if my encodings render bad results, because I love to test.
So I'd propose, if it's just a quick-and-dirty job to hack, go for it. If it's big pain, just wait and see if there will evolve really useful matrices.
Maybe you could make a special-edition-build only available by attaching it here !?

anyway, thanks for offering help.

cheers

[pandv]

Anyone knows because the first item (top-left) in the custom quantizer matrix is set to 8 and locked?

pandv.

[-h]

Anyone knows because the first item (top-left) in the custom quantizer matrix is set to 8 and locked?

Because it is :)

..

It's because it would be quantizing the intra DC coefficient, and that is handled "elsewhere" in the MPEG-4 spec by the DC scaler. The DC scaler is a quantization divisor whose weight depends on the desired block quantizer (like a variable matrix entry).

-h

[pandv]

So, it's impossible to scale this matrix completely.

I normally make my encodes with 2-6 quantizers for I-Frames and 2-16 for P-Frames. What I am thinking about, is:

Make a custom array equal to the desired array (mpeg or h236) divided by 2.

Cap the quantizers 4-12 for I-Frames and 4-32 for P-Frames.

Theorically i get the same encode but with double resolution (the new quantizer 5 is equivalent to the inexistent old quantizer 2.5) allowing the codec to get more precision, and minimizing the overflow.

But, if I can't change the DC quantizer, is not possible because this quantizer is doubled (and I think is the more important).

pandv.

[SirDavidGuy]

Maybe we come up with a more intelligent solution

What about encoding with all of the quant matrices on the first pass, and when a frame gets in a lower division of the size on all the matrices, choose a low-bitrate optimized matrix. You could average the frame sizes, and set bounds based on the quant ranges (eg, if set to vary between 2 and 10, divide the number of sizes into 9 zones, based on the average of the matrices. There may be some problems with interlapping zones, but these could probably be solved by measuring the MSE of each, and choosing which one was more similiar.

[ReferenceDivx]

I'm in the process of testing h.263,mpeg,hvs,ultimate, and maybe low bitrate matrices on quant 2-12 with my new program(which is in a very alpha stage).

It measures the traditional MSE and PSNR but now it also does global perceptual error as well.

The perceptual error is computed using the Watson model which takes into account three factors: contrast sensitivity, luminance masking and contrast masking.(not the best but its somewhere to start)

All post some of my observations when i get done.

[Dali Lama]

@ReferenceDivx that's great news, good luck. Also, could you please add to your test the Standard Matrix and the Horrible Matrix (hehe, see below). BTW, Watson is the one who made DCTune I think.

@all thanks for testing out Ultimate Matrix and contributing your thoughts. I know there have been mixed reviews, but that's fine. I am even more grateful that others have tested out other matrices too, this is how we will progress.

@Koepi, I think the CG/Animation Matrix is designed for such a movie as Monsters, so results should be very good, keep us posted.

BTW, I just encoded the Iron Monkey with the Standard Matrix and it looks like an overall good encode. I don't want to talk, because I might mislead people about its quality.

One final Note. I wrote another matrix, which came from DCTune, so I take no credit. It is an interesting matrix in that it seems to increase the quant ration, the opposite of the Ulimate matrix. So I have named it "Horrible Matrix" It should retain a lot of detail, but I have not done full encode. Just a part one and it seems promising. It is attached.

P.S. If anyone wants me to stop posting my matrices just let me know. I don't want anyone to feel that I just make them up and waste your time testing it.

Take Care,

Dali

[rui]

Originally posted by Dali Lama
P.S. If anyone wants me to stop posting my matrices just let me know. I don't want anyone to feel that I just make them up and waste your time testing it.

Take Care,

Dali

I am not a Mod or something of that kind, but i think i speak for many when i say : of course you should post them :)

This is what this thread is all about: costum quantization matrix. So your matrices (and others) are welcome.

[Rrrough]

This is what this thread is all about : costum quantization matrix. So your matrices (and others) are welcome.

I couldn't agree any more. I appreciate your efforts and don't feel like it's a waste of time at all.
And ... of course more testing is needed ;)

cheers and thanks

[kilg0r3]

one not like it, one go away. simple.

[iago]

Originally posted by Dali Lama
P.S. If anyone wants me to stop posting my matrices just let me know. I don't want anyone to feel that I just make them up and waste your time testing it.@Dali,

Please keep up your valuable effort. It's absolutely not a waste of time and as you have already pointed out in your post, only thus can we progress! :)

best wishes,
iago

[Rrrough]

has anyone ever heard of an avisynth "snapshot-filter", which takes snapshots at a configurable frame-distance ? that would make image quality metrics easier a lot, because taking snapshots manually, saving them as bitmaps and converting to ppm is quite a pain.

cheers

EDIT : problem (partially) solved, could one of the mods give me a strike for posting yet another stupid post please ???

[cjv]

Hello everybody. Just reporting on some testing. My philosophy is that 1CD rips should look good and watchable, but 2CD rips should faithfully reproduce the DVD as best as possible.
I mostly use H263/H263 on 1CD rips, and mostly MPEG/MPEG on 2CD rips, of course exceptions to the rule exist.

For this rip, I used MPEG-hvs/MPEG-hvs, and I must say that I am astonished how well it kept the DVD "feel" as compared to standard MPEG/MPEG.
VanillaSky R1
First pass: 1902070
Linear scaled (external 1.9): 1264563
157kbps VBR MP3
Quantizer distribution for 2nd pass:
Q:2:67027
Q:3:118914
Q:4:297
(Thank you Koepi for your awesome linear scaling!)
Visual: Amazing! It kept the DVD sharpness and even the film grain intact, with no blocking, and looks more like a 2600kbps MPEG-2 encode, but much MUCH sharper due to 640x352 lanczos resize.

I am currently testing an 800-1500kbps AR2.35 low bitrate MPEG-2 matrix, but the documentation is in German and the web translators are not making much sense of it :(

Now, back to testing...

cjv

[Belgabor]

Originally posted by cjv


I am currently testing an 800-1500kbps AR2.35 low bitrate MPEG-2 matrix, but the documentation is in German and the web translators are not making much sense of it :(



Just post it/a link. There's a lot of german people here (including myself), perhaps we can :D

Cheers
Belgabor

[cjv]

Cool, thanks..its from a text file I had though. Anyways, I can figure out that its for MPEG-2, but 800-1500kbps 2.35 AR is around our bitrates and film types, and coupled with an increased resolution we use for XviD, I figured its worth a shot! Here it is:



Sie ist für das folgende Szenario optimiert worden:

- Only One CD - Ein ganzer Film auf einer CD!
- MPEG 2
- GOP 15
- 8 bit
- Datenraten: AVG-800 kbps MAX-1500 kbps
- Aspect Ratio 2.35 : 1
- Filmtyp: Komödie, Thriller, Drama, Action

Für reine Actionstreifen, wo es 3/4 des Films nur am Krachen ist,
könnten noch leichte Modifikationen nötig sein.
Die Matrix ist für ein Aspect Ratio von 1.85:1 nicht!! geeignet,
da für soviel Bild einfach die Datenrate nicht ausreicht.

Was hab ich da überhaupt gemacht ?
Meine Ausgangsmatrix stammt von Columbia Tristar (immer GOP 12, 10bit DCT).
Ich habe zum testen der Bildqualität wieder die Sequenz aus "The Untouchables" genommen,
um das Ergebnis direkt vergleichen zu können.
Quantisierung mit original CCE Matrix(UltraLow) 2.32
Quantisierung mit original Columbia Matrix 4.8
So jetzt wurde erst mal optimiert auf ca. 3 zu kommen
(immer wieder vergleich am TV zwischen den MPEGs)
Quantisierung mit der Angel 2.35:1 Low Matrix 2.98
Ich glaube hier habe ich jetzt das Optimum gefunden.
Ja aber was ist hier anders als bei der CCE Matrix!
Die tiefen Frequenzen (Der wichtigste Bildanteil !) wird hier mit
max. möglicher Qualität gespeichert, wohingegen die hohen Frequenzen schon
sehr früh zu Null werden, aber bei dieser niedrigen Datenrate bringt das wirklich Vorteile.

Nochmal ! Die Matrix ist nur ! für das oben genannte Szenario geeignet.

Kommentar von Ixi / shh :
Schöne Matrix!
Wie ich sehe auch etwas niedrigere default-Quantisierung für die horizontalen Frequenzen.
Das ist gut, weil ja von 480 beim Playback wieder horiz. gestreckt wird,
und man dann zusätzliche horizontale Genauigkeit brauchen kann.

Diese Default-Matrizen von CCE: 'Low' und 'Ultra-Low' sind warscheinlich
auf D1-Auflösung & TV optimiert: TV hat keine so hohe PixelFrequenz um die
D1-Auflösung darzustellen => kann man mit der Matrix canceln...
Für SVCD sollte man es wohl eher umgekehrt machen: Vertikale Freqenzen hoch quantisieren.


Here is the matrix:
8,13,15,19,19,23,23,29,
13,13,17,19,22,23,27,29,
15,17,19,22,23,27,29,35,
17,21,22,23,27,29,35,37,
21,21,23,27,31,33,37,99,
21,25,27,31,33,37,99,99,
25,25,31,33,37,99,99,99,
25,31,33,37,99,99,99,99

8,11,13,15,15,19,19,24,
11,11,15,15,19,21,24,25,
13,15,17,19,21,24,25,34,
13,17,19,21,23,26,34,99,
17,19,21,23,26,32,99,99,
17,21,23,26,32,99,99,99,
22,22,28,30,99,99,99,99,
22,28,30,99,99,99,99,99

Of course, a full translation is neither expected nor necessary, basically I'm just wondering if its worth any furthur testing for XviD encoding purposes?
(so far I find it reduces compresibility (w/lanczos), but the visual results are almost perfect DVD-like if there's enough bitrate to spare.) I will try a full encode (FightClub) either tomorrow or the next day.
Thanks,

cjv

[Belgabor]

Ok, I'll give my best. I have to admit I'm seriouly lacking backgroud on these things, so forgive me if i forgot something important.

The facts:
- The matrix might need optimizing for films with high action content (3/4)
- It's not suitable for an aspect ratio of 1:1.85 because the data rate would be too low for such a high content.
- was made for cce with the settings at the top
- Diffrences to the original CCE matrix: (direct translation)

The lower frequencies (The most important part of the image) are saved with maximal quality while the higher frequencicys get zero sooner, but this really gives you an atvantage at lower bitrates.

(I know this isnt brillant english, but i kept to the original as close as possible)

I think this is the most important part.

Cheers
Belgabor

[tangent]

Originally posted by cjv

Here is the matrix:
8,13,15,19,19,23,23,29,
13,13,17,19,22,23,27,29,
15,17,19,22,23,27,29,35,
17,21,22,23,27,29,35,37,
21,21,23,27,31,33,37,99,
21,25,27,31,33,37,99,99,
25,25,31,33,37,99,99,99,
25,31,33,37,99,99,99,99

8,11,13,15,15,19,19,24,
11,11,15,15,19,21,24,25,
13,15,17,19,21,24,25,34,
13,17,19,21,23,26,34,99,
17,19,21,23,26,32,99,99,
17,21,23,26,32,99,99,99,
22,22,28,30,99,99,99,99,
22,28,30,99,99,99,99,99


Looks like a brickwall lowpass filter there to me.

[ReferenceDivx]

I'm starting to think about writing my own matrices. What consideration do I have to consider when making the matrices. What number range can the number be between (2-99)? or somthing else. Do all the numbers have to add up to some number?

Could someone post in plaintext the H.263 matrix and the 264 matrix. I don't know if there is actual matrices for these, or they are just a system for compressing images. (Actually i think it is the later from several posts I just read)

Thanks

/////////////////////////////////////////////////////////////
Tangent posted in another post a while back:

Well, not much to explain. The top left hand corner is the DC quantiser, at the bottom left hand corner you have the horizontal high frequency component, across the top row you have the vertical high frequency components, and at the bottom right hand corner you have the diagonal high frequency component. When the 8x8 block has been DCT transformed into ths spectral domain, the transform matrix is divided by the quantization matrix, and each coefficient is rounded off to the nearest integer. The quantized coefficients are then Huffman+Runlength encoded. Typically, after the quantization, most of the coefficients are zero, near zero, maybe with the exception of the DC coefficient. Most of the information tend to be in the lower frequency areas.

If you increase the quantizer in one cell, then there will be less information stored in that cell. So optimally you want the more preceptible frequencies to have a lower quantizer and the less perceptible frequencies to have a higher quantizer. The JPEG baseline standard uses something like this:

52 55 61 66 70 61 64 73
63 59 66 90 109 85 69 72
62 59 68 113 144 104 66 73
63 58 71 122 154 106 70 69
67 61 68 104 126 88 68 70
79 65 60 70 77 68 58 75
85 71 64 59 55 61 65 83
87 79 69 68 65 76 78 94

As most of you probably know, each block can also store a quantizer multiplier value to get higher compression with lower quality.

Perhaps a place to start would be to try the JPEG quantizer matrix (divide everything by 2 since we mostly use 2x quantizer).
////////////////////////////////////////////////////////////

[Rrrough]

@-h

:o sorry, another stupid question,
in the above mentioned thread (http://forum.doom9.org/showthread.php?threadid=18938&highlight=HuffmanRunlength+encoded) you mentioned :

The quant matrices are sent when the encoder is initialised, so we can't send updated tables whenever we feel like it (i.e., we can't use different tables for low or high quants). Since these tables are stored in the VOL header, this is a future possibility.

but modulated was possible, back then. how was/is that possible ? has that ever changed ? or were you only speaking of "un"modulated modes ?
is the h.263 matrix also sent as VOL-header ? I guess not, then ? sorry, I didn't find anything concerning that.

cheers

[-h]

but modulated was possible, back then. how was/is that possible ? has that ever changed ? or were you only speaking of "un"modulated modes ?

I'm not sure what I was talking about. Perhaps the API implementation in vfw/core was insufficient back then, or I was worried about the per-frame overhead of VOL headers. I think it was just a problem with the way core handled custom matrix encoding - back then you were only allowed to send the matrix once per encode or something.

is the h.263 matrix also sent as VOL-header ? I guess not, then ? sorry, I didn't find anything concerning that.

H.263 does not have a "matrix" as such, it just divides every DCT coefficient by (quant * 2).

-h

[Rrrough]

so changing from MPEG to h.263 midstream doesn't force a new VOL header ? is there any overhead involved changing to h.263 ?

cheers

[molerus]

Hi!

Long forgotten thread huh?:)

I spent some time testing custom matrices and I found funny bug/not bug in XviD. Namely when I compress a clip using custom matrix and then set it back to normal MPEG codec seems to use still the custom matrix - the resulting file is exactly the same in length :confused: . I tried it for a ridiculous matrix giving me shitty picture and the results were corresponding - same picture. The same result I got in 2-pass encoding using the matrix called New Modulated HQ. If anyone is interested in it can be the way to use custom matrix in modulated encoding. :p

P.S. Maybe someone noticed it earlier but I haven't read it before. If so then sorry for this post. :rolleyes:

[Didée]

This I have reported 2 times up to now, but got no comment or response at all.

Now I have a link to the latest build on my desktop, which I always hit after finishing playing with custom matrices ...

[Sigmatador]

hum the attached files have gone ^^

here (http://atlas2.tgv.net/~media-video/forum2/viewtopic.php?t=2240&start=60) are the HVS matrix.

can someone upload the CG-Animation matrix plz ?

[philippas]

Can someone post the format of the file that the custom quant matrix is saved ?
I want to write an app to automatically create a file were the settings will be saved, because it's very frustrating to manually edit 63 and 64 values from the Gui of xvid.

Thanks in advance .:)

[ultimatebilly]

Isn't this just what the save button in the custom matrix GUI does?

[Sigmatador]

The CG-Animation matrix plz ^^

[Rrrough]

Nitrogen nicely published a link for a whole collection of matrices (also CG-matrix) in this (http://forum.doom9.org/showthread.php?threadid=34493&perpage=20&pagenumber=2) thread.

cheers

[Sigmatador]

oops ^^ thx ^^