DCT blocks in dark (and solid) areas

[bot]

Firstly, yes, I did search the forum.

Secondly, one answer (from Koepi, I believe) was to lift the luma threshold offset with the 'Lumaoffset' avisynth filter. Does that still stand as the way to go?

But wouldn't the encoder be doing the same thing with the lifted luma threshold darkness? Are there other issues with dark areas? (And how visible would a lifted threshold be as gray instead of black?).


And...
as I understand it, the blocks comes from the encoder giving smooth surfaces (and gradients) too much compression, causing misalignments between macroblocks (showing up as a mosaic). Is that correct?

So can you trick the encoder into allocating sufficient bits by adding slightly offsetting noise in troublesome areas (hoping that it can be done at a level that won't be visually disturbing) instead?

[lordadmira]

Short answer: no. We're currently discussing this in this thread.

LA

[Prettz]

He's talking about something different from that thread. He's talking about the classic over-quantization of the chroma components in areas that have very high chroma and very low luma.

I believe that right now the only solution is to throw more bits at that scene by using zones.

[bot]

Would a customized quant matrix alleviate the problem?

[Koepi]

Unlikely, but you might try MPEG or HVS BEST/BETTER quant matrices.
(H263 smoothes out [and therefore blocks] the most due to it's 'insensitivity' to certain frequency<->detail correlations ["all 32 matrix"]).

Regards
Koepi

[bot]

Thank you for your replies. I'm still trying to get my head around this, and I'm currently stuck in this thought:
If a low_luma + high_chroma scene breaks (or tricks) the codec to quantize too much, why can't a special LowLumaHighChroma matrix alleviate the problem? (And vice versa with gradients).



I don't have samples available at this time, but IIRC, the blocks appear mainly in low frequency areas, no?

[lordadmira]

AFAIK it goes by total brightness, it doesn't care about chroma individually. It's not so much that it "overquantizes" as that whatever tiny gradient there was is blown away by the quantizing process. This results in the entire block being one solid color or nearly so. An adjacent block undergoes this same process but it's resultant solid color area may be a few points different than what's next to it. You can see color differences much better when they're in the form of two large solid areas. Even 1 point difference can be visible. From the codec's point of view there is a teeny variation from the original that is well within the "detail removal limits". But to the human observer there are large color blocks. In theory it would be possible to write a routine into the codec to handle these scenarios but fundamentally it's a limitation of the entire Mpeg4 paradigm.

LA

[bot]

Ah. I can see how that applies to gradients, but not to the low luma situation.

And, "fundamentally a limitation of the entire mpeg4 paradigm";
what is it about mpeg2 that makes it not produce blocky images if the bitrate is high enough (/quant is low enough)?

[lordadmira]

A "low luma situation" is a very fine gradient whose brightness happens to be around zero.

Mpeg2 does create blocks. They're less noticeable because the videos tend to be very high resolution, the matrixes are very high quality, and the bitrates are usually very high (6 - 10 Mbps). Mpeg4 can be made to have these same characteristics but u won't have convenient file sizes anymore.

[Prettz]

Keep in mind that both chroma channels are subsampled horizontally and vertically in the YV12 color space (1 chroma pixel corresponds to a 2x2 block of luma pixels). Now when you apply ANY kind of quantization to the subsampled chroma pixels, you're going to lose considerably more detail than you are with the luma plane. Normally you still don't even notice this, but when there's virtually no luma in an area and the area's details are defined mostly with a single chroma channel (meaning dark red or dark blue), then you tend to really notice the quantization artifacts, whether it's blocking or just ringing.

The only way to solve the problem is to significantly increase the resolution (and bitrate) of your video clip; not a very good solution just to increase the quality of a few scenes. Otherwise even the most inefficient, ultra-high-detail matrix still isn't going to give you the quality you want in those dark scenes.

[Manao]

Now when you apply ANY kind of quantization to the subsampled chroma pixels, you're going to lose considerably more detail than you are with the luma plane.

That's wrong.

[Prettz]

Originally posted by Manao
That's wrong.

How is it wrong that you lose more detail by applying quantization to a subsampled plane than by applying it to a full-res plane? I'm just trying to help explain these things to bot and anyone else reading this thread who's new to these concepts. I'm certainly not trying to offer up a bulletproof academic disertation on the subject.

[Manao]

It was late, I should have explained more :

Quantization is roughly equivalent to rounding float numbers to int. Now imagine you have a serie of random floats, and you round them to the closest int. The mean error will be 0.25.

Now take a serie of random floats, but each float is repeted once ( IE : 0.2 0.2 1.6 1.6 0.5 0.5 3.3 3.3 ... ). The mean error, when rounding to the closest int, is exactly the same.

In such a case, details are lost before the quantization, in the subsampling stage.

[Prettz]

Originally posted by Manao
It was late, I should have explained more :

Quantization is roughly equivalent to rounding float numbers to int. Now imagine you have a serie of random floats, and you round them to the closest int. The mean error will be 0.25.

Now take a serie of random floats, but each float is repeted once ( IE : 0.2 0.2 1.6 1.6 0.5 0.5 3.3 3.3 ... ). The mean error, when rounding to the closest int, is exactly the same.

In such a case, details are lost before the quantization, in the subsampling stage.

Don't get me wrong, I understand how quantization works. Perhaps my explanation was a bit too simplified. However, it's still correct to simplify things to the point of saying that the same strength of quantization affects the subsampled chroma planes considerably more strongly than it does the luma plane; even if in most cases its effect is unnoticeable to the human eye, the effect is still there nonetheless.

[bot]

Just to be sure, the repetition of the floating point number in this analogy represent the effect of subsampling the chroma channel?

If so, how does that not make the global effect of quantization of subsampled chroma more noticable?

Mpeg2 does create blocks. They're less noticeable because the videos tend to be very high resolution, the matrixes are very high quality, and the bitrates are usually very high (6 - 10 Mbps). Mpeg4 can be made to have these same characteristics but u won't have convenient file sizes anymore.

I don't get it. Then why wouldn't lower quant and higher bitrate in these scenes affect the problem?

[RANT]
Why can't a very high bitrate quant matrix be used during these conditions (or even smaller macro blocks)? ...Even if they have to be manually applied as zones to each scene? Can the encoder be made to interpret the scene and apply something similar to what makes mpeg2 hide these artefacts so well?

I don't mean to come off as demanding impossible or super complicated new features of the encoder; I don't understand the intricasies of programming, of the mpeg4 standard or how the encoder works.
[/RANT]

[*.mp4 guy]

what there saying is that you would have to encode the entire thing at super high quality to get rid of your problem, at least thats the impression i got.

Or you could try using a high bitrate matrix that scales well for the entire video and setup a zone for the problem scene that locks the quant at one for a while, that might work, but the rest of your movie would be degraded or the filesize would go, up i think.

[bot]

Originally posted by *.mp4 guy
[...] but the rest of your movie would be degraded or the filesize would go, up i think.

But the objective is getting a constant picture quality?

[*.mp4 guy]

It would yield a more constant picture quality, but in return for this you would loose compressibility. To really know whats going to happen youl just have to try it with different settings.