Custom Quantization matrix

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