Dogway / Avisynth-Scripts

AviSynth+ 3.7.3+ Filters
GNU General Public License v3.0
91 stars 13 forks source link

QTGMC+: Denoiser=KNLMeansCL not working #71

Closed marukuru closed 1 year ago

marukuru commented 1 year ago

QTGMCp(Preset="Slow", EdiMode="NNEDI3", Threads=20, Denoiser="KNLMeansCL", NoisePreset="Slow", EZDenoise=1.0, ChromaMotion=true, gpuid=0) results in

((null), line 1, column 4)
(ExTools.avsi, line 7385)
(ExTools.avsi, line 1937)
(SMDegrain.avsi, line 1270)
(SMDegrain.avsi, line 1273)
(QTGMC+.avsi, line 937)

after fixing the obvious bug in QTGMC+.avsi, line 936 by changing gpuid=id to gpuid=gpuid.

Latest AVS+ from master and qyot27's latest KNLMeansCL fix.

Dogway commented 1 year ago

Works for me after fixing the typo. What revision of AVS+ v3.7.3 are you at?

Check ExTools, QTGMC+ and KNLMeansCL (v0.7.5 in requirements is a typo) are updated also, and if still doesn't work post your script and if possible a clip.

I haven't tested latest (Jan 2023) qyot27's KNLMeansCL so not sure if compatible, are there artifact builds somewhere?

marukuru commented 1 year ago

Thanks for the quick response, @Dogway. ExTools, QTGMC+ etc are all latest from master. AVS+ is AviSynth+ 3.7.2 (r3862, master, x86_64). Don't be fooled by the 3.7.2, it's compiled from master, which still officially is 3.7.2:

#define       AVS_PROJECT       AviSynth+
#define       AVS_MAJOR_VER     3
#define       AVS_MINOR_VER     7
#define       AVS_BUGFIX_VER    2

I did some more testing, but without further success.

LWLibavVideoSource("sample.mkv", format="YUV422P10")
AssumeFPS("ntsc_video")
AssumeBFF()
ConvertBits(8, dither=1)
QTGMCp(Preset="Slow", EdiMode="NNEDI3", Threads=20, Denoiser="KNLMeansCL", NoisePreset="Slow", EZDenoise=1.0, ChromaMotion=true, gpuid=0)
ConvertToYUV420()

sample.zip

Dogway commented 1 year ago

Works for me with your clip and script in AvspMod, even using LWLibavVideoSource.

So your problem is only when using KNLMeanCL in QTGMC+ right? I guess it would give you issues also if called alone. Make sure you have pinterf's KNLMeanCL v1.1.1e and Asd-g's vsTCanny v1.1.8, and check their requirements, as a debug test first.

Other than that it might be an issue with too recent AVS+, I don't know what has changed since r3835, so can't make the required modifications.

If your build version is still reporting 3.7.2, you might need to custom edit all instances of IsVersionOrGreater(3,7,3) in my scripts.

marukuru commented 1 year ago

Thanks for further investigating. I did revert AVS+ to r3835 without success. I also compared pinterf's KNLMeanCL v1.1.1e to Khanattila's version + qyot27's fixes, they are basically identical, as Khanattila merged pinterf's changes a while back. (I also went ahead to apply qyot27's fixes to pinterf's source manually). vsTCanny is compiled from master, which is 1.1.8.

Oddly enough KNLMeansCL alone works flawlessly. That's why I also tried replacing the ex_KNLMeansCL() call with a direct KNLMeansCL() call (while adapting the parameters), but that lead me down a whole nother rabbit hole:

Expr: Failed to convert '1,200000' to float, not the whole token could be converted
(ExTools.avsi, line 171)
(QTGMC+.avsi, line 1051)

At this point I'm all out of ideas.

Dogway commented 1 year ago

Since you are building the plugins, I would also check if it works with the public builds, to rule out any building conflicts. So ex_KNLMeansCL() alone doesn't work for you either? What's the error message?

marukuru commented 1 year ago

Same error as in my initial post (ex_KNLMeansCL(gpuid=0)):

((null), line 1, column 4)
(ExTools.avsi, line 7385)
(ExTools.avsi, line 1937)
(SMDegrain.avsi, line 1253)
(SMDegrain.avsi, line 1273)

Using KNLMeansCL(a=2, s=4, d=1, h=1.0, device_id=0) without QTGMC+ works fine, so does Denoiser="fft3df".

Dogway commented 1 year ago

Ok, I will have a look tomorrow. Meanwhile try to play with the Prefetch() values, lowering them, etc.

marukuru commented 1 year ago

I did several tests with different prefetch() values, also removed it altogether, but it didn't solve the problem.

