DGMPGDec 1.5.8

[LigH]

Recently I read a statement that some people recommend to disable the internal deblocking filter of DGMPGDec, even though it has the advantage of knowing the quantization factors per block ... but it has the disadvantage of doing a rather simple job. Other deblocking algorithms are probably smarter, but lack of knowledge about the original quantization when they are used after MPEG2Source(CPU=0).

I wonder if you could imagine any way to support other deblocking filters somehow -- maybe implement them yourself; maybe implement a kind of plugin system for postprocessing functions; maybe find a way to submit hints along the clip in AviSynth; ...

Just an idea. Just curious if your reply is anything else than "not worth the efforts".

[Guest]

"other deblocking filters"

As long as your request remains this vague, there is no way for me to respond. Specifically, what deblocking algorithm(s) would you like to see implemented?

[LigH]

I have some issues finding the thread again - since our german board was updated to version 4.0.3, the search engine is corrupted, the index incomplete... But I hope to be able to pull Didée here so he can tell you his opinions.

If I am not completely wrong, comparing with ffdshow's deblockers, DGMPGDec uses Nic's deblocking routines (with the h/v thresholds), which are quite fast but rather simple. Alternatives would be:

- mplayer deblocking
- mplayer precise deblocking
- fast SPP deblocking
- precise SPP deblocking
- precise SPP deblocking with soft threshold

I don't know much about them, except that SPP is quite slow but probably rather smart in comparison. But I could not link any proof for it. I hope Didée can tell you more...

[Guest]

OK, waiting for Didée...

Not Godot.

[Didée]

Sorry, but I don't really want to make any "please-implement-THIS" recommendations. My point of view simply is that Nic's deblocking routines are literally past century's technology, and just aren't state-of-the-art anymore ... myths are hard to kill, and many still do believe that mpeg2source's deblocking would be preferable because it's "internal" and because it "knows" the quantizers. Sure, it knows ... just that it usually smooooths-away too much detail nonetheless.

The most painless implementation, probably, would be to just use the Deblock() code that is already contained in DGDecode. That would "only" need some halfway-reasonable mapping for the quants (1-31 <> 1-51), and of course, adaption for the case of interlacing.

It's not the option that I personally would like the most, but of all available options it's probably the one that could be done most easily.


For the record, a small comparison of source vs. mpeg2source(CPU=4) vs. "blind" Deblock() vs. "blind" deblock_qed():

ClickMe (http://www.mediafire.com/file/tnm3cmnim5m/deblocking.avi) (1.4MB, MediaFire) (Use single frame stepping to compare.)

[Guest]

It's not the option that I personally would like the most I'll bite. What *is* the option you would like the most?

[Didée]

Could be it's not the best time to ask that ... all past years I still have been on a CRT monitor, and only now I'm about to switch to a flat panel, finally. now, CRTs are forgiving and inherently blurry, whereas TFTs are without mercy and inherently (too) sharp. Hence, my point of view might change in the future. ;)

But seriously ... to me it seems that the AVC-deblocker overall is a reasonably good basis. For the case of slight up to medium blocking, I do like the idea as it's implemented in the deblock_qed function (do the major deblocking only on block boundaries, but only little in the block interior areas - this still removes most of the visible blocking, but keeps much more of observed detail). However, when there is some "more severe" blocking, this strategy turns out not very good, and a plain Deblock(quant=big_enough) seems more pleasing.

So, while still using the basis of the existing AVC-Deblock() routines, a fairly sophisticated enhancement could go like this:

1) the deblocker uses Deblock() with adaptive quantizers acc. to the Q's of the Mpeg2 frame/block quantizers

2) the deblocker works at different strengths on block borders vs. block interiors
(actually, my qed() function uses DCTFilter to perform an 8x8-block-blur on the difference that the initial deblock() did achieve, and uses that blurred difference instead of the original difference for the inner 6x6 of a block. A lowpass, that is. Maybe DCT isn't the best option, but it was the easiest and fastest that I could only do at the script level.)

2a) this difference is modulated acc. to the actual block quantizer: for blocks with low quant, deblock mostly the borders. With increasing block quants, start doing more filtering to the interior regions, up to "full work" at some certain high quant and above. It would seem feasable to allow to specify a lower and upper threshold, to allow more control about how careful or aggressive the deblocking acts for any given block quantizer.

Huh, why do things aways sound so complicated once you try to put them in words ...

The versatility would be that, together with the quantizer thresholds, it would be possible to modulate the "smartness" from "too weak because tooo careful" at the one end, up to "same as good old naked deblock()" at the other end. No reason for anyone to complain, because everyone could set it as weak or as forceful as wished.

[LigH]

Yikes. One and a half year gone without considering this idea again.

So I created a thread in Donald Graft's forum (http://neuron2.net/board/viewtopic.php?f=7&t=190) to remind us on it, and have it done, eventually ... hopefully ...

[Selur]

Would it be possible to move the field option selection from DGIndex to DGDecode like it's the case in DGIndexNV and DGSource ?

[Guest]

It's possible but I don't see any compelling reason to spend my limited time to do it.

[Selur]

personally I thought it would be more convenient for the user, but if you don't want to don't it's your tool.

[Selur]

quick question: is it okay to simply change the field operation at the beginning of the d2v file, or does the d2v file have to be recreated?

[Guest]

Yes, it is OK.