Deblock_QED() bug (w/ screenshots)

[`Orum]

I've found an annoying bug in Deblock_QED (or, quite possibly, one of the filters it uses). I'm using masktools v2.0a36 for AviSynth 2.5.x (actually using 2.58), Deblock 1.2, DCTFilter V 0.0.1.4, and Deblock_QED dated 2008-08-18.

Now, most importantly, here's what I see:

http://img.photobucket.com/albums/v16/yoitsmeremember/broken/dbk_qed.jpg

The only filters applied after Deblock_QED are Spline64Resize and Crop. This appears when I use it on filmed footage too, but occurrences are irregular--the same frame may be good or bad, it's random. Sometimes these blocks go all the way up the frame. They seem to always be at the bottom or top, and always every-other column of blocks, and then proceed a variable amount up the frame.

Sometimes I also get other weird things, like this:

http://img.photobucket.com/albums/v16/yoitsmeremember/broken/dbk_qed2.jpg

Keep in mind this frame actually has other filters applied after Deblock_QED aside from just the resize/crop, but you can see other artifacts it sometimes produces. These behave just like the other blocks in the patterning and position on the frames, they just look different.

Has anyone else seen this? Does anyone know how to fix it? I hope I don't have to resort to another deblocker, as when it works it works very well.

Thanks in advance.

Edit: Another screenshot (http://img.photobucket.com/albums/v16/yoitsmeremember/broken/dbk_qed3.jpg) similar to the first, except with white blocks going almost all the way up the screen.

[Adub]

Screenshots don't really help that much. We can see the problem, but we can't replicate it ourselves. Post a small clip as a sample, and your entire script, so that we can replicate your tests completely.

[`Orum]

My script looks like this:
MPEG2Source("VTS_01_1 - 0xE0 - Video - MPEG-2 - 720x480 (NTSC) - 16~9 - Letterboxed.d2v")

TFM(d2v="VTS_01_1 - 0xE0 - Video - MPEG-2 - 720x480 (NTSC) - 16~9 - Letterboxed.d2v")
TDecimate(mode=1)

ColorYUV(levels="TV->PC")
Deblock_QED()
Spline64Resize(852, 480)
Crop(6,2,-6,-0)
As for a video sample...well, it not really relevant, this happens on *any* and *every* clip I use Deblock_QED on. I never notice this when seeking, only on an encode. It seems to happen more often if the processor is at 100% just from the encoding process, frameserving excluded. To easily replicate that, simply set x264 to brames 16, b-adapt 2, me tesa, and merange 32, and threads equal to the number of cores you have. Or just run a taxing game at the same time. I'm sure it's not an encoding bug, as it happens with XviD too (but that's harder to peg your CPU at 100% constantly).

It still seems to happen even when your CPU isn't at 100%, just a lot less frequently. Keep in mind, even when your CPU's maxed, this only occurs on about 1 out of 1000+ frames, but it's enough that I can't use it.

[Comatose]

Since you say it happens more often when your CPU is maxed, I suspect unstable CPU or maybe even RAM.

You should also redownload all the filters required for Deblock_QED() as one of them may be bad (DCTFilter?).

[`Orum]

Since you say it happens more often when your CPU is maxed, I suspect unstable CPU or maybe even RAM.

You should also redownload all the filters required for Deblock_QED() as one of them may be bad (DCTFilter?).
My CPU is underclocked, and my RAM passed memtest86+ not only when I bought it, but two days ago with the latest version as well. I would also be surprised if that was the case, as I have never seen bugs with any other filter (other than well known bugs).

I redownloaded the filters, and the hashes match exactly what I already have installed. I think the best thing to do now would be to individually test the functions used in the three different filters, and then the script separately to figure out where the problem is.