Help to remove the blocks

[huang_ch]

I've met a blocky problem when I'm encoding Robotech. The source contains much noise, but with Chainmax's help, the noises are filtered a lot with a script. But after encoding it with X264, I found many blocks appeared which is not very easy to see in the source. My first guess is that maybe the bitrate is not enough, so I went to try --crf 18 and even 12, but the blocks still exist, almost the same with --crf 24~26. And I've also played with AQ/BlockBuster, nothing seems to work. So I'm asking for some suggestions here. Thanks.
The source (denoised) screenshot:
http://img270.imageshack.us/img270/7005/rawed2.png (http://imageshack.us)
The encoded screenshot:
http://img226.imageshack.us/img226/2476/snapshot20061216170235jlt6.png (http://imageshack.us)
Notice the background in the middle and the left area of the arm of the man(the right one).

[DarkZell666]

Try using --no-fast-pskip option (if you haven't done that already), or change CQM.

I notice that the encoded result is darker and has much less contrast than the raw denoised result too (wierd but don't have a clue why ^^')

[Manao]

It's also insanely blurry. Is it due to the heavy denoising ? Don't use blockbuster, but I'd still advise to use AQ. On such sources, it won't hurt.

[huang_ch]

to DarkZell666, I've always been using --no-fast-pskip, never tried to drop that option... And the darker, I don't know why, because others doesn't have this problem, but that source screenshot is not directly taken from source, but save from MPC, so maybe something with MPC.
to Manao, yeah, you're right, it is blurry, and the cause may be the denoising, for the source is heavily noised. I've adjust the script to have more sharpen on it. But as I mentioned in my post, I've tried AQ, but no obvious improve, even using AQ with strength 1.1 and sensitivity 5 or 22 with --crf 12, doesn't help.

[Sharktooth]

You removed too much noise... also edges are insanely blurry.
Codecs tend to "block" when there is no or very little noise... so try to remove less noise (you will also have a more detailed picture).

[huang_ch]

You removed too much noise... also edges are insanely blurry.
Codecs tend to "block" when there is no or very little noise... so try to remove less noise (you will also have a more detailed picture).

I've tried to reduce the strength of denoise filter, it does help to reduce the block a bit, though not all. But the question is that, why the blocks still exist even not improved by using a much lower --crf 12?

[Sharktooth]

x264 always behaved like that. Probably it's due to some kind of speed optimizations.
as a last resource, you can always add the BlockBuster filter (method=noise) after the denoising and tune it for your encode.

[Morte66]

Try using this antiblocking custom quantisation matrix written by mp4guy:
http://www.joel-benford.co.uk/posts/M4G-V3.cfg

Command line is --cqmfile "C:\Program Files\MeGUI\extra\M4G-V3.cfg" or similar, according to where you put it. If you like that and you use B frames, also try --direct none.

That combination will give a much bigger share of the bitrate to smooth areas. It needs about 30% more total bitrate to come out even on the sharp parts.

[huang_ch]

Try using this antiblocking custom quantisation matrix written by mp4guy:
http://www.joel-benford.co.uk/posts/M4G-V3.cfg

Command line is --cqmfile "C:\Program Files\MeGUI\extra\M4G-V3.cfg" or similar, according to where you put it. If you like that and you use B frames, also try --direct none.

That combination will give a much bigger share of the bitrate to smooth areas. It needs about 30% more total bitrate to come out even on the sharp parts.

Thanks. I've tried that matrix, the result is pretty similar to AQ, which is that both AQ & Matrix does help to reduce the block a bit (indeed, the most visual effect is that large blocks are improved to multiple-small blocks with AQ/Matrix). But there're still many blocks available.

[Morte66]

Oh well, so much for that.

Blocking has always been x264's big issue, you could try using another encoder for this one file. Maybe Xvid/DivX, or even MPEG2 with QuEnc or hc. [I don't really know if this would help, it's just something to try.]

[Didée]

You definetly have to improve on the processing side, before encoding. With such a mis-processing as shown above, no codec will produce a result that you like. The posterization caused by FFT3D is obvious, and is a must-not for mpeg4 codecs.
Also, practically all dark image features are washed away. Is there really not more to get from the source, or was it some overly halo-removal filtering, plus the denoising ...

[DigitalDeviant]

Ahhh... Robotech/Macross!

Would it be possible to upload a short segment of the original .vob? I've played around with encoding the recent R1 ADV Macross releases but the old Robotech is in a lot worse shape.

[Audionut]

Looking closely at those screenshots. Personally I don't see many blocks at all, and what I can see is directly related to that banding in the background.

I would see if that banding is there in the unprocessed source.

If it is, I would as suggested, use less filtering, but apply a debanding filter and addgrainc(8,0,0)

If it isn't, then I would use less filtering and more importantly try a combo of different filters with a debanding filter if needed and addgrain.

In my experience h264 has problems with banding.

You could also try reducing --deadzone-inter and --deadzone-intra

[huang_ch]

One source is posted in another thread:
http://forum.doom9.org/showthread.php?p=907557#post907557
It's really heavily noised. I'll try to adjust the filters according to all of your suggestions. Thanks.

[ChronoCross]

lol I enjoyed that other thread. it's always fun to watch chainmax try to remove all the noise in a source.

After looking it over.....your screwed. Whatever company encoded those in the first place should be killed. The fact that they actually made you pay money for it is pretty insane.

There's no way to remove all the damage done to that video so your going to have to settle for blocks.

I would recommend turning down the filtering because your doing too much. perhaps trying to enhance the lines of the anime can deceive the mind a bit. as for the blockiness and lack of detail (remove any hardcore filtering your doing). you can use fastlinedarken or kmftoon(something like that) to do the line darkening/thinning. USe DGINDEX's Built in postprocessing to help fight some of the natural mpeg blocking and maybe apply a light deblocker(any one will do).

the best thing you can do in this source is to forget about removing noise and worry more about the blocks.

btw who did you buy this DVD from? is it from ebay pirates? That source makes me crazy cause I'm sure the source material isn't that bad, just horrible mastering.

[huang_ch]

ChronoCross, what I get is just DVDrips.... So I'm not aware from where the DVD comes out. About the blocks vs noises, I must say that, the blocks shown in this thread doesn't appear all the time while those ugly noises are everywhere, so I'd rather see these blocks sometime than see those noises all the time.... But as all of you suggested, I'll try to lighten the strength of those denoise filters to make a balance.

Indeed, what I'm using today is pretty light than the one Chainmax gave, which is like below:
DeHalo_Alpha(ss=1.2)
Deblock(35)
fft3dgpu(sigma=1.5,sigma2=2.5,sigma3=3.5,sigma4=3.5,plane=4,precision=0,bw=32,bh=32,ow=16,oh=16)
aWarpSharp(depth=20,cm=1)
dull=last
sharp=dull.LimitedSharpenFaster(ss_x=1.0, ss_y=1.0,SMode=3,Strength=30)
Soothe(sharp,dull,25)

[ChronoCross]

I'm not sure why the awarpsharp limitedsharpenfaster combo. That's actually going to make the blocking worse.

Oi I totally overlooked the fact that your going from AVI Rips that have already been encoded...probably rule #6.

If your not really interested in noise or blocking then you should give deen() a shot. it'll whipe quite a bit of detail but it's obviously not the goal here to keep that much fine detail but more to remove noise and blocks and I find that it works really well in that respect. Try something like

awarpsharp()
deen("a3d",4,4,4,4)
crop()
Resize()

That should let you judge if you want to use this filter at all. Try tweaking the values and see if it gives you the improvement your looking for.

[cacepi]

I notice that the encoded result is darker and has much less contrast than the raw denoised result too (wierd but don't have a clue why ^^')
Wrong colorimetry is my guess. IMO, ColorMatrix() should be a rule, not an option.

-Edit- Oh, they're AVI files. And it's a possible crosspost. Better pray for some balls, batter; I smell strikes in your future.

[huang_ch]

I've tried to directly encode the source without any de-noise, the blocks still exists though its much smaller than the one after de-noised. One thing I'm pretty confused is that why this kind of blocks always exists regardless how much bitrate I set?

Another question about this kind of blocks, if I already have an encoded video with this kind of blocks, is there any filters made specifically to remove/reduce this kind of blocks? I found that if I look at some source more carefully, most of them have this kind of issue, even WMV codec.

[shon3i]

It's also insanely blurry. Is it due to the heavy denoising ? Don't use blockbusterWhy not blockbuster? Did you maybe have other solution.

[Manao]

If you're going to add noise, do so on playback. Adding noise before encoding is the less efficient way.

[Morte66]

@huang_ch

You might find this thread interesting:
http://forum.doom9.org/showthread.php?t=112968

[foxyshadis]

One thing I'm pretty confused is that why this kind of blocks always exists regardless how much bitrate I set?
People have already recommended tweaking the deadzone settings, did you even try it? They specifically lower the flat-block threshold, and although they might raise the bitrate slightly, it shouldn't be anywhere near jumping 6 whole crfs.

Another question about this kind of blocks, if I already have an encoded video with this kind of blocks, is there any filters made specifically to remove/reduce this kind of blocks? I found that if I look at some source more carefully, most of them have this kind of issue, even WMV codec.

Grain+Deband with a high threshold. FFdshow has both filters, make it your friend. The only place totally noise-free animation looks good is flash and lossless masters; you just can't get that sort of sharpness out of DCT codecs at a reasonable bitrate, so you'll have to trick the eye somehow.

[huang_ch]

Just tried several things these days:
1. Lowing Deadzone, both inter/intra to 6 or even 0, but no obvious visual effect, don't know whether it is low enough.
2. Add debanding, tried to add it before encoding, but sometimes it got even worst. But apply that at playback seems really useful, but one issue is that even I apply the lowest threshold (1.01), I can see some jumping/moving dots in those block areas, is this the correct result when using debanding?
3. Tuning filters, tried Deen to replace those denoises, also no better.
4. Trying mp4's CQM with more sources, though the effect is not very impressive, not many blocks removed just as I mentioned in a previous post, but I have to say, it gave the best result in all the things I've tried by now.

And some questions related to that CQM are: (what I use is M4G-LRM-V4)
1. I uses B-frame, and I've tried --direct none, don't find any impact, does mp4's CQM prefer to use --direct none or just suggest to try?
2. Also see in MP4's CQM thread about tuning deadzone, but since I didn't succeed in see any difference by changing deadzone, is there any preferred value for these 2?

[Audionut]

IMHO those tiny blocks that I'm struggling to see are directly related to the artifacts in the source.

To say that even with crf 12 you are still seeing blocks, strongly suggests that it is a problem with the source.

As the ideas given to you already haven't worked, for what it's worth, You either need to fix the source or apply stronger deblocking settings in x264 and addgrain to hide any remaining artifacts.

Also, afaik debanding filter shouldn't produce the effect you described.

edit: And I had a quick play with your source posted and it's horrible. When I apply denoising it produces a dup frame effect. The video moves but the noise remaines for a frame. Way out of my league.

[Morte66]

IMHO those tiny blocks that I'm struggling to see are directly related to the artifacts in the source.

I've been down the same road as haung-ch and I agree.

I'm pretty sure that:

- Bad MPEG2 on DVD/DTV includes lots of blocks hidden by lots of noise.

- Removing the noise reveals the blocks, which can be really nasty (at least with noise you can move a few feet away from the screen). x264 acts inherently as a strong denoiser.

- x264 can introduce blocks of its own, especially in smooth dark areas viewed on a bright/contrasty LCD (CRT is too dim to show these). You can tackle this quite well with CQM/AQ etc. [You've probably done this job already, judging by your posts.]

- So the blocks in a vanilla x264 encode will be partly created by x264 and partly revealed by x264. Adjusting x264 settings won't do anything for the blocks it reveals.

- There is no way to satisfactorily tackle MPEG2 blocking going into the encode, you just swap problems around. Standard DGIndex deblocking often makes things worse. You can turn blocks into blobs, at the cost of detail. Blockbuster adds noise, and x264 largely ignores noise.

- So you are going to have the original MPEG2 blocks in your output, whatever you do. The question is: are you going to put up with them, or are you going to hide them with noise?

- After a few weeks banging your head against the wall, "just put up with them" starts looking surprisingly good. But maybe you still have some sprit...

- If you want to hide them, you can either (a) use an encoder which reencodes the original noise or (b) add fake noise on playback. Xvid is OK for the first with plenty of bitrate, but it's pretty much a DVD9 -> DVD5 thing. DeBand() is the least-bad approach I know to the second, but it has problems with jumping blocks and it messes with the colour.

There is no magic solution.

Somebody who knows more about this stuff than me said "what you really need is some proper dither". I don't know if that's something that could be done in ffdshow() one day.

[DarkZell666]

- There is no way to satisfactorily tackle MPEG2 blocking going into the encode,I'm having a hard time understanding this concept of "MPEG2 blocking is invincible", lol. Why ain't there any deblocking filter capable of getting rid of it ? I'm skeptical about this ... I know you've tried gazillion solutions, but I'm still convinced you did something wrong (sorry, I just can't believe the statement as you written it :p)

- After a few weeks banging your head against the wall, "just put up with them" starts looking surprisingly good.So true, considering I personally need to pause and zoom to witness such light blocking =)

