I came across SPP deblocking setting by accident in the ffdshow alpha build 27. Feb 2004. Obviously it is some for of deblocking. Does anybody have any more details?

It blurs an awfull lot and it does so eating plenty of CPU cycles. 70%-80% on my Athlon 64 3000! That is without any form of deringing (but both chroma/luma v/h). If deringing is enabled, playback slows to a stutter.

I checked Google and Doom9, but there is almost no info available. Only that it needs a "matrix" that would have to be included while encoding. Are they talking about the matrix of DCT coefficients?

ooh, i had no idea there was a new build of ffdshow...

i'll download it and get back to you

just from what you describe, it looks like it uses the matrix to make an educated guess as to how much Q noise there is for each coefficient, and then processes accordingly, rather than doing a general filter based solely on macroblock quantizer. that's my guess anyway.

[edit]

hey, wow. that's really pretty postprocessing. KILLs my CPU though. 3fps playback... it could be useful for inputting into avisynth for encoding though, although at that speed it's slower than a homegrown denoiser script.

the de-ringing is beautiful.

i _think_ what it might be doing is calculating the probable error for each coefficient, then "jittering" them within the error tolerance and averaging the result. that would certainly explain why it's so slow. it seems to turn ringing/blocking into blur. not a bad idea i think, though it seems over-conversative.

It is part of the mplayer code, it is based on work by Aria Nosratania.

It applies DCT->quant->dequant->iDCT on shifted versions of the decoded frame and sums the result (without the shifts). This is a form of denoising by thresholding an overcomplete shift-invariant transform (well it is shift invariant if you do it for all possible shifts, the default only does it with 8 shifts ... with 64 shifts it would get REALLY slow :). By using the same quantization used in the original encoding you ensure the solution will be near the quantization constraints (not guarantueed though).

It works quite nicely, although I think there is room for improvement in determining how to weight the contribution resulting of each block after iDCT ... the original papers do explain that the global optimum is a mostly flat weighting (except for the 0 shift) but I think there might be good ways of determining the locally optimal weights.

Try using it for movies coded with h263 quantization ... it doesnt handle stuff with custom matrices properly yet.

Thanks for your replies.

Pinky's brain, do you mean Aria Nosratinia? It would at least seem to be his field of expertise. He has published a paper which deals with this subject. This one seems like a follow-up.

Ya, that's the one.