smart deblocker

[jmac698]

yes, I've read some posts referring to keen, deblock, QED. There's not enough info on how they work. I want advice on this, I only need deblocking on scene changes and high motion areas. Is there this type of "smart" deblocker? Doesn't it seem obvious that you could use motion vectors to adapt the strength of deblocking, in real life it's always in the scene changes and motion.

[foxyshadis]

Deblock_QED adapts to the amount of blocking present in each block via masks, but it's fairly conservative in its block removal. Importing via directshowsource you can use xvid, ffdshow, or whatever to do adaptive deblocking based directly on each block's quant; very blocky frames are much higher quant. No other filter can access that information once it's in avisynth.

Then there's mcnr_simple, a motion compensated denoiser also by Didée that you can probably use in conjunction with deblock_qed, to help the worse blocks that it leaves alone (and the video in general). Deblock_qed could probably also be modified to only work on heavy blocking, rather than only light blocking as it is now. You can also use a vector-based resizer like eedi2 to reconnect minor disconnects caused by blocking, so edges look smoother (BlockTerminator does this).

Hope that helps a little.

[Emp3r0r]

jmac698: is this for 1080i hdtv? and if it is, what is your target resolution?

[jmac698]

No other filter can access that information once it's in avisynth.
Does that mean, "No other filter (besides Deblock_QED)..." or "No [...] filter can access..."
In case 1, use Deblock_QED only, in case2, decoder only, and not in a script.
If decoder only, which one has the most potential? (I know, I have to experiment myself at some point).
...via masks I imagine this might mean, looking for edges/high freq., somehow, to find those blocks.

My assumptions were: 1) constant deblocking blurs all parts unecessarily 2) in my source, static areas were ok and I wanted them left alone 3) in bad areas I need a strength control.

vector-based resizer like eedi2 to reconnect minor disconnects your saying, a block that is high quant. will have a larger motion error thus non uniformly moving parts of edges, which you mean "disconnect". In other words we need to track the decoded motion and "smooth" it despite how it's encoded?

As far as noise, I see gradations of shading clearly, what are some reasons for this? I think that, if I view with the wrong gamma I could see steps, but maybe also there is an MPEG type reason for this.

I'm not trying to resize at the moment, just want to view it nicer.

[Mug Funky]

high quant blocks don't necessarily have motion error, rather they don't use enough bits to correct the error inherent in the motion-compensation - they have "texture error", but good motion. this is why static scenes and global motion will look fine - it can be compensated very well, so even high quants will do without things looking off (so long as the texture in the reference block is of a high enough quality, which isn't always the case).

[foxyshadis]

"No other filter can access that information once it's in avisynth." I meant the encoded stream's quantizers; playback filters like xvid and ffdshow vary the strength of postprocessing based on each frame/block's quantizer. Once you've imported the video into avisynth no other filter gets to see any of that though, so if you use it at all it has to be via directshowsource. A mid-strength deblocking (no deringing) in ffdshow can help bad parts a lot. That's the easiest adaptive you can get.

Even if you don't resize in the end, you can still use eedi2 and then resize again back to your original size. If you look closely at very bad blocks, you'll notice that lines don't quite line up, they're kind of disjointed across block boundaries. Still, using eedi2 has its own issues (speed, artifacts) and is best for really noticeable stuff or specially masked off.

As for banding (gradient steps), that's due to the lower colorspace of YV12 that mpeg uses.

[redfordxx]

"playback filters like xvid and ffdshow vary the strength of postprocessing based on each frame/block's quantizerand dgdecode? it accesses the encoded file directly too, doesn't it?

[neuron2]

and dgdecode? it accesses the encoded file directly too, doesn't it? Yes, DGDecode has access to the MPEG syntax, including quants.

[redfordxx]

Yes, DGDecode has access to the MPEG syntax, including quants.So, my guess is BlindPP and Deblock can't use it but MPEG2Source(..."xxxxxx"...) can and is adaptive deblocker?

[Mug Funky]

only problem with adaptive deblocking is you get a kind of flickering detail... b-frames get deblock/deringed far more than p-frames, and things can look oversmoothed and "pulsy". this isn't a big deal when only deblocking is enabled, but the dering filter in dgdecode is quite strong and can hurt detail (or quant noise that looks like detail... at that point it's hard to tell which is which). a temporal filter can be used to restore image stability, but it's more likely to favour the b-frames and remove what detail remains on p-frames.

this is probably fine if your source is HDTV and you're resizing down to SDTV. in fact it's probably desirable.

[redfordxx]

Well, whoever reads this thread might be interested in this (http://forum.doom9.org/showthread.php?p=825082).

only problem with adaptive deblocking is you get a kind of flickering detail... a temporal filter can be used to restore image stability, but it's more likely to favour the b-frames and remove what detail remains on p-frames.Ok, to solve it...any favorites or recommendation? Namely, I always made more damage than help with temporal filtering

[dukey]

a good deblocking would be only that ONLY deblocks the parts of the image which actually need it. All too often deblockers just decide they are going to deblock the whole image which often results in a very unrealistic smoothed look over the whole video.

Ie where mpeg oftens fails is on colour graduations on walls .. etc. It would be good if a deblocker could deblock that, and leave the result of the image untouched for example.

[redfordxx]

a good deblocking would be only that ONLY deblocks the parts of the image which actually need it.Well, I don't know whether it is meant reaction on my post/link. But I have to say that's what I wanna achieve by three things (e.g. in case of ReDeblockLite version):
1)adaptive deblocking base input
2)LinearBlock application
3)correction convolution

[redfordxx]

Importing via directshowsource you can use xvid, ffdshow, or whatever to do adaptive deblocking based directly on each block's quant; very blocky frames are much higher quant. No other filter can access that information once it's in avisynth.

I have an idea --- guys, pls tell me whether you think it's crazy or feasible:

How about guessing a quant of a block (from amout of detail in it) and create deblocking strenght mask from it? Maybe with DCTFilter (but I have no idea how it works) and masktools.
(when not dll code)


[EDIT]Hey, I tried and it seems to work, I'll probably make another deblocker

[redfordxx]

Hi,
I have made the idea happen (at least I am on the way).

Jmac698, if you have lot of time and/or many GHz at home, can you take a look on SmoothDeblock3 (http://forum.doom9.org/showthread.php?p=835683#post835683)? I will appreciate feedback, how it behaves on your blocking issue.
Whoever else's welcome too, of course.

[markanini]

"No other filter can access that information once it's in avisynth." I meant the encoded stream's quantizers; playback filters like xvid and ffdshow vary the strength of postprocessing based on each frame/block's quantizer. Once you've imported the video into avisynth no other filter gets to see any of that though, so if you use it at all it has to be via directshowsource. A mid-strength deblocking (no deringing) in ffdshow can help bad parts a lot. That's the easiest adaptive you can get.
Sorry for digging up this ancient thread but has anything new materialised from the idea about a deblocker adapting to source quantizers?
Basically I'm playing with SPP deblocking in ffdshow thinking to my self "It's nice not having to adjust all those parameters in Deblock_QED. I wonder if theres anything better though..."

[markanini]

I'm gonna go ahead and answer my own question. Seems mplayer is the ticket, lots of different methods and parameters that use source quantizers.