Wanted: Per-Block-Quantizer

[LigH]

Dear XviD developers,

in the german Gleitz forum (soon to be merged with a reincarnation of the german doom9 forum) a question came up, why the quantizer display of ffdshow shows many different quantizer factors per frame in DivX 5 videos, but always the same factor per frame in XviD videos. There was a guess that it might depend on "psychovisual enhancements" in DivX 5, and maybe "lumi masking" in XviD could also lead to variable quantizers per frame.

I know that there are MPEG2 encoders which calculate quantizer factors per macroblock, probably depending on the amount of details in this block. I'm quite sure that content in some block does not require as low QF as others to reconstruct with low enough difference.

I'm not into the sources, therefore I would thank you to tell me, if there already is such a technology in XviD, and

- if yes: where I can activate it, and on which parameters the QF depends;
- if no: is it planned, or how hard would it probably be to implement it

[Kurosu]

1) That's defined in the MPEG-4 standard, which could be simplified a bit like that (I don't have access to the exact formulation, nor the conditions [coding mode/profile] needed): given a quantizer step, the allowed variations are:
- {-2,-1,0,1,2} for I and P-frames
- {-2,0,-2} for B-frames

I remember reading that the old lumimasking mode (adaptive quantization) was really able to change the mquants for each block, and the newer no longer did this.

Another good instance of such adaptive quantization is the numerous "masking" features available in ffmpeg/ffdshow: the quants are dynamically modulated as expected.

2) I don't know, nor I think XviD currently has a tool with the efficiency of ffmpeg's masking features. XviD allows it of course, but leaves that in Dev-api-4 to a plugin.

[superdump]

There is an idea to improve the adaptive quantisation feature in dev-api-4. I believe the ranges that Kurosu posted are correct but they are with relation to the previous macroblock. So, for example, in a string of macroblocks in a P-Frames, you could have the first macroblock with a quant of 2, the next with a quant of 3, the next with a quant of 5 the next with a quant of 4 the next with a quant of 2 and so on.

IMO masking doesn't work very well as different movies have different luminance etc so you might be ovecompressing important (or important areas in) dark scenes. There is an idea in the works about textured and smooth blocks, but we'll have to wait to see if that comes through yet.

I believe all variations are made via psychovisual assumptions. Though I may be wrong, I can't think of anything else at the moment.

[Kurosu]

Originally posted by superdump
I believe the ranges that Kurosu posted are correct but they are with relation to the previous macroblock.
At first, I thought this was wrong, as a previous search did not provide such a result: I thought only MPEG-2 and H.263 were working that way. But indeed, after a bit of look up, that's right.
The I/P-frame dquant possible (dbquant for B-frame) values are also used for S-VOPs (ie were there's GMC).

[Suikun]

Actually I hacked some kind of macro block based 2-pass into XviD two days ago. It "works" but it's quite a bad hack, breaks about everything else, doesn't fit into devapi4's plugin system, the resulting encode looks horrible and it doesn't give accurate filesizes because my overflow handling sucks ^_^;.
Another downside of such an approach is that it uses a certain amount of bitrate for storing the quantizer change (3 bits per macroblock I think). A 640*480 picture has 1200 macroblocks, so we have a 450 bytes overhead for each frame. This means 11250 byte/sec for a 25fps clip! This may be neglectible for high bitrate encodes, but it's unacceptable for encodes at 500kbit/s for example.

[sysKin]

Originally posted by Suikun
Another downside of such an approach is that it uses a certain amount of bitrate for storing the quantizer change (3 bits per macroblock I think). A 640*480 picture has 1200 macroblocks, so we have a 450 bytes overhead for each frame. This means 11250 byte/sec for a 25fps clip! This may be neglectible for high bitrate encodes, but it's unacceptable for encodes at 500kbit/s for example. Yes this is true. Moreover, it's not possible to change quantizer and use four-vector motion mode in the same macroblock - so the four-vector mode is disabled for these macroblocks, which lowers quality even more.

IMHO there is a better way of implementing a HVS model into XviD - I'd work on it now, but I better not, because everyone is waiting for 1.0 release :)

Radek

[MemTronic]

Hi sysKin,

I really like your implementations into Xvid !
...they always did/do some very good to it!!!

AND I think I am NOT alone here = believing in your coding-skills!


SO = I personally would/will wait a lot longer for your (and other devels of course) new feaures/improvements to find it's way into Xvid!

GOOD DEVELOPMENT NEEDS TIME!!! (everybody who had worked on a bigger project (like Xvid) = KNOWS THAT)

...and CURRENT Xvid IS GOOD "enough" to produce accurate (pleasing) QUALITY!


so long... and KEEP UP YOUR GREAT WORK!


MemTronic