Cvs 2002-03-03 (quantization tables)

[-h]

Just looked over the new quantization matrix stuff:

- Yes I know the entry screen is ugly, maybe I'll pretty it up.
- The MMX code for MPEG quantization (that includes "MPEG" and "Custom") has been disabled, as it broke the custom mode. So, anyone using MPEG or Custom with today's build will see much slower encodes.
- 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.

You would now be able to make a "middle ground" set of matrices which lie between MPEG and H.263, giving you the best of both worlds if you may. I'll upload said table as a file you can load in with the "Load" button if anyone wants to experiment.

The biggest thing people will notice is the slowdown thanks to disabling MMX (for the time being) - just wanted to point that out.

-h

[Koepi]

I guess we should branch the CVS for that then... ;)

Else I would get lost ;) People asking for faster modes etc pp...

(one major point where "we" were better than divx4 was speed, right? ;) )

For the time being? Really?

Damn.

Regards,
Koepi

[Actron]

hmm....i dont know, how this would really improve the modulated quant. because was also something like a middleground between h.232 and mpeg....

so i will stick with 2.3. because of the speed

[Teegedeck]

I've been looking forward to those user-defined quantization matrices! A shame that I can't test it right away because I'm in the middle of an encoding session. :(

Wellll; I don't think DX5 will have that feature.

[Koepi]

I guess we need some literature about quantization matrices since I dunno what or where t tweak to achieve what I want ;)

Any suggestions?

Regards,
Koepi

[tangent]

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).

[octapus]

Are there any thoughts in the future about change the quantization table whenever seems suitable ( fit). I think quality/space would raised little more.
If you want it from another point of view, how about finding best quantization table for each (frame)>(x size) where x bigger than a reasonable amount of bytes.

[rui]

Well, it happened.
I had my first crash using XviD. It was in the 2 pass of a 1 cd encoding of a full movie.:(

I can’t give more details because I didn’t have debugview running, and I wasn’t near the computer when it happened. When I went back to the computer, it was on the desktop, and the avi file was at about 400MB.
I was using the latest build from 3/3 that I downloaded from uManiac’s site, for testing the new Costum quantization matrix. I used this costum quantization both in 1 pass and 2 pass.
The other settings were 5 motion search precision, 1-31 inter frames quantizer, 1-31 intra frames quantizer, Keyframe boost 50%, curve compression 25% high 15% low, and all other values at default.
But, like expected, the new build is a lot slower then the others. I used to get 24/26 fps with Koepi’s builds, and now I was getting about 19/20 fps.

[Klumsy]

Well, I doubt that I can do matrices that will look better than the existing ones. So I hope the modulation will stay in the codec. Maybe with the extension to choose what tables are used for modulation and the border, where the the table is changed.

I wait until Koepi puts up his new build with the matrices. Then I will play around a bit with the tables. When I change the table, do I have to do the first pass again too?

[-h]

I was using the latest build from 3/3 that I downloaded from uManiac’s site, for testing the new Costum quantization matrix. I used this costum quantization both in 1 pass and 2 pass.
The other settings were 5 motion search precision, 1-31 inter frames quantizer, 1-31 intra frames quantizer, Keyframe boost 50%, curve compression 25% high 15% low, and all other values at default.
But, like expected, the new build is a lot slower then the others. I used to get 24/26 fps with Koepi’s builds, and now I was getting about 19/20 fps.

Hm that's a weird one. I haven't had the dev branch crash on me yet (when I compile it right), we might just have to wait and see. Also the speed has been better for me.. very odd.

-h

[Koepi]

You shouldn't forget that a half year passed by since those reports and since then we have MMXed "general" routines, not just for mpeg hand h.263... ;)

Many things changed since then. :)

Regards,
Koepi

[rui]

That was my report, but as Koepi said, it was a long time ago :)

[-h]

Oh wow, I didn't even notice how old that report was!

At least it has been put to rest :)

-h