How would you deal with this? (interlaced blend/blocking)

[charleski]

I spent quite a while trying to get this video into a form suitable for encoding. it comes from an MPEG-2 transport stream (yes, it really is 544x576 /boggle) with a low bitrate (~1.5Mbps). It's also clearly been badly converted from NTSC to PAL. restore24 certainly did wonders on cleaning up the blends, though a few were left. I was just wondering if i could have done anything better?

A major problem was the blocking in the original, and I ended up putting the deblocker before restore24 then giving a bit of sharpening to the analyse section of it. Was that the right thing to do? The noise filtering at the end is a bit heavy, and the end result is certainly soft, but it does elmininate most of the blocks and associated grunge, which I find more objectionable. As you can see by looking at the avs file I played around with a load of different options (until I finally got sick of it, TBH).

This particular project is finished and I won't be going back to it (the avisynth file took over 6 hours to render to a HuffYUV intermediate, ugh), but I will almost certainly come across similar dross in the future, and I would appreciate any comments on the script I used.

A cut of the original stream with the avs file I used is here (http://homepages.nildram.co.uk/~cajking/GrottyVideo.zip) (7MB).
TIA

[Edit]BTW, the reason I didn't use PixieDustPP was that it gave an access violation in the script at line 47 where pixiedustPP calls pixiedust. not sure why that happens, but I couldn't work out how to sure it.

[Revgen]

Have you tried using ffdshow's deblockers like SPP. You can use them by using ffavisynth.

Just open ffdshow and setup the post-processing the way you want it, then press "apply" and close.

Then enter

ffdshow("default")

into your .avs script.

[charleski]

I hadn't thought about using ffdshow, that would be worth trying.

Is it right to put the deblocker before restore24? Is there anything else I could have done to improve r24's performance?

[Revgen]

I think it would be better to deinterlace first, the deblocker might screw up the interlacing and make work more difficult for the deinterlacer.

[charleski]

Hmm, my rationale was that it's best to remove the artifacts in the order they were introduced.
It probably goes NTSC->PAL (field blending)->MPEG encoding (introduce blocking)->transmission, so I thought I should remove the problems in the reverse order. Actually, I tried putting the deblocking after r24, and found I would get some frames with really nasty residual blocks that had come through the r24 process. They were much less obvious if I did the deblocking first, which is why I ended up doing it that way. You can see the effects yourself if you download the example I posted: while r24 still yields residual blends from the first 2 wipes (which are really nasty in the original), it clears up the 3rd wipe to the car, but leaves behind blocking artifacts which I have to clean up in the final filters. Those artifacts were better if I deblocked first. But yeah, I was worried about how that would affect the operation of r24.

[Leak]

Have you tried using ffdshow's deblockers like SPP. You can use them by using ffavisynth.

Just open ffdshow and setup the post-processing the way you want it, then press "apply" and close.

Then enter

ffdshow("default")

into your .avs script.
The last time I tried using ffdshow's SPP that way (which was several months to a year ago) the results were a horrible blocky mess; probably because SPP can't get the quantizers that were used for each block and just assumes a quantizer of 0 or 31 or something.

Of course, using ffdshow as the VfW- or DirectShow-codec to actually decode the video and having SPP deblocking turned on works much better... :)

np: Takeshi Muto - Tape Birth (Expect More From A Past Life)