Target SSIM: A new ratecontrol method?

[Dark Shikari]

I initially thought of this here (http://forum.doom9.org/showthread.php?p=1028733#post1028733) but I figured I would make its own thread and elaborate. Here's how the idea would work.

Target-SSIM would be its own ratecontrol method. It would be, expectedly, considerably slower than others, given the algorithm I will explain. The reason it would be advantageous is that it would guarantee that every part of each frame has at least the specified SSIM, and preferably as close to the target SSIM as possible. This would mean that:

1. No bitrate would be wasted achieving unnecessarily high quality in areas where it wouldn't be noticed.

2. The classic problem of distributing quality would be solved. A common problem of all sorts of encoders is that they may discover they can increase average quality by decimating one area of a frame and boosting the bitrate in the other portion. However, visually, all we notice is the decimated portion of the frame; a human would much rather see a lower overall quality than even one or two ugly blocks. This method would guarantee no blocking and no low quailty portions of an image, period, no ifs ands or buts.

Algorithm:

1. Encode a macroblock. Guess the QP that would achieve the target SSIM.
2a. If the resulting SSIM is within a tolerance of the target SSIM, save the macroblock.
2b. If the resulting SSIM is higher than the tolerance, raise the QP and re-encode the macroblock. Guess how much to raise the QP based on how far off the SSIM is from the target.
2c. If the resulting SSIM is lower than the tolerance, drop the QP and re-encode the macroblock. Guess how much to lower the QP based on how far off the SSIM is from the target.
3. Repeat step 2 until either:
a. The SSIM of the macroblock gets into the tolerance.
b. A case is reached where the SSIM of one QP value is over the tolerance and one is under, in which the closer one is picked.
c. Even QP 51 doesn't reach the target SSIM (will happen with completely flat blocks, like on a straight black background). In this case, just use QP 51.
4. Continue to the next macroblock.

Not the fastest method out there, but it could solve basically every major quality problem. Its quite possible it could drastically increase visual quality also, as often people use very low CRF values to avoid blocking and low-quality areas, while the rest of the frame might have a load of wasted bitrate as a result. Same with AQ: there might be areas of the frame getting bitrate wasted on them as a result of AQ. This method would ensure that as little bitrate as possible is wasted while completely avoiding uneven quality.

[akupenguin]

x264_aq_cssim.0.diff (http://akuvian.org/src/x264/x264_aq_cssim.0.diff)

For some reason, it doesn't work with B-frames + 8x8dct (generates an invalid bitstream). Either one alone is fine.

This is AQ, so it doesn't make AQ obsolete. It doesn't even make luma-mask AQ obsolete, except insofar as you can include luma-mask in SSIM.
What does this have to do with trellis?

[Dark Shikari]

x264_aq_cssim.0.diff (http://akuvian.org/src/x264/x264_aq_cssim.0.diff)

For some reason, it doesn't work with B-frames + 8x8dct (generates an invalid bitstream). Either one alone is fine.

This is AQ, so it doesn't make AQ obsolete. It doesn't even make luma-mask AQ obsolete, except insofar as you can include luma-mask in SSIM.
What does this have to do with trellis?
Isn't the purpose of trellis to optimize quantizers on a per-macroblock basis, and by doing this already as a ratecontrol method, it sort of conflicts with any further attempt to do so? Or do I misunderstand trellis?

[akupenguin]

Trellis optimizes individual DCT coefficients. It isn't any closer to ratecontrol than -m6 is.

...You could ask for a SSIM-based trellis instead of SSD. But SSD is the only metric that can be efficiently optimized for (exploiting the fact that DCT is orthonormal). Anything else would be many times slower, like libavcodec's "quantizer noise shaping".

[Tack]

This is an interesting idea.

I tried this on one of my clips I use for testing AQ, and it didn't fare so well. I used my current set of values (which handles this particular clip reasonably and produces an SSIM of 0.9741170 and bitrate of 1902kbit) and reencoded it, specifying an aq-cssim of 0.974.

The resulting file had an SSIM of 0.9777498 and used 2626kbit, but the DCT blocking in dark areas was significant.

I'd have expected the bitrate to be reasonably close, all other things being equal (well, I had to disable 8x8dct). It's entirely possible I've completely missed the point of how this is supposed to work. :)

[Dark Shikari]

This is an interesting idea.

I tried this on one of my clips I use for testing AQ, and it didn't fare so well. I used my current set of values (which handles this particular clip reasonably and produces an SSIM of 0.9741170 and bitrate of 1902kbit) and reencoded it, specifying an aq-cssim of 0.974.

The resulting file had an SSIM of 0.9777498 and used 2626kbit, but the DCT blocking in dark areas was significant.

I'd have expected the bitrate to be reasonably close, all other things being equal (well, I had to disable 8x8dct). It's entirely possible I've completely missed the point of how this is supposed to work. :)
Maybe the SSIM needs to be luma-weighted? That could be the problem; a very dark block will show as a very high SSIM even if the block is entirely decimated.

I would think overall such a method would cut the bitrate/quality ratio because its allocating lots higher quantizers to "hard" areas of the image but on the other hand vastly increase visual quality on a whole-frame basis by doing exactly that.

[akupenguin]

I would expect that every single macroblock having SSIM >= X would take significantly higher bitrate than average SSIM = X.
In pure RDO (i.e. maximizing average SSIM for a given total bitrate), the most complex parts (high bits-per-SSIM cost) will have lower SSIM and the simple parts will have higher SSIM. If you force it to equalize all macroblocks, the average SSIM per bitrate can only go down.

[Dark Shikari]

I would expect average SSIM = X to be significantly lower bitrate than every single macroblock having SSIM >= X.
Yes, of course.

I can expect Target-SSIM to have higher bitrate than an equivalent SSIM 2pass encode or the like, because what its doing is raising quality on complex areas, which costs lots of bitrate, while lowering quality on simple areas, which doesn't use much bitrate. But when the SSIM is averaged for the final metric, all areas, regardless of complexity, are weighted equally, which is misleading because that's not how the human eye sees.

This means in a full-frame metric, target-SSIM would give a better result than CRF.

[akupenguin]

But do you have any reason to believe that constant SSIM (which doesn't conform to any weighting scheme even; it completely ignores bits) is closer to the correct HVS weight than evenly-weighted RDO is?

BTW, constant SSIM makes largely the opposite decisions compared to CRF/2pass. The frames that CRF assignes the lowest QP to, constant SSIM assinges the highest QP, and vice versa. Well, I always knew that; on a scale from constant bitrate to constant metrics you have (in order), CBR - ABR - CRF - CQP - CSSIM.

[Dark Shikari]

But do you have any reason to believe that constant SSIM (which doesn't conform to any weighting scheme even; it completely ignores bits) is closer to the correct HVS weight than evenly-weighted RDO is?
Well what RDO is doing is distorting the most complex parts of the picture, the parts that the eye notices most, because it saves the most bitrate.

I would think that ideally, one would want to have a constant quality across the frame if possible, rather than having the lowest quality concentrated in the most detailed areas and the highest quality concentrated in the lowest-detail areas.

The question one asks is whether the "ideal" is to have, for example, 0.95 SSIM in the 1/5th of the scene that's high motion and 0.99 SSIM in the 4/5th that is low-motion (resulting in 0.982 total SSIM), or whether one should have a lower total SSIM at the same bitrate, but equivalent across the whole scene.

[DeathTheSheep]

what its doing is raising quality on complex areas...while lowering quality on simple areas.

Therefore, the idea is not to have an even SSIM across the frame, but to give more complex areas more bitrate! But this method would itself produce easily recognizable distortions in dark/low-contrast areas which aren't signaled as "complex" leading to block mess in those areas and thus reducing HVS quality (a problem claimed already to exist)!

The question thus becomes: how is SSIM to be weighted so as to actually correspond better to the HVS, the very problem it was trying to solve! This is counterproductive, is it not?

Or am I misunderstanding something here? :eek:

[Dark Shikari]

Therefore, the idea is not to have an even SSIM across the frame, but to give more complex areas more bitrate! But this method would itself produce easily recognizable distortions in dark/low-contrast areas which aren't signaled as "complex" leading to block mess in those areas and thus reducing HVS quality (a problem claimed already to exist)!

The question thus becomes: how is SSIM to be weighted so as to actually correspond better to the HVS, the very problem it was trying to solve! This is counterproductive, is it not?

Or am I misunderstanding something here? :eek:
But doesn't a constant SSIM across the frame guarantee giving more bitrate to highly complex areas? If properly luma-weighted, wouldn't such a system also avoid having low quality in dark/low-contrast areas?

Another question that could be answered with some actual human visual testing: is ensuring constant frame-wide quality a good idea? That is, does the eye notice bad quality in the complex areas when their SSIM is lower, or are those high-motion complex areas the areas that the eye doesn't see much of anyways? If its the former, this algorithm is a good idea, if its the latter, its a bad approach.

[DeathTheSheep]

It does according to the behavior of SSIM, whether for good or otherwise.

But giving loads of bitrate to complex scenes will be at the expense of low-complexity scenes at a given bitrate, would it not? Thus, the areas in which x264 currently struggles--the low-contrast, low "complexity" areas--will suffer further. And let it be known that this very problem is the raison d'etre for --no-fast-pskip, adaptive quantization patching, etc; that is, to address the problems already present in low-contrast, low-complexity areas, and at the expense of what x264 would usually consider more "complex". Imagine how x264 would behave now that bitrate is cut even further on these problem areas.

If, however, your method would specifically force x264 to approbate higher quality for these areas in particular, 'tis a different story altogether, isn't it?

[edit] The second question you pose cannot be readily answered, for it varies by situation, source, settings, severity of qcomp cplx blur or whatnot. It is also a very interesting question (see how I go in for the interesting questions), for I, en fait, actually prefer constant quantizer strongly over constant quality mode for low bitrate anime, as the quality degradation in high-motion animation is absolutely appalling to the eye, whereas I don't mind it nearly as much for live-action content wherein only the minuscule details appear to be washed away in high motion. Certainly the eye does not focus as clearly upon details of small significance when there is such pervading motion taking place on screen!

[708145]

Certainly the eye does not focus as clearly upon details of small significance when there is such pervading motion taking place on screen!

In other words, we need a motion compensated quality metric! There was a note in one of the SSIM papers about adding motion but so far I missed its research/development it seems.

So basically an extremely powerful method is:
1) use best HVS metric available and
2) optimize strictly for it.
It's the first part that is most difficult; no metric exists that models the HVS good enough for this to work.

I sketched an algorithm dubbed EYE (Estimate your Eye) but it was no better than existing metrics in the end, just much slower :p

bis besser,
T0B1A5

[Dark Shikari]

Since now we know Target SSIM is a bad idea as it just makes the blocking worse, here's another idea: similar algorithm but possibly quite effective at stopping blocks.

1. Run deblocker (at the current threshold) on the source macroblock. If the deblocker is activated, encode the block as normal, as the original source has a block there and there's nothing you can do about it. Otherwise, go to step 2.
2. Encode the macroblock.
3. Run deblocker again. If it isn't activated, save the macroblock and continue.
4. If the deblocker is activated, re-encode the block with a lower QP. Place a limit on how much the QP can be lowered using this method.

Assuming the deblocker's method of finding blocks is good, this could work.

If the deblocker requires multiple side-blocks to find blockiness, then the entire frame could be encoded and then all the blocks dealt with.

[akupenguin]

The deblocker doesn't make decisions like that. The only places it doesn't activate are: where the gradient is high enough that it thinks the loss in detail from deblocking will be worse than any possible blocking; or where there's guaranteed to be no blocking just because of the modes involved (e.g. in the middle of a skip mb, under the assumption that the previous frame was adequately deblocked).
The deblocker doesn't avoid areas without blocking artifacts, it just has no effect there.

[Dark Shikari]

The deblocker doesn't make decisions like that. The only places it doesn't activate are: where the gradient is high enough that it thinks the loss in detail from deblocking will be worse than any possible blocking; or where there's guaranteed to be no blocking just because of the modes involved (e.g. in the middle of a skip mb, under the assumption that the previous frame was adequately deblocked).
The deblocker doesn't avoid areas without blocking artifacts, it just has no effect there.
Wait, then what does the threshold aspect of the deblocker do (the beta value)?

In that case one could simply use a blocking measure, like the one used by the MSU quality tester, to do the same.

[akupenguin]

Beta is the threshold of gradient. As I said, it has nothing to with whether blocks are visible, but rather whether deblocking is acceptable.

[Dark Shikari]

Beta is the threshold of gradient. As I said, it has nothing to with whether blocks are visible, but rather whether deblocking is acceptable.
Ah k, so the deblocker doesn't detect blocks, it instead looks as to whether deblocking would be beneficial, regardless of blockiness.

[DeathTheSheep]

So you're suggesting perhaps that x264 use a different/better rubric than simple gradient threshold to decide exactly where this deblocking "would be beneficial?" Or what parts of an image it should be applied "more strongly" perhaps?

Interesting... I wonder whether the deblocker could actually make such decisions.

[akupenguin]

You can't modify the deblocker's decision. The only parameters it has are alpha and beta, which are set per-slice.

So the idea is just "run the HVS metric on deblocked samples" (which cssim.0 doesn't).