Blockiness of dark areas

[unixfs]

Hi,
when encoding with xvid* and libavcodec (every version)
I experience always the same problem (especially when watching the movie with my standalone player on my TV): dark areas are never uniformly colored,
they are full of flashing dark gray blocks, even when encoded in
2-passes, with high bitrate (> 0.2 bpp) and with the supposedly highest quality settings, such as

for xvid4: vhq=1, me_quality=6, trellis, hq_ac, mpeg_quant, no b-frames
for libavcodec: mbd=2, trellis, no-bframes, mv0

When encoding with Tmpg in mpeg1 these artefacts *never* show up,
but the image is obviously much more faded.

Has anyone managed to get rid of this blockiness?
How?

Thanks very much.

[Nic]

Read through the post by kilgor in the FAQ, it may help with your encoding...

-Nic

[iago]

Easiest way -> reduce the brightness of your TV! :D

[sysKin]

The sooner xvid 1.0 final is out, the sooner I'll create new bugs - and a cure to what you're having is definitely among these bugs. In fact it's almost ready (not as a code but in a stage where I can just code in a matter of hours. Plus a week for bughunting ;p).

Radek

[iago]

sysKin,

Since this issue (blockiness of dark areas) has always been a matter of great concern to me (:D), I'll be looking forward to that first buggy build that you mentioned in your post!..

[unixfs]

Hi,
that thread is extremely interesting (I haven't reached the end yet).

I can't find that ColorYUY2 plugin; where can I download it?

Syskin, I hope your solution can be easily ported to libavcodec too,
so [S]VCD can look much better, too.

[iago]

unixfs

Since this issue was widely discussed in the past and a couple of workarounds already suggested (LumaFilter-UnFilter combo or blockbuster, etc.), I do not wanna go more into detail. Also, you can read the famous thread if you have the time. ;)

Btw, from my experience so far, it seems that "adaptive quantization" works in a different way now. Contrary to common belief and unlike what it did in the past, it no longer steals bits from the darker parts of the picture, but only from brighter areas. Therefore, at least theoretically, those bits taken from the brighter areas of the picture are possibly redistributed to dark and medium brightness scenes.

I'm not sure of course, but I think this point needs more testing and verification. If so, using "adaptive quantization" should already be helping with the darker parts of the picture, giving them the extra bits taken from the brighter parts, and actually not causing more blockiness, etc. in dark areas, as generally supposed.

Who knows??? ;)

regards,
iago

[Didée]

(Take this post with a grain of salt: I'm living behind the moon, still encoding with that stone old RC2 binary ;) )

Correction: Adaptive quantization uses higher MB-quants for very bright MBs _as well as_ for very dark ones.
(Watch such a video with ffdshow's 'visualizations' activated, you'll see the proof.)

The difference to the former implementation - the "new old" one, or was it the "old new" one? - (XviD veterans will remember this funny naming thing, in correlance to the hvs-based lumi masking ...) - is this:

The old implementation simply over-quantized everything that was under some given, *fixed*, lumi threshold. This worked well for bright scenes, but worked very bad for dark scenes: in those dark scenes, big parts of the frame, if not the complete frame, were under the threshold and therefore the whole frame was over-quantized.

In the Beta/RC builds, this has changed:
Now only MBs get overquantized that lie under/over a given threshold relative to the frame's overall luminance. Therefore, even in very dark frames, there is no chance any more to accidentially over-quantize the whole frame.

A dev, in the right mood, might explain it much more detailed. But the above should give the basic idea: no more absolut thresholding, but relative instead.

- Didée

[vijv]

if you increase your bitrate to 1000 and use adreas 78er matrix you will see far less block in dark scenes

[sysKin]

Originally posted by Didée
A dev, in the right mood, might explain it much more detailed.Nothing more to add, this is exactly what's going on :)

Radek

[iago]

Didée,

You're right (as usual). Thanks for clearing it up! :)

[crusty]

Somehow the 'old' technique sounds very, ...uhm.. what's that word for 'not-smart' again? :D

[Prettz]

How about an option to over-quantize very bright areas and UNDER-quantize very dark areas? :)

[iago]

How about an option to over-quantize very bright areas and UNDER-quantize very dark areas? :)Hehe, what about assigning only quant 1 to the dark parts of the picture!.. :D

crusty,

Of course you can come up with a "smart-er" technique, which would certainly be highly appreciated! ;)

[BoNz1]

Originally posted by iago
Hehe, what about assigning only quant 1 to the dark parts of the picture!.. :D

I have suggested this before and indeed it does work very well. The bitrate doesn't bloat too high in these sorts of scenes when you use quant 1 as it usually does but it is much higher than usual. However, this would be extremely useful if you where to be doing very high bitrate encodes. The thing with dark scenes is that they are very flat and don't have much detail usually. When there is detail XviD is fine of course. However, when it is flat there is also a lot of noise. If you cannot preserve that noise and grain you get a very ugly block smudged picture.

[Didée]

Related comment (http://forum.doom9.org/showthread.php?s=&postid=440451#post440451) from syskin.

And don't forget that mf suggested kind of an "inversed lumi masking" centuries ago ...

Let's await stunning new bugs;) after XviD 1.0 is here.

- Didée