View Full Version : adaptive quantization overhead
torsius
26th January 2004, 09:39
I just noticed recently, when I was messing around with the visualizations in ffdshow, that using adaptive quantization results in multiple quantizers per frame.
This is expected behaviour I know, but I remember when it was called lumimasking, someone remarked on how xvid didn't use multiple quantizers per frame because it resulted in a certain amount of overhead involved with having a certain block labeled with a specific quantizer.
I really don't know anything about the specifics (obviously) but my question is this: is the amount of (net) bitrate gained by using adaptive quantization in scenes that benefit from it worth the amount of (net) bitrate lost in the overhead involved with multiple quantizers per frame?
If there isn't any sense in what I'm asking or saying, feel free to blow me out of the water! :)
crusty
26th January 2004, 16:45
I don't know the specific overhead caused by using AQ, but I know we had the same discussion about overhead of Qpel vs benefits of Qpel.
As long as AQ works like it's supposed to (i.e. isn't broken), it really depends on the source. Qpel and AQ differ from other encoding options in that they require an extra overhead, while the gains are completely dependant on the source material. If the source material has a lot of scenes where the benefits of AQ outweigh the overhead, it'll make sense to use it.
With Qpel it is pretty much clear that predictability is very low, basically the only way to find out is to try and see.
Maybe with AQ predictability is a bit higher. Since AQ works with high-contrast scenes reducing detail in the far ends of the brightness spectrum, you can probably look at the source and guesstimate the amount of scenes with really high contrast. I wouldn't call it a scientific method tho, but it's a start.
I'd say try this on a movie like 'Dark City' or something similar, like a good old film-noir. Plenty of high contrast scenes there...
CruNcher
26th January 2004, 19:01
agree to what crusty said but it's not only old sources this can help especialy action movies where alot of shooting is going on like Matrix for example those gunflashes are really well quantized and can save bits for other more important scenes :)
Kb_cruncher
28th January 2004, 14:47
Adaptive Quantisation decreases, not increases, filesize in every test that i have done so how can there be any overhead?I could be wrong but my tests show otherwise.
Koepi
28th January 2004, 16:00
There are 3 bits reserved in each macroblock (or were it more?) for setting the quant deviation (+-2 max. from frame average quant). Since this is fixed even if adaptive quantisation isn't used, there is nothing like overhead involved compared to using adaptive quantisation.
SysKin may clear this further up, I _think_ it is this way, not 100% sure.
Regards
Koepi
MfA
28th January 2004, 16:05
Fixed quant testing is a microbenchmark which should be interpreted with care ... anyone who uses it to test the effects of things like adaptive quantization and trellis search probably shouldnt be using it (really only a developer doing tests between different implementations should want to use it in this scenario).
The question is not wether it decreases rate, the question is wether it decreases rate sufficiently to justify the increase in distortion which accomponies it ...
As for overhead, the MB coding mode determines if DQUANT is present ... so it simply takes 2 extra bits if you use it. For B-frames if you want to use DQUANTs you cant even use direct mode!!!
crusty
28th January 2004, 16:19
Adaptive Quantisation decreases, not increases, filesize in every test that i have done so how can there be any overhead?
Overhead is the extra amount of bits requiered for the implementation of the process. It's always an additional amount of bits used.
Aside from that, there's the amount of bits saved because of the process.
The bits saved by the process can be more than the amount of bits used by the implementation of the process. Then filesize will decrease.
But the amount of bits saved by the process can also be less than the amount of bits used extra by the process itself. Then filesize will increase.
You have only seen examples of the first, but that doesn't mean that the other situation doesn't exist.
Think of a car as the file, and an extra part to the motor as the option.
The extra part can make you use less fuel than before, but only if you encounter uphill parts on your road.It also uses a constant tiny amount of fuel all the time.
So if you encounter many uphill pieces of road, you will save fuel.
But if you encounter none, you will have only spent a bit extra fuel.
Get the analogy?
MfA
28th January 2004, 16:24
More importantly, even if it saves bits at fixed quant it doesnt mean a thing ... it tells you absolutely nothing usefull, zip, nada, zilch.
vBulletin® v3.8.4, Copyright ©2000-2009, Jelsoft Enterprises Ltd.