Noobish supposition: wouldn't applying a non-conditional linear blend on each 16x16 marcoblock edge work ? *wishful thinking going on ... ^^*

[foxyshadis]

That would make the problem worse, not better. I don't know if you have a recent Photoshop, but there's a "Reduce Noise" filter with exactly that sort of naive deblocking for jpeg. Here's what you get:
http://foxyshadis.slightlydark.com/random/p.png
See if you can spot the 8x8 borders. The thinner the edge, the more is washed out.

Besides, it's not all DCT edge-blocking, some of it is banding/blocking exacerbated by DCT. You can't fix that with normal deblocking.

[DarkZell666]

Duh ok, I wouldn't have imagined it could be so visible (mind you it took me a couple of seconds to spot the problem, lol), but ... is it really more unpleasant than unprocessed blocking ? :p

[Morte66]

@DarkZell666:

I'm curious to hear what you think of this video segment:
http://rapidshare.com/files/8285403/xf104.mpg.html

Look at the shadows and smooth areas, e.g. the dark sky. Watch it fullscreen in a dark room. Try it with your player set flat. Then adjust the contrast/brightness to make the highlights go white and the border go black, not light grey and dark grey. [E.g. ZoomPlayer using VMR9 renderless with brightness -20 and contrast 1.2.]

