How do I use DeBlock with or without McTemporalDenoise?

[VideoFanatic]

From what I understand, DeBlock is the best deblocker so I need help with using it. I don't really understand this part of the McTemporalDenoise documentation:

deblock bool = false
Enable deblocking before the denoising
useQED bool = based on mode
If true, use Deblock_QED, else use Deblock (faster & stronger)
quant1 int = based on mode
Deblock_QED "quant1" parameter (Deblock "quant" parameter is "(quant1 quant2)/2")
quant2 int = based on mode
Deblock_QED "quant2" parameter (Deblock "quant" parameter is "(quant1 quant2)/2")

So this is my script:

McTemporalDenoise(settings="medium", interlaced=true, useQED=false, deblock=true)

The McTemporalDenoise quant parameters don't really explain anything. How do I put in my script that I want full strength deblocking? Also what do I do for the parameters mentioned below?

Also if there's nothing that needs deblocking then deblock will do nothing, is that correct?

Here's the DeBlock documentation:

• quant : the higher the quant, the stronger the deblocking. It can range from 0 to 60.
• aOffset : quant modifier to the blocking detector threshold. Setting it higher means than more edges will deblocked.
• bOffset : another quant modifier, for block detecting and for deblocking's strength. There again, the higher, the stronger.

Defaults are quant = 25, aOffset = bOffset = 0. If quant + aOffset is inferior to 16, the filter does nothing at all. The same goes for quant + bOffset.
Examples

To deblock the motion compensation (MVTools plugin):
vectors = source.MVAnalyse(isb = false, lambda = 1000) compensation = source.MVCompensate(vectors, mode = 0) compensation.Deblock()

I would also like to know how I can use the Deblock plugin on it's own when not using McTemporalDenoise.

Also I seem some people do this for McTemporalDenoise: deblock=true, useQED=true
What's the point in that as I thought you can only use one or the other?

[jagabo]

Deblock()
Deblock_QED()

For usage see the documentation for those particular filters.

http://avisynth.org/mediawiki/DeBlock
http://avisynth.org/mediawiki/Deblock_QED

For more details on Deblock_QED() look in the Deblock_QED.AVS file.

In MCTD() deblock=true/false determines whether deblocking will be performed at all, useQED=true/false deterimines whether Deblock() or Deblock_QED() will be used when deblocking is enabled.

[sanlyn]

The default value of "deblock" for all settings modes in MCTD is "false" -- meaning that deblocking before denoising is off by default. The default value of "useQED" varies according to the "settings" mode. For Very Low, Low, and Medium, useQED is "true"; for High and Very High, useQED is "false". In your sample script you are running MCTD at "Medium". In that mode, "deblock" is false by default, so making it true will run deblocking before the main denoise routines. With deblocking enabled, then setting useQED to false will run plain old deBlock instead of running QED. In this case, the word "eblock" refers to whether deblocking is turned on or off; it doesn't refer to the DeBlock plugin.

The McTemporalDenoise quant parameters don't really explain anything. How do I put in my script that I want full strength deblocking? Also what do I do for the parameters mentioned below?

They explain that the values for quant1 and quant2 vary according to the MCTD settings mode. The settings for each mode are in the avsi script. Here is an edited version from the script:

### +-------------+-----------------------------+-----------------------------+-----------------------------+-----------------------------+-----------------------------+
### | SETTINGS    |      VERY LOW               |      LOW                    |      MEDIUM                 |      HIGH                   |      VERY HIGH              |
### |-------------+-----------------------------+-----------------------------+-----------------------------+-----------------------------+-----------------------------|
### |-------------+-----------------------------+-----------------------------+-----------------------------+-----------------------------+-----------------------------|
### | deblock     |      false                  |      false                  |      false                  |      false                  |      false                  |
### | useQED      |      true                   |      true                   |      true                   |      false                  |      false                  |
### | quant1      |      10                     |      20                     |      30                     |      30                     |      40                     |
### | quant2      |      20                     |      40                     |      60                     |      60                     |      80                     |
### |-------------+-----------------------------+-----------------------------+-----------------------------+-----------------------------+-----------------------------|

