View Full Version : Deblock with High-bit-depth Support
MysteryX
30th May 2018, 04:16
To practice reading VapourSynth code, I thought back-porting a plugin to Avisynth would be the best way.
Here's an updated version of Deblock.
https://github.com/mysteryx93/Avisynth-Deblock/releases
v1.3
- Added high-bit-depth support
- Added Planes parameter to specify which planes to process
- Supports all planar formats
High-bit-depth is especially useful for this filter because it happens at the very beginning of the script, so the rounding errors get amplified throughout the rest of the script.
All credits go to those who wrote, stole and adapted the code.
Enjoy!
(anyone wants to update the Wiki page (http://avisynth.nl/index.php/DeBlock)?)
FranceBB
30th May 2018, 06:19
Hmm... I downloaded it and it works while I'm at 8bit, but I don't know how to tell the filter which bit depth I'm using 'cause it doesn't have a bit-depth parameter. Does it automatically detect it?
I tried deblocking at 16bit, but it seems that instead of being 16bit aware, it's just wrongly applying deblocking to the green part of the video, pretending it's 8bit.
FFMpegSource2("test.mov", fpsnum=25000, fpsden=1000, atrack=-1)
Dither_convert_8_to_16()
Deblock(quant=25, aOffset=0, bOffset=0, planes="yuv")
Please, don't tell me it only supports high bit depth in Avisynth+, 'cause that would be a pain in the butt.
p.s line 27 of init.cpp is LMAO
return "Blocks are kawaii uguu~!";
Just a few more questions:
1) In init.cpp, line 16 you set
input = env->Invoke("PointResize", AVSValue(sargs, 5), nargs).AsClip();
Why PointResize?
2) in Deblock.cpp line 273 - 300 the following code is supposed to check for 16bit, but the one used by Avisynth+, not the one used by Dither Tool nor the one used by HDRCore in Avisynth, right?
if (vi.BitsPerComponent() <= 16) {
_peak = (1 << vi.BitsPerComponent()) - 1;
_alpha = _alpha * _peak / 255;
_beta = _beta * _peak / 255;
_c0 = _c0 * _peak / 255;
_c1 = 1 * _peak / 255;
}
else {
_alphaF = _alpha / 255.f;
_betaF = _beta / 255.f;
_c0F = _c0 / 255.f;
_c1F = 1.f / 255.f;
}
}
PVideoFrame Deblock::GetFrame(int n, IScriptEnvironment *env) {
PVideoFrame src = child->GetFrame(n, env);
env->MakeWritable(&src);
if (vi.BitsPerComponent() <= 8)
Process<uint8_t>(src, env);
else if (vi.BitsPerComponent() <= 16)
Process<uint16_t>(src, env);
else
Process<float>(src, env);
return src;
}
DJATOM
30th May 2018, 08:48
It's 8-bit only with classic avisynth, since plugin writer needs to implement 2 extra steps:
- read 16-bit video from stacked format;
- split-back to stacked again.
StainlessS
30th May 2018, 09:51
I dont as yet use any high bit depth stuff at all, but think that maybe Stacked format High Bit should be left to die in peace, best not to expect new plugs to support a 'lemon'. [EDIT: t'was a horrible kludge]
FranncBB, whats wrong with Avs+ ?, its great.
FranceBB
30th May 2018, 13:43
I guess I'll give it a shot. Last time I tried Avisynth+, I moved all the Avisynth plugins to Avisynth+ and nothing worked.
I'll try one more time.
StainlessS
30th May 2018, 14:23
1st Time I tried Avs+, I found about 5 bugs in 20 mins, nowadays, is so much better, tis total lovelyness +.
MysteryX
30th May 2018, 15:35
Please, don't tell me it only supports high bit depth in Avisynth+, 'cause that would be a pain in the butt.
It only works with AVS+ formats. Better leave the ugly Stack16 hack die in peace. I haven't added any extra format support beyond converting VapourSynth code.
p.s line 27 of init.cpp is LMAO
return "Blocks are kawaii uguu~!";
Ya had to leave that! It was probably in there since the very first version and nobody dared touch it.
1) In init.cpp, line 16 you set
input = env->Invoke("PointResize", AVSValue(sargs, 5), nargs).AsClip();
Why PointResize?
If it's not Mod8, it will add padding instead of throwing an error.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.