It's from the low-quality end of my DVD collection, but it's by no means unique -- I've got dozens of DVDs like that. Tell me if you think it has problems that are worth tackling in the backup/playback chain.

[DarkZell666]

I'm not able to reproduce the viewing conditions right now, but from what I've seen (watching it in mplayer), I would say that the grain looks a bit oversharp, and that there's some aliasing.

About blocking ? During normal playback I can't spot any, but in some scenes, pausing will show that the noisy parts are blocked like hell (except that I don't usually pause a movie 15 times when I'm watching it :p)

Tweaking the brightness/contrast upwards (using my video card's overlay settings), I can see that the sky has blueish non-moving blocks (even during the camera pans), but setting everything flat and watching it normally doesn't reveal any of this at all.

I'm asking this honestly (no irony involved or anything for once ;)): what's the point you're trying to make ?
What do YOU see ? Either i've got ill eyes or you have logitech's G5 laser-sight XD


Edit: now i've watched the sample 10 times over and I know where the blocks are, I can indeed see them during playback, but that's sort of "cheating" ;)

[Morte66]

I'm asking this honestly (no irony involved or anything for once ;)): what's the point you're trying to make ?
What do YOU see ? Either i've got ill eyes or you have logitech's G5 laser-sight XD

Well, you said a few times that you didn't see any problem with things that bothered me. I wondered if the difference was because of our viewing conditions and display configuration. It looks like it was.

