Closed marukuru closed 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?
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()
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.
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.
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?
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"
.
Ok, I will have a look tomorrow. Meanwhile try to play with the Prefetch() values, lowering them, etc.
I did several tests with different prefetch() values, also removed it altogether, but it didn't solve the problem.
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
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?
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.
((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.
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).
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+?
Follow up: The problem has its origin in the use of setlocale
by KNLMeansCL. Removing the calls and recompiling, and all errors are gone.
I should seriously take the time to rewrite all the code in proper cpp17
QTGMCp(Preset="Slow", EdiMode="NNEDI3", Threads=20, Denoiser="KNLMeansCL", NoisePreset="Slow", EZDenoise=1.0, ChromaMotion=true, gpuid=0)
results inafter fixing the obvious bug in QTGMC+.avsi, line 936 by changing
gpuid=id
togpuid=gpuid
.Latest AVS+ from master and qyot27's latest KNLMeansCL fix.