From the above table you can see that if you run MCTD at "medium", quant1=30 aand quant2=60. Add quant1 and quant2 together, you get 90 (30+60=90). Divide that by 2, and 45 becomes the value for deBlock's "quant" if you run deBlock instead of running deBlock_QED. 45 is about 2/3 of the way up for deBlock's quant value, which can't be higher than 60. Keep that number 60 in mind, and look at the settings for quant1 and quant2 at "Very High" mode. In that mode, quant1=40 and quant2=80. 40+80=120. Divide 120 by 2, and you get deBlock's max quant setting of 60.

The MCTD avsi script is mighty long; the top half of it or so is commentary. Be careful when browsing the avsi. If you inadvertently make any change, you're in trouble. For browsing the avsi I made a copy of it and renamed it "MCTD.txt".

To use DeBlock by itself without running MCTD, use deBlock like any other plugin. The statement to execute deBlock at its default values is:

DeBlock()

When run as a standalone filter, the default "quant" value for deBlock is 25. This value can be set to a minimum of 0 (in which case, why even run it?) or a max of 60. The statement "aOffset = bOffset = 0" means that aOffset and bOffset are both set to 0 by default.

DeBlock documentation states that if the sum of aOffset plus quant is less than 16, deblock does nothing. The same would be true if bOffset + quant is less than 16. The default for quant is 25 -- so if the offsets are 0 by default, 0+25 is still greater than 16.

You can make deBlock work more strongly be upping quant to higher values. That's an overall setting, but if you leave aOffset set to 0 then the edge-seeking algorithms tend to treat more objects as a "block edge". Higher settings of aOffset mean stronger block edge seeking, and higher settings of bOffset mean stronger block smoothing. The only way to get a handle on how those 3 settings affect an image is to fiddle with them and see what happens. A few blocky videos will soon give an idea of how those settings operate.

deBlock_QED's quant1 and quant2 parameters are roughly (repeat, roughly) doing the same thing as deBlock's aOffset and bOffset.

Also I seem some people do this for McTemporalDenoise: deblock=true, useQED=true
What's the point in that as I thought you can only use one or the other?

Look at the modes chart for default values for deblock and useQED for different settings modes. Users might prefer the QED version for speed. The word "deblock" in the context of mode settings does not refer to the DeBlock() plugin. It refers to whether or not the user wants pre-deblocking before denoising. Enabling it takes longer.