I normally watch video on a good monitor in a dark environment at high contrast. I prefer things this way, the picture takes on a 3D look and the content seems more cinematic. And I usually watch at a distance of about 1.25-1.5x the screen diagonal, because with typical mis-en-scene that usually gives a more convincing perspective (i.e. relative size of foreground and background objects for scaled viewing distance). I do it for reasons of art rather than technology.

All this is very revealing of flaws, both in DVDs and encodes from DVDs, so I do my best to control them. Hence I post a lot in threads like this. ;)

If I play things the way you do, with DVD luminosity in the default 20..235 instead of 0..255 (or near), then I don't see the blocks unless I search for them either. But the content isn't as interesting that way.

What I really need is for HD DVD to get going properly...

[*.mp4 guy]

You can get close to removing all the mpeg2 blocks from most dvd's with this script, but its slow as hell, although it leaves detail almost completely intact.

source = last

backward_vec2 = source.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
backward_vec1 = source.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
forward_vec1 = source.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
forward_vec2 = source.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
mask = mvmask(kind=1, vectors=forward_vec1).UtoY().spline36resize(source resolution)#its very important that this line matches the resolution you are feeding the script with
smooth = source.degrainmedian(mode=3).fft3dgpu(bw=16, bh=16, bt=3, sigma=4, plane=0)
source2 = maskedmerge(source, smooth, mask)

