Need temporal deblocking, any ideas?

[themostestultimategenius]

:confused: I'm trying to process a video from HDTV broadcast source (ts file) that has some bad blocking artifacts. Worst part is the blocking is on the subjects and not just the background. One frame will be mostly ok but the next would have lots of blocking. I've tried smoothd but it didn't help much and resulted in loss of detail in the good frame.

I think i need a temporal deblocker rather than a spatial one. But i'm open to other suggestions. Here's a capture from a blocky portion of the video and then from one frame later (1920x1080i deinterlaced and resized to 720p):

http://img300.imageshack.us/img300/1386/clipboard1pw7.jpg http://img300.imageshack.us/img300/7494/clipboard2jv2.jpg

[Blue_MiSfit]

Damn, that's pretty tough.. Looks upscaled to me, lots of chroma blocking and smearing.

fft3dfilter/gpu @ sigma=3 for color, and like 1-2 for luma.

That should help the smearing a lot. Maybe LSF or at least fft3dfilter/gpu's sharpening to recover from the denoiser.

I don't really know much about deblocking. I do know that using DGMPGDec to do deblocking is a place to start.

~MiSfit

[foxyshadis]

DGDecode("....",cpu=4,moderate_h=50,moderate_v=50) # lower the strength to heavier blocks only
Deblock_QED() # this one you'll have to tweak the most - be sure to use one of the versions modified for 1080p
MVAnalyse()...
MVDegrain2() # see the docs for a standard sample

Customize to taste.

[IanB]

I've seen this effect a lot with HDTV, it seems to be caused by the mpeg encoder being very mean with the bit allocation for B frames compared to I and P frames.

Perhaps there is scope to add the frame type to the hint infrastructure in DGDecode so scripts an/or filters can adopt different strategies based on the original frame type.

And allow different parameters to the internal post-processing filter also based on the original frame type.

[Leak]

You could try decoding the file with ffdshow (using DirectShowSource), with SPP deblocking turned on. That's quite similar to SmoothD, but it has the added advantage of actually knowing the quantizers used for each block and thus adapting to the compression - it'll deblock the heavily quantized (i.e. blockier) parts more than the other frames.

[themostestultimategenius]

IanB: Actually the original tp file plays jerky and I thought it might be due to messed up bit allocation. So I think you're right about that.

Thanks guys for all your help. I'll probably end up doing a lot of experimenting before I get a satisfactory result. But you've given me some good ideas.

[cwk]

Do the frames alternate in blockiness? For example:

blocky
non-blocky
blocky
non-blocky
blocky
non-blocky

etc.

Or are the blocky frames randomly distribute?

[[P]ako]

I would downsize it, it's not worth keeping it as such a high resolution.