Hmm, still no overlapping blocks, apparently. Do other people find block artifacts less distracting than I do, and that's why nobody's trying to fix it for image and video compression?
Well, no, it's not - at least not in H.264. I have not read details yet on how it works in H.265, but in general deblocking is a completely different approach to solving block aliasing.
Deblocking works (very roughly) like this: look at the edges of the blocks and see if there's a sharp edge there. Now check and see how strong of an edge there is there in the original input. Depending on these two relative edge strengths, blur the block edge. That is, if there's a strong edge in the output, but not in the input, blur a lot. If the input does have a strong edge, blur less. H.264 also uses some other heuristics to decide how strong the edge filter should be, and happens to do the filtering on the encoder side as well as the decoder side, which allows for better interframe compression.
So while this, in a vague mathematical sense, does provide overlapping information between blocks in a way that can be analogized to overlapping blocks, that information is far cruder than true time-domain aliasing cancellation
But to answer my own previous question, the reason they don't use overlapping blocks appears to be that that the concept is very difficult to reconcile with motion compensation.
I think where it ends up being an especially big problem is with low-luma regions that have subtle gradients. A particularly common example is a scene showing the sky at night. I'm not sure what the crux of the issue is, but I think it may be some combination of the following hypotheses:
1. Psychovisual models are overly pessimistic about human perception of dark scenes and bit rate is reduced in these scenes too aggressively.
2. Large areas of subtle gradation cause the motion predictor to use big 16x16 blocks. This would be bad on two counts: i) the deblocker tones down to its lowest level on motion compensation boundaries, and ii) the deblocker can affect a maximum radius of 3 pixels from the edge, which would do little more than make the blocks look fuzzy.
3. Greater quantization in dark areas means that faint, transient noise like film grain is smoothed over, but the edge detector still sees it in the source frame, and that causes the deblocker to turn off (or at least weaken) on those blocks. If the noise were there, it would perceptually mask the boundary, but because it has been lost to other compression techniques, the block boundaries stand out. This particular hypothesis suggests that the problem could be reduced without modifying the spec by adding a simple luma-sensitive denoise preprocessing step.
Sort of, but you vary the weighting to fade the blocks into each other.
Or technically speaking, what you do is you multiply the blocks by a window function before you do the Fourier related transform. If you choose the windowing function carefully, you can even set it up so that all you have to do is add the overlapping areas together.
This is especially easy to understand in one dimension, which is more or less how MP3, Vorbis and AAC do it. Block boundary effects are so noticeable with audio that unless they are corrected very robustly, the quality is unacceptably choppy.
The technique generalizes basically without alteration to two dimensional data, but I've never seen an image or video algorithm that used it. JPEG just ignores the blocking issue entirely, and video algorithms seem to rely exclusively on deblocking filters. As I said, I think this has to do with the fact that TDAC doesn't trivially generalize to motion compensation.