source3 = source2.MVDegrain2(backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400,idx=2)
source3.gradfun2db(1.5)

[Morte66]

You can get close to removing all the mpeg2 blocks from most dvd's with this script, but its slow as hell, although it leaves detail almost completely intact.

Thanks, I will have a go at that over the weekend.

[Chainmax]

lol I enjoyed that other thread. it's always fun to watch chainmax try to remove all the noise in a source.
...
And it's always fun to see you post baseless comments meant to rile people up. Unfortunately, most of the times you succeed.

[huang_ch]

Thanks, I will have a go at that over the weekend.

Me too. :)
After all, I'm a bit agree that most blocks are caused by those blocks already exists but not so easy to see in the source file, but using X264 really seem to reveal those blocks. :thanks:

[Audionut]

You can get close to removing all the mpeg2 blocks from most dvd's with this script, but its slow as hell, although it leaves detail almost completely intact.

Hi, I get an error, "invalid arguments to function mvmask".

Any ideas,
Thanks.

[Sharktooth]

Update masktools.

[Audionut]

mvmask is part of mvtools. I have the latest versions of both.

edit: If I remove the parameters of mvmask it still shows the same error.

[foxyshadis]

You have to have, at the minimum, a vector clip. kind is deprecated, and may have even been removed entirely from the latest version. Try with the vectors but without kind.

[Audionut]

No luck.

Also when I removed mvtools from the plugin dir and loaded it through the script it returned this error.

http://img95.imageshack.us/img95/5011/erroreu3.png

Here is the script.
#import("G:\ST9_INSURRECTION_D1_UK\VIDEO_TS\new folder\mvtools.dll")
source=mpeg2source("G:\ST9_INSURRECTION_D1_UK\VIDEO_TS\test.d2v")
#crop(8,78,-8,-78)
#bilinearresize(624,256)
#removegrain()
backward_vec2 = source.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
backward_vec1 = source.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
forward_vec1 = source.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
forward_vec2 = source.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
mask = mvmask(vectors="forward_vec1").UtoY().spline36resize(720,576)
smooth = source.degrainmedian(mode=3).fft3dgpu(bw=16, bh=16, bt=3, sigma=4, plane=0)
source2 = maskedmerge(source, smooth, mask)

source3 = source2.MVDegrain2(backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400,idx=1)
source3.gradfun2db(1.5)

[*.mp4 guy]