Dogway commented 1 year ago

I few things before testing again, you are on > Windows7 ? Also what graphic card do you have? In case it's an OpenCL issue. Testing on AvspMod?

Could you test removing device_type=device_type from the KNLMeansCL calls in the function?

I updated to r3877 and no issues here either

marukuru commented 1 year ago

Actually I'm on Linux (Ubuntu 22.04 LTS, Kernel 6.1.4, i9-10850K, 32GB RAM). I'm using the integrated UHD Graphics 630 with the latest OpenCL runtime directly from Intel.

I'm testing with a vanilla x264 compile (latest from master). I tried every possible value for device_type and also removing it altogether. Apart from a KNLMeansCL: no compatible opencl platforms available! on CPU or accelerator the problem stays the same. I also tried replacing the Eval+KNLMeansCL call with a plain KNLMeansCL() and KNLMeansCL(device_type="gpu", device_id=0) call, because both work perfectly without the QTGMC+ and ExTools/SMDGrain wrapper.

Funny enough: when I bypass the KNLMeansCL call ExTools still crashes at the exact same function call (ex_bs()), even with ColorBars():

((null), line 1, column 4)
(ExTools.avsi, line 7385)
(QTGMC+.avsi, line 747)

Shortest example to get it crashing on my machine is:

Input   = Colorbars(pixel_type="yv12")
Input   = Input.KNLMeansCL()
rgb     = Input.isrgb()
fs      = propNumElements(Input, "_ColorRange") > 0 ? propGetInt(Input, "_ColorRange") == 0 : rgb
tv      = !fs
bi      = Input.BitsPerComponent()
temp    = ex_bs(false ? 128 : 128.5, 8, bi, fulls=!tv, flt=true)
Input

Remove the KNLMeansCL() call and everything works fine. So it seems that KNLMeansCL somehow manages to interfere with ex_bs. Maybe the output is non-standard. Maybe @qyot27, @pinterf or @Khanattila have any idea?

qyot27 commented 1 year ago

What I would do in this situation is recompile AviSynth+, KNLMeansCL, and whatever host program the script is being fed to (FFmpeg? avsyuv?) as debug builds and see if the behavior can still be replicated. If so, then use gdb to get a backtrace and see exactly where the failure occurs.

The fixes I submitted in that pull request for KNLMeansCL don't touch the core execution stuff at all, it's just getting the plugin init exposed properly on non-Windows, and [a somewhat hacky] way of getting around KNLMeansCL assuming the use of avsplus' v8 headers instead of the current v9 (or pre-v10, given some of the most recent commits). The meson-related commits make it possible to use the system install of the headers rather than the v8 headers KNLMeansCL ships with, and does some modularizing of how the AviSynth+ and VapourSynth plugins are detected, built, and ultimately installed.

Dogway commented 1 year ago
((null), line 1, column 4)
(ExTools.avsi, line 7385)
(QTGMC+.avsi, line 747)

Line 7385, so ex_dlut() ? That's Eval(ex_dlut("range_size", 8, false)), surely the issue is strange as there should be nothing interfering with KNLMeansCL, as both separately work on your end.

marukuru commented 1 year ago

Thanks for the input, @qyot27 & @Dogway. I'll try to get debug builds up and running and do more testing. The issue sure is strange…

Meanwhile I found, that hardcoding ex_dlut("range_size", 8, false) without the Eval() results in

Invalid arguments to function 'min'.
(/home/user/.avisynth/ExTools.avsi, line 7385)

with ex_dlut returning 256,000000. Replacing said value with a hard-coded 256. and everything works as expected . Seems like there's some implicit casting or formatting when using string() screwing with the output of ex_dlut(). I tried reformatting the output with string(range_size[fs], "%#0.0f")), but it seems that on my system , is used as the floating point delimiter instead of .… So this might actually be an issue with AVS+ using locales for format conversions (issue).

marukuru commented 1 year ago

For future reference: quick workaround is to set a correct locale when launching a program, eg LC_NUMERIC="en_US.UTF-8" x264 -o … or LC_NUMERIC="en_US.UTF-8" ffplay -i. Thanks to @pinterf for pointing me in the right direction. The problem is not actually related or in any kind exclusive to @Dogway's scripts. Thank you to everybody participating in trouble shooting. @Dogway: Maybe you can include a trouble shooting/pit fall section in the README.MD until the issue is fixed with AVS+?

marukuru commented 1 year ago

Follow up: The problem has its origin in the use of setlocale by KNLMeansCL. Removing the calls and recompiling, and all errors are gone.

Khanattila commented 1 year ago

I should seriously take the time to rewrite all the code in proper cpp17