Support better deblocking algorithm in MPEG2 decoder

[LigH]

It is already a while ago that I asked in another forum, and because if was probably forgotten since, I'll ask here again:

Do you have time and interest in enhancing your software-only MPEG2 decoder by implementing more modern and effective deblocking algorithms than the existing one?

I will not copy and paste »Didée's explanation why Nic's deblocking is not recommendable anymore, despite its advantage of knowing the quantization factors« – so please read it in detail again in doom9's forum, using this link.

Just in brief:

• An MPEG2Source() internal deblocker has the advantage of knowing the source video's quantization to tune its strength and threshold on its own.
• The currently used deblocker related to CPU and CPU2 parameters (Nic's algorithm) fails taking this advantage by being less efficient than other more modern algorithms.
• The additionally available Deblock() filter, based on a H.264 implementation by Manao, has the advantage of being more efficient, but the disadvantages of not knowing the source quantization and requiring a manual strength parameter, and operating on MPEG4-AVC/H.264 quantization parameters instead of MPEG2/H.262
• For some cases with rather fine quantization and little blocking, the pure Deblock() result can be too strong, an attenuation as implemented in deblock_qed() would be recommendable.

So the request would be to implement the additional use of Deblock() as alternative to the parameters CPU and CPU2 in MPEG2Source(), and optionally even the QED attenuation. Possibly via parameters like:

MPEG2Source(..., bool useDeblock, float qed)

(just a suggestion; practical reasons may prove it wrong or not...)

Please don't miss that it would have to work with interlaced sources too. Find Deblock_QED with a modification by Bi11 in »this thread on doom9's forum«.

[hydra3333]

+1 for interlaced...

[Rocky]

I know LigH has been waiting a long time for this. With an active request for BlindPP functionality enhancement from real.finder it seems an appropriate time to re-engage with this thread. Honestly, it seems unlikely anything will be done for BlindPP because it is fully wired for _asm. Functions combine C code and inline asm to an extent that would make it difficult to move the asm to external files. And even if that could be done, I'm not confident in my asm skills enough to think about extending it to HBD. I have been unable to find C code versions of Nic's postprocessing. So let's look again at Deblock().

We could fork from this and make it dual Avisynth/Vapoursynth:

https://github.com/mysteryx93/Avisynth-Deblock

@real.finder

If Deblock got a 64-bit version with Didee-like QED stuff and HBD could you be happy? Yes, FunkyDeBlock and SoftSharpen would need to be modified, but is it so difficult?

[real.finder]

Deblock() already got HBD and x64 https://github.com/mysteryx93/Avisynth-Deblock/releases

and I am already did update Deblock_QED to work with HBD

anyway, can BlindPP be replaced with something that can give similar output? I did try back then https://forum.doom9.org/showpost.php?p= ... tcount=264

[Rocky]

Ha ha, your post and my edit passed like ships in the sea.

What does BlindPP do that Deblock_QED does not? Please show with screenshots if possible. I looked at some comparisons I found on Doom9 and to me Deblock_QED crushed BlindPP.

If it's all just to upgrade FunkyDeBlock and SoftSharpen I'm not that interested, given my progress bar of life.

[real.finder]

I have been unable to find C code versions of Nic's postprocessing. So let's look again at Deblock().

maybe you can find it here https://web.archive.org/web/20030214183 ... alias.com/ (XviD Binaries / DShow Source Code)

[Rocky]

C'mon, you think I didn't find that? There are only binaries there as far as I can see. Looking for C/C++ source code for Nic's postprocessing!

Hoping you answer the query in my previous post. Any chance of that?

[real.finder]

There are only binaries there as far as I can see.

https://web.archive.org/web/20030410210 ... ow_src.zip



don't know if it can help

about "Hoping you answer the query in my previous post. Any chance of that?"

I don't need BlindPP because it's better than anything, I just see it as some basic function (same as avs blur or any other basic thing like RemoveGrain), I see it used in scripts function so I need it, or if there are a way to replace it (again as it, mean similar output and share same basic parameters)

[Rocky]

https://web.archive.org/web/20030410210 ... ow_src.zip
don't know if it can help

Nah, it's just the inline _asm stuff. Didn't you look at it?

about "Hoping you answer the query in my previous post. Any chance of that?"

I don't need BlindPP because it's better than anything, I just see it as some basic function (same as avs blur or any other basic thing like RemoveGrain), I see it used in scripts function so I need it, or if there are a way to replace it (again as it, mean similar output and share same basic parameters)

You won't give the screenshots that would show me what you mean by "similar output", so really, what am I supposed to do.

OK, here it is. I'm not doing anything with BlindPP unless a compelling case is made. I simply don't have time for doing stuff because it would be nice.

No offense intended. We're still buddies, right?

[real.finder]

away from offtopic BlindPP, did _Quants* (_QuantsMin, _QuantsMax, ETC.) properties help here or it has to be per frame blocks? so in this case new an array _Quants property (that got the blocks values from the top left to the bottom right) will be needed I think and of course the deblocker have to be update to read it

[Rocky]

That's an interesting idea. Could be a lot of data, especially for HBD. Maybe a string property could be used. I'll look into it for future release. Not for the pending DGMPGDec 2.0.0.7 to be released today.