The reference to using DeBlock() with mvTools is for use with the mvTools plugin. In early versions of mvTools, DeBlock(0 was an included function. The reference shows how use deBlock the way it was used 'way-back-then in mvTools.

[VideoFanatic]

Thanks that helps a lot. Also just wondering what the default for adapt is? In the table all it says is this:

sharp==2?true:false

So does that mean that adapt is true or false by default? What would you recommend I put it on and does it actually give a bitrate saving like it says?

[sanlyn]

You are reading the statement sharp==2?true:false from the wiki HTML for MCTD. The script has changed since that wiki was published and no longer occurs in the script. Just scratch that HMTL and stick with the current avsi.

Certain kinds of sharpening and oversharpening will sharpen noise, which costs bitrate when encoding. The bitrate savings don't apply until you encode.

[VideoFanatic]

I see what you mean, I just looked at the avsi and it differs from that html page.

Certain kinds of sharpening and oversharpening will sharpen noise, which costs bitrate when encoding. The bitrate savings don't apply until you encode.

I'm not sure what you meant by that! Of course you would have to encode the file before you get a bitrate saving!?

What am I doing wrong here? I'm trying to use DeBlock instead of CPU=6 but it seems to quite obviously not be as good as CPU=6. I'm using it at the strongest setting and I can still see obvious blocking:

McTemporalDenoise(settings="medium", interlaced=true, deblock=true, useQED=false, quant1=40, quant2=80)

Is that script correct?

[sanlyn]

I gave up using deblockers with MCTD. Maybe I'm doing it wrong, myself, but deblockers seem to be more effective when run after MCTD or run without it. It also could be that block noise is not what you're seeing -- maybe it's banding, low-bitrate or high-compression problems, or some other artifact. Both DeBlockers work OK when I use them alone.

[VideoFanatic]

OK so I'll try DeBlock on its own and not in McTemporalDenoise. Do you know what the maximum values for aOffset and bOffset are? I'll try this once I know what the max values are:

DeBlock (quant=60, aOffset= , bOffset=)

[jagabo]

Did you crop or resize the frame before deblocking? Blocks must remain on 8 pixel boundaries for proper deblocking.

[VideoFanatic]

It was 720 x 480 then I did this

Crop(22,0,-6,-12)
AddBorders(14,6,14,6, $000000)

[sanlyn]

OK so I'll try DeBlock on its own and not in McTemporalDenoise. Do you know what the maximum values for aOffset and bOffset are? I'll try this once I know what the max values are:

DeBlock (quant=60, aOffset= , bOffset=)

DeBlock_QED is an offshoot of DeBlock(), and QED scripts show values for aOffset and bOffset between 2 and 8. You can try those with DeBlock(). I've usually gone for the QED version: more parameters and probably better documentation. I'd try either of them before running MCTD. If you get no results, try it after MCTD with MCTD's own pre-deblock turned off. But seeing no effect at all is unusual. As I said, maybe it's not macroblocks. If it's really motion blur or other artifacts, deblockers won't help.

One of the DivX sites shows these examples of macroblocking:

[jagabo]

It was 720 x 480 then I did this

Crop(22,0,-6,-12)
AddBorders(14,6,14,6, $000000)

There's your problem. The width is OK. You removed 22 pixels from the left edge then added 14. The net effect is shifting the image 8 pixels left. But the height is a problem. You shifted the image down by 6 pixels, leaving the blocks misaligned.

Shift the image down by 8 pixels instead. That will also give you better compression.

Crop(22,0,-6,-12)
AddBorders(14,8,14,4, $000000)

[VideoFanatic]

So you're saying that DeBlock in McTemporalDenoise isn't working well because I cropped incorrectly? I don't really understand that alignment issue, I thought as long as you crop and add borders in even numbers then you're OK? Why would having top and bottom borders on 8 and 4 give better compression than 6 and 6?

What documentation mentions that alignment problem? I don't understand then why CPU=6 works fine with the same crop.

The video I was trying to use DeBlock on and crop was the same one in this thread.

[poisondeathray]

I don't understand then why CPU=6 works fine with the same crop.

CPU=x is applied before you crop, in the source filter mpeg2source()

[sanlyn]

So, jagabo, this cropping/AddBorders issue in YV12 has complications I hadn't considered. I'm familiar with the rules of 2's of 4's, etc., but this throws a new light on matters. Couldn't one convert to, say, YUY2 for better results, then back to YV12? I realize the risk of some losses there, but such conversions are done all the time.

[manono]

Deblocking is always best done before cropping/resizing. It's usually the first thing in the script after opening the video (unless you have to bob an interlaced source before deblocking).

[VideoFanatic]

I used DeBlock fuction of McTemporalDenoise and I had the crop and borders after McTemporalDenoise.

[jagabo]

I don't understand then why CPU=6 works fine with the same crop.

Mpeg2Source(...CPU=6) deblocks before the video is given to AviSynth.

[jagabo]

So, jagabo, this cropping/AddBorders issue in YV12 has complications I hadn't considered. I'm familiar with the rules of 2's of 4's, etc., but this throws a new light on matters. Couldn't one convert to, say, YUY2 for better results, then back to YV12?

Deblocking works on 8x8 blocks of pixels, starting at the top left corner. If the blocks aren't aligned properly the deblocking algorithm will not detect the edges of the blocks correctly. It doesn't matter what the colorspace is (as long as the deblocking filter works in that colorspace).

[jagabo]

I used DeBlock fuction of McTemporalDenoise and I had the crop and borders after McTemporalDenoise.

On progressive frames? That should have been ok then. Neither DeBlock() nor DeBlock_QED() explicitly supports interlaced frames. I don't know what MCTD() does before calling them.

Try this:

Mpeg2Source("Raw 2001 Dec 10 stutter & brightness changing.d2v", info=3)
Interleave(Deblock(60).Bob(), Bob.Deblock(60))

You'll see that Deblock() works much better if you deinterlace first.

[VideoFanatic]

Jagabo do you want to test it yourself here to see if McTemporalDenoise is actually deblocking properly or not? This is my script and I think I've set deblocking to full strength. I encoded the video as h264.

Mpeg2Source("L:\Raw 2001 Dec 10 stutter & brightness changing.d2v")

RemoveSpots()
AddGrainC(var=1.0,uvar=1.0)

McTemporalDenoise(settings="medium", interlaced=true, deblock=true, useQED=false, quant1=40, quant2=80)

ColorYUV(autogain=true)

Tweak(Bright=0, Sat=1.0, Cont=1.0, Hue=0.0, Coring=False)

Crop(22,0,-6,-12)
AddBorders(14,6,14,6, $000000)

If there's a problem then is the only way to fix it by changing the crop? What values are allowed? I know you said that Deblocking works on 8x8 blocks of pixels but that doesn't really mean anything to me.

[jagabo]

Cropping after deblocking will make no difference to the deblocking. You should understand that by now. AviSynth is a pipeline. Frames come in at the top of the script and get passed through to filters lower in the script. Filters earlier in the have no idea what filter later in the script are doing.

Deblocking is working in McTemporalDenoise(). But since it's getting interlaced frames it's not working as well as it could.

[VideoFanatic]

OK so if I put McTemporalDenoise at the bottom will that work?

[jagabo]

No. You're not deinteralcing anywhere so MCTD() will still be getting interlaced frames. And your Crop() will cause block misalignment as we discussed earlier.

[VideoFanatic]

So I need to deinterlace just so I can get the DeBlock part of McTemporalDenoise to work? Will the crop then work or is it still misaligned?

Do I do this:

AssumeTFF().SeparateFields()
McTemporalDenoise(settings="medium", deblock=true, useQED=false, quant1=40, quant2=80)
Weave()


And then my crop?

[jagabo]

That won't work because SeparateFields() will leave you with 8x4 blocks, not 8x8 blocks.

[VideoFanatic]

If you have the solution then please tell me because I don't know.

[jagabo]

I'm trying to get you to think for yourself. You'll learn much more that way.

[poisondeathray]

Adding grain then using MCTD right after doesn't make sense to me

If you want to use deblock_qed for interlaced video separately

par=getparity()
SeparateFields().PointResize(width,height)
Deblock_QED()
AssumeFrameBased()
SeparateFields()
Merge(SelectEven(),SelectOdd())
par ? AssumeTFF() : AssumeBFF()
Weave()

Adjust the deblock_qed parameters to your tastes
http://forum.doom9.org/showthread.php?p=934083#post934083

[sanlyn]

I will have to get back to this. It seems to be going in the wrong direction. Or maybe I'm not following it correctly.

One problem for me is the way autogain sees those big thick black borders and compensates by blowing the hell out of brights, moving gamma about 30 RGB points toward the bright end, and giving a badly washed-out video. Then comes Tweak(), which makes no correction at all. This is preceded by running RemoveSpots on interlaced video. Of course RemoveSpots can be run that way, and has been, and I've done it a couple times myself. But I had specific reasons for doing it. I don't see the reason for doing it that way here.

The final cropping statement is a puzzle. I count a left and right border that add up to 18 pixels. That's 14 pixels on the left, 4 on the right. Tonight I learn that any crop value not divisible by 8 is a no-no. So to clear away the 18 border pixels (for whatever purpose one might have), the only way to do it is to remove 16 pixels from the left and 8 pixels from the right (a total of 24 rather than 14). Then there are 8 pixels of noise at the bottom. 8 is a cool number, so it's OK. The allowed Crop statement would then be "Crop(16,0,-8,-8)". Trying to even-out the borders and center the image is not allowed -- one would have to add 12 black pixels to the left and right (12 is not allowed) and 4 pixels top and bottom to center the image (4 is not allowed). In fact it is not allowed to center the image at all, because this would irreparably displace pixels from their original positions. So the only allowed way to restore the borders without displacing pixels is to write "AddBorders(16,0,8,8). This gives an uncentered image with lopsided borders looking a little worse than before, border-wise. Sort of drains some of the fun out of fixing this stuff.

I am now wondering how MCTemporalDenoise is supposed to resolve a number of the video's worst problems, one of the lesser of which is pixel blocks. Maybe I'm just getting tired. This will probably look different in the morning.

Anyway, I got a ton of useful tips from jagabo's field handling.