That script is compatible with the latest version of mvtools here (http://avisynth.org.ru/mvtools/mvtools.html) and kind is not deprecated, it is still usefull, if slightly broken (thats why there is the UToY.Resize at the end of it). the script works for me with version 1.6.2 of mvtools.

[edit]
audionut, update mvtools, then use mvmask exactly as it is in the script I posted.

[Audionut]

Removed source from in front of mpeg2source and add back

source = last

fixed it.
Thanks all.

[Morte66]

And so, after a thunderous 2.16fps encode (compared to 10.23 without the MPEG2 deblocker), the first results are in...
http://rapidshare.com/files/8517839/XF104enc.zip.html

I hasn't done anything to the really huge posterised clusters that take up a substantial chunk of the screen, but the small individual blocky bits that are mixed into the more functional areas of the picture are much improved.

It's too slow to go in the regular backup chain, but it looks well worth using on the problem DVDs. I will test some more.

Cool.

[*.mp4 guy]

Gradfun is the avisynth implementation of deband, and should have removed the pasterization from the blobs, could you check if it is working by looking at the uncompressed filtered source (If x264 just adds the banding back in your better off not using it and getting a bit more speed and detail).

[Morte66]

Gradfun is the avisynth implementation of deband, and should have removed the pasterization from the blobs, could you check if it is working by looking at the uncompressed filtered source (If x264 just adds the banding back in your better off not using it and getting a bit more speed and detail).

It's hard to say...

In the encode there are large smooth areas with quite sharp colour transitions at the edges, i.e. banding or posterisation or whatever you call it. They have sharp blocky edges with lots of right angles, and the edges move so they really grab the eye. I presume that DeBand and gradfun are meant to reduce the obviousness of the transition.

In the filtered source (avisynth -> zoomplayer) I also see the big smooth areas, but they have noise and "miniblocks" scattered over them. They don't especially draw attention to themselves, and on deliberate examination they don't feel like posterisation though upon reflection they obviously are. Once I encode, the noise goes and the posterised areas are revealed. If I stick a heavy denoiser like FrFun7() on the end of the source and watch it without encoding, it looks rather like the x264 encode.

I think gradfun is helping with the posterisation in the filtered source. The edges don't seem so sharp. It's hard to say for sure amongst the general crud, but I reckon so.

Anyhow, I ran the encode again without gradfun(). It ran at 2.25fps instead of 2.16, and it looks much worse. Block city. So gradfun() is a keeper on the end of that script. I might try turning it up...

[*.mp4 guy]

Well the Xfiles are so grainy and overcompressed its not very surprising that there is a lot of banding (in my experience banding is directly related to how compressed the dc coeficient is), I was a bit surprised though, as that scrip usually doesn't leave any banding behind. As long as the individual "levels" of the bands are close together gradfun should be able to remove them, but I'm curious about what it will do at higher settings.

[Morte66]

but I'm curious about what it will do at higher settings.

Nothing very different, it seems. I played around a bit, didn't really get anywhere. I guess there's only so much you can do when the posterised areas are a hundred pixels across...

[shon3i]

I have similar problem with Jay and Silent Bob Strike Back movie.

Here is original m2v file spited and demuxed from original DVD with dgindex

http://www.sendspace.com/file/u2kq7b

I have problems with these green walls, and other darker scenes, other scenes look very good.

avs i used during encoding

DGDecode_mpeg2source("JayAndSilentBobStrikeBack.d2v",info=3)
ColorMatrix(hints=true)

x264 settings

--pass 2 --bitrate 856 --stats ".stats" --ref 8 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -1,-1 --subme 6 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "JayAndSilentBobStrikeBack.mp4" "JayAndSilentBobStrikeBack.avs"

I've tryed CQM, and AQ but nothing much help, but aslo encode with lastest mainconcept 2.1 encoder and his give me little better and less blockly walls, and much faster encoding even better picture than i use CQM with x264

Can you suggest some filtreing with FFT3DGPU because speed is important to me.

EDIT: i forgot to say, target bitrate is 856kbps, it is important to be 1CD rip.

Thanks

[Morte66]

@shon31:

I experimented with your clip. It seems to me that...

- The source has lots of random flickery blocks under the noise. x264's inherent denoise effect reveals them.

- If you do a straight encode and use DeBand in ffdshow on playback, it doesn't really solve the problem. The movement/flickering of the blocks is too much for DeBand.

- If you insert m4g's anti-blocking script into the backup then encode, it mostly changes the random flickery blocks into organised global banding. [This is slow, and using fft3dgpu instead of fft3dfilter doesn't make much difference overall.]

- DeBand in ffdshow can cope with these organised bands a lot better than the flickery blocks. Provided you increase the strength above default, it hides the bands pretty well. They're not gone, but much improved.

- All this pre-processing and post-processing makes the picture softer. If you watch from a distance that's more than twice the screen diagonal, it's not a big loss.

Summary: if you don't mind a very slow encode, and requiring ffdshow to be installed, and a soft picture, you can substantailly reduce the blocking.

Any reasonable encoders settings will work if you process this way. The anti-blocking pre/post-process settings dominate the results, not the x264 config.