Costs of adaptive quantization

[maikm...@googlemail.com]

Hi all,

well, I guess we all know http://x264dev.multimedia.cx/?p=377

"(macroblock-level quantizer choice) can, in theory, be done using its
“segmentation map” features, albeit very hackily and not very
efficiently"

Well, perhaps I'm just misreading and misunderstanding the VP8 spec
(that is very possible), but is it just me who thinks that the
definition of segments isn't actually that big of an overhead and
hopefully rather well-compressible by the entropy coding, given that
usually only delta values are encoded. The macro-block references to
the segment table don't look overly costly either... and my stomach
tells me that defining the segments and reusing those settings for
several macroblocks should be cheaper than e.g. individually
specifying them.


So what am I missing here?


Maik

[Yaowu Xu]

I agree with your assessment on the encoding cost of segment map
updates as well as the efficiency of feature adaption using the
segment map.

Yaowu

[Timothy B. Terriberry]

Yaowu Xu wrote:
> On Fri, May 21, 2010 at 1:45 AM, maikm...@googlemail.com
> <maikm...@googlemail.com> wrote:
>> (that is very possible), but is it just me who thinks that the
>> definition of segments isn't actually that big of an overhead and
>> hopefully rather well-compressible by the entropy coding, given that
>

> I agree with your assessment on the encoding cost of segment map

I don't. You can either update the segmentation map for every coded
block in the frame, or for none of them. There's nothing in between. If
you do update it, each flag is coded entirely independently. Deltas are
only used w.r.t. to the parameters for a segment at the beginning of the
frame, not the actual segment index associated with each MB, which is
the bulk of the data. There's no prediction, either temporal or spatial.
For any real usage of the segmentation map for adaptive quantization,
this is going to run you a cost pretty close to 2 bits per coded MB.
Entropy coding buys you almost nothing here: you only get a benefit if
some segments are used much more frequently than others, and this is the
opposite of what you want when choosing the set of quantizers to use for
the frame (because you only get 4). This basically makes the
segmentation map useless at low rates.

You can still get roughly 50% of the benefit of adaptive quantization
just by varying lambda during RDO, though.

[maikm...@googlemail.com]

On 21 Mai, 23:01, "Timothy B. Terriberry" <tterribe...@mozilla.com>
wrote:

> Yaowu Xu wrote:
> > I agree with your assessment on the encoding cost of segment map
>

> I don't. [...]

> For any real usage of the segmentation map for adaptive quantization,
> this is going to run you a cost pretty close to 2 bits per coded MB.

> [...]

> This basically makes the
> segmentation map useless at low rates.

I stand corrected. Thank you very much for putting things into
perspective.

> You can still get roughly 50% of the benefit of adaptive quantization
> just by varying lambda during RDO, though.

Well, I guess that means there's still hope for some psy-
optimizations ;)

I just wonder on the reasons for the design of the segmentation system
as-is.


Maik

[Paul Wilkins]

I agree that the way the segmentation is done is not ideal and it
could be inefficient at low data rates, particulalrly if you regularly
want to make minor changes to a map.

This is something we should look at once we have the bitstream
development branch set up.

Then we can look at delta updates to the map, more segments, doing
something similar to what we already do with the loop filter strength,
where we can apply deltas based on the prediction mode and/or the
reference frame or... well whatever we can come up with that does a
better job.

This is not the end of the road, but the beginning of a process :)

On May 21, 10:01 pm, "Timothy B. Terriberry" <tterribe...@mozilla.com>
wrote:
> Yaowu Xu wrote: