QTGMC Deinterlacing Script (v3.384)

[ErazorTT]

Originally Posted by LigH

That was the point of "if you didn't set lsbd=true then it will work with internal dither". Negation.

Thats also not the case. If lsbd is set to false, than no dithering is being done!

[real.finder]

Originally Posted by ErazorTT

Thats also not the case. If lsbd is set to false, than no dithering is being done!

maybe in the future I will see what I can do here, anyway, -Vit- didn't make this (lsbd) or even the internal dither of dfttest, so I will make the change not Default if I do it

[PirateIce]

er what ErazorTT? if lsbd=false than it gets passed as dfttest(lsb=false) and makes dfttest dither to 8 bit internally. whereas dither= should be the number of the dither IF dithering is used internally. am i way off on this?

[ErazorTT]

Originally Posted by PirateIce

er what ErazorTT? if lsbd=false than it gets passed as dfttest(lsb=false) and makes dfttest dither to 8 bit internally. whereas dither= should be the number of the dither IF dithering is used internally. am i way off on this?

I tested that, and no, thats no the case. If lsbd=false than no dithering is done. This can be very clearly seen looking at the chroma planes only with UToY8() or VToY8(). There is a very clear banding going on if lsbd=false. To resolve that dither must be 1. And my point is, that this is much faster than using ditherpost.

[PirateIce]

Ah I see I didnt realize dfttest was defaulting to no dithering, dither=0, even when lsb=false.

[odyssey]

Originally Posted by Groucho2004

A few pointers/comments:

1. You may be using old/outdated plugins. In order for us to suggest new versions you should use AVSMeter to create a "snapshot" of your Avisynth install and associated plugins. Run "AVSMeter -avsinfo -log" from the command line and post the generated log file ("avsinfo.log").
2. "SetMemoryMax(700)" may be a bit low for 5 base threads.
3. Consider using Avisynth+ instead of SEt's MT. At this stage it's quite stable and tests have shown good results multi-threading QTGMC().

Lastly, how are you feeding the script to x264?

Here you go:

AVSMeter 2.4.6 (x86) - Copyright (c) 2012-2016, Groucho2004

VersionString: AviSynth+ 0.1 (r2347, MT, i386)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\SysWOW64\AviSynth.dll
Avisynth.dll time stamp: 2016-12-22, 11:03:25 (UTC)
PluginDir+ (HKCU, x86): C:\Program Files (x86)\AviSynth\plugins
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+


[C 2.5 plugins]
C:\Program Files (x86)\AviSynth\plugins\yadif.dll [1.7.0.0]

[CPP 2.5 plugins]
C:\Program Files (x86)\AviSynth\plugins\AddGrainC.dll [1.5.2.0]
C:\Program Files (x86)\AviSynth\plugins\DctFilter_test.dll [0.0.1.5]
C:\Program Files (x86)\AviSynth\plugins\Decomb.dll [n/a]
C:\Program Files (x86)\AviSynth\plugins\dfttest.dll [1.8.0.0]
C:\Program Files (x86)\AviSynth\plugins\DGMVCDecode.dll [1.0.0.24]
C:\Program Files (x86)\AviSynth\plugins\EEDI2.dll [0.9.2.0]
C:\Program Files (x86)\AviSynth\plugins\eedi3.dll [0.9.1.0]
C:\Program Files (x86)\AviSynth\plugins\FFT3DFilter.dll [2.1.1.0]
C:\Program Files (x86)\AviSynth\plugins\FRIMSource.dll [n/a]
C:\Program Files (x86)\AviSynth\plugins\loadhelper.dll [n/a]
C:\Program Files (x86)\AviSynth\plugins\mt_masktools-26.dll [2.0.48.0]
C:\Program Files (x86)\AviSynth\plugins\mvtools2.dll [2.5.11.2]
C:\Program Files (x86)\AviSynth\plugins\nnedi.dll [1.3.0.0]
C:\Program Files (x86)\AviSynth\plugins\nnedi2.dll [1.6.0.0]
C:\Program Files (x86)\AviSynth\plugins\nnedi3.dll [0.9.4.0]
C:\Program Files (x86)\AviSynth\plugins\RemoveGrainSSE2.dll [n/a]
C:\Program Files (x86)\AviSynth\plugins\RepairSSE2.dll [n/a]
C:\Program Files (x86)\AviSynth\plugins\SSE2Tools.dll [n/a]
C:\Program Files (x86)\AviSynth\plugins\SupTitle.dll [2.0.8.0]
C:\Program Files (x86)\AviSynth\plugins\TDeint.dll [1.1.0.0]
C:\Program Files (x86)\AviSynth\plugins\VerticalCleanerSSE2.dll [n/a]
C:\Program Files (x86)\AviSynth\plugins\VSFilter.dll [1.0.1.3]

[CPP 2.6 plugins]
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll [n/a]


[Plugin errors/warnings]
----------------------------------------------------------------------------------------------------------------------

Error loading "C:\Program Files (x86)\AviSynth\plugins\DirectShowSource.dll"
Cannot load 64 bit DLL with 32 bit Avisynth

----------------------------------------------------------------------------------------------------------------------

"C:\Program Files (x86)\AviSynth\plugins\HookSurcode.dll"
Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Users\Microsoft Sucks\Downloads\AVSMeter246\AVSMeter246\AVSMeter.exe
Address: 0x003B44E1

----------------------------------------------------------------------------------------------------------------------

Error loading "C:\Program Files (x86)\AviSynth\plugins\ImageSeq.dll"
Cannot load 64 bit DLL with 32 bit Avisynth

----------------------------------------------------------------------------------------------------------------------

Error loading "C:\Program Files (x86)\AviSynth\plugins\Shibatch.dll"
Cannot load 64 bit DLL with 32 bit Avisynth

----------------------------------------------------------------------------------------------------------------------

"C:\Program Files (x86)\AviSynth\plugins\SupCore.dll"
Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Users\Microsoft Sucks\Downloads\AVSMeter246\AVSMeter246\AVSMeter.exe
Address: 0x003B44E1

----------------------------------------------------------------------------------------------------------------------

Error loading "C:\Program Files (x86)\AviSynth\plugins\TimeStretch.dll"
Cannot load 64 bit DLL with 32 bit Avisynth

----------------------------------------------------------------------------------------------------------------------

Error loading "C:\Program Files (x86)\AviSynth\plugins\VDubFilter.dll"
Cannot load 64 bit DLL with 32 bit Avisynth

----------------------------------------------------------------------------------------------------------------------

"C:\Program Files (x86)\AviSynth\plugins\dfttest.dll"

Dependencies that could not be loaded:
libfftw3f-3.dll

Note: "libfftw3f-3.dll can be downloaded here:
http://www.fftw.org/install/windows.html

libfftw3f-3.dll must be placed in a directory to which the
'PATH' environment variable points, i.e. System32/SysWOW64"

----------------------------------------------------------------------------------------------------------------------

Cannot load file 'C:/Program Files (x86)/AviSynth/plugins/eedi3.dll'. Platform returned code 14001:
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

Dependencies that could not be loaded:
vcomp.dll

----------------------------------------------------------------------------------------------------------------------

Cannot load file 'C:/Program Files (x86)/AviSynth/plugins/SSE2Tools.dll'. Platform returned code 126:
The specified module could not be found.

Dependencies that could not be loaded:
MSVCR71.dll

----------------------------------------------------------------------------------------------------------------------

As you can see I've upgraded to Avisynth+. Haven't had a single crash since then, so thanks for that suggestion

A few odd things that I need to fix in that log. One thing is that I had to replace avisynth.dll in both system32 and syswow64 with 32-bit MT-dll to make it load at all.

Next question: What are the current recommended filter versions for use with QTGMC, if the plugin pack is outdated?

[LigH]

Originally Posted by odyssey

One thing is that I had to replace avisynth.dll in both system32 and syswow64 with 32-bit MT-dll to make it load at all.

Definitely a wrong move. These are separate directories for a good reason: One (system32) should contain only 64-bit DLLs, the other (SysWoW64) only 32-bit DLLs.

Please do not try to access system directories using a 32-bit file manager on a 64-bit Windows. Windows will hide the content of the 64-bit system directory from 32-bit applications.

I am not sure about the listed error messages; but you seem to have mixed 64-bit and 32-bit DLLs in the same AviSynth plugin autoload directory. No surprise there are issues.

Please take some time to scan this thread backwards; Groucho2004 listed a set of recommended plugins, and this list has been linked a few time since. It will certainly contain the term "RgTools" (search this thread for it).

[Groucho2004]

Originally Posted by odyssey

One thing is that I had to replace avisynth.dll in both system32 and syswow64 with 32-bit MT-dll to make it load at all.

As pointed out by Ligh, it seems that you put 64 bit plugins in the 32 bit plugin directory. This is a real mess.
1. Uninstall Avisynth, delete avisynth.dll and devil.dll from system32 and syswow64, delete the Avisynth directory in "Program Files (x86)".
2. Use the AVS+ installer from here
3. Add your plugins

Once this is working (AVSMeter doesn't report errors), start updating to the latest AVS+ build.

Originally Posted by odyssey

"C:\Program Files (x86)\AviSynth\plugins\HookSurcode.dll"
Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module:   C:\Users\Microsoft Sucks\Downloads\AVSMeter246\AVSMeter246\AVSMeter.exe
Address:  0x003B44E1

"C:\Program Files (x86)\AviSynth\plugins\SupCore.dll"
Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module:   C:\Users\Microsoft Sucks\Downloads\AVSMeter246\AVSMeter246\AVSMeter.exe
Address:  0x003B44E1

What are those? They sure aren't Avisynth plugins.

[PirateIce]

Originally Posted by ErazorTT

I tested that, and no, thats no the case. If lsbd=false than no dithering is done. This can be very clearly seen looking at the chroma planes only with UToY8() or VToY8(). There is a very clear banding going on if lsbd=false. To resolve that dither must be 1. And my point is, that this is much faster than using ditherpost.

looking back at the docs for dfttest:
dither= "Controls whether dithering is performed when converting from float to unsigned char for output. Internally dfttest works on floating point values. For output the result must be quantized back to unsigned char values. Prior to v1.8 this was always done by simply rounding. "

so I read that as meaning from float to 16bit regardless of lsb setting, if thats the case I would think running the following code with lsbd=false would allow dfttest to dither to 8 bit without the dithering issue you described

	dnWindow = (NoiseProcess == 0)      ? NOP() : \
	           (Denoiser == "dfttest")  ? noiseWindow.dfttest( Y=true, U=ChromaNoise, V=ChromaNoise, sigma=Sigma*4, tbsize=noiseTD, threads=FftThreads, lsb=lsbd, dither=1) : \
	        (Denoiser == "KNLMeansCL")  ? noiseWindow.SMDegrain_KNLMeansCL(Chroma=ChromaNoise, lsb=lsbd, a=2, d=NoiseTR, h=Sigma, device_type="GPU" ) : \
	                                      noiseWindow.FFT3DFilter( plane=(ChromaNoise ? 4 : 0), sigma=Sigma, bt=noiseTD, ncpu=FftThreads )
	dnwindow = (Denoiser == "KNLMeansCL" || Denoiser == "dfttest") && (NoiseProcess != 0) && lsbd ? dnWindow.ditherpost(mode=6, U=ChromaNoise?3:2, V=ChromaNoise?3:2, slice=false) : dnWindow
	dnwindow = (Denoiser == "KNLMeansCL" || Denoiser == "dfttest") && (NoiseProcess != 0) && yuy2 ? dnWindow.ConvertToYUY2() : dnWindow

as for lsbd=true I might be wrong about its usage but isnt the whole point of it to stay at 16 bit at this stage and dither later? It doesnt seem to me like its needed to increase internal precision anywhere in dfttest.

[PirateIce]

So, I still think the code just needs the addition of dither=1 as I wrote above, and that internally dithering is what happens when you set lsbd=false, IF you add dither=1 to the code, otherwise it is just quantized to 8 bit.

The part about dither=1 dithering something internally to 16bit i think was gibberish though, sorry ><, I believe it has no effect if lsb=true, but defaults to rounding if not set to 1 even if lsb=false.

And the other part of the edit from ErazorTT seems to just remove the ability to use lsbd=true and should have no effect from what I can tell if lsbd=false. Im refering to the following:

Originally Posted by ErazorTT

dnwindow =    (Denoiser == "dfttest") && (NoiseProcess != 0) && lsbd ? dnWindow : dnWindow #noop since dithering already done by dfttest internally
dnwindow = (Denoiser == "KNLMeansCL") && (NoiseProcess != 0) && lsbd ? dnWindow.ditherpost(mode=6, U=ChromaNoise?3:2, V=ChromaNoise?3:2, slice=false) : dnWindow

[real.finder]

Originally Posted by PirateIce

So, I still think the code just needs the addition of dither=1 as I wrote above, and that internally dithering is what happens when you set lsbd=false, IF you add dither=1 to the code, otherwise it is just quantized to 8 bit.

The part about dither=1 dithering something internally to 16bit i think was gibberish though, sorry ><, I believe it has no effect if lsb=true, but defaults to rounding if not set to 1 even if lsb=false.

And the other part of the edit from ErazorTT seems to just remove the ability to use lsbd=true and should have no effect from what I can tell if lsbd=false. Im refering to the following:

iirc, dither in dfttest will have effect even with lsb

[PirateIce]

ah so it IS a dither that occurs BEFORE the 8 bit conversion, as in float to 16bit Im thinking. In that case it still seems like the effect of dither=1 would still be prefered over rounding with either lsb=true or lsb=false and doesnt need to change in either case.

[ErazorTT]

Originally Posted by PirateIce

ah so it IS a dither that occurs BEFORE the 8 bit conversion, as in float to 16bit Im thinking. In that case it still seems like the effect of dither=1 would still be prefered over rounding with either lsb=true or lsb=false and doesnt need to change in either case.

I think that dithering is actually unnecessary for 16 bit, so that I would suggest to set the lsb and dither parameters exclusively:

..., lsb=lsbd, dither=lsbd ? 0 : 1)

[PirateIce]

Did you see your banding problems disappear and the performance you were looking for with lsb=false and dither=1?

[PirateIce]

Well just to summarize for anyone else, these following changes should improve output when using dfftest and lsbd=false by using the basic dither from float, you can increase the value of the dither to further combat source banding, for example replace dither=lsbd ? 0 : 1 with dither=lsbd ? 0 : 9. All changes at end of first line just added the following lines to clarify with previous suggestions, they are unchanged.

if you are on the latest version of QTGMC 3.352, starting at line 559:

	           (Denoiser == "dfttest")  ? noiseWindow.dfttest( Y=true, U=ChromaNoise, V=ChromaNoise, sigma=Sigma*4, tbsize=noiseTD, threads=FftThreads, lsb=lsbd, dither=lsbd ? 0 : 1) : \
	        (Denoiser == "KNLMeansCL")  ? noiseWindow.SMDegrain_KNLMeansCL(Chroma=ChromaNoise, lsb=lsbd, a=2, d=NoiseTR, h=Sigma, device_type="GPU" ) : \
	                                      noiseWindow.FFT3DFilter( plane=(ChromaNoise ? 4 : 0), sigma=Sigma, bt=noiseTD, ncpu=FftThreads )
	dnwindow = (Denoiser == "KNLMeansCL" || Denoiser == "dfttest") && (NoiseProcess != 0) && lsbd ? dnWindow.ditherpost(mode=6, U=ChromaNoise?3:2, V=ChromaNoise?3:2, slice=false) : dnWindow
	dnwindow = (Denoiser == "KNLMeansCL" || Denoiser == "dfttest") && (NoiseProcess != 0) && yuy2 ? dnWindow.ConvertToYUY2() : dnWindow

[ErazorTT]

Originally Posted by PirateIce

Did you see your banding problems disappear and the performance you were looking for with lsb=false and dither=1?

Yes this resolves both: No banding and faster than lsb=true.

[cork_OS]

Hello.
Is it possible to create QTGMC analog using NNEDI3ocl? Or it won't become any faster than original QTGMC?

[ErazorTT]

Originally Posted by cork_OS

Hello.
Is it possible to create QTGMC analog using NNEDI3ocl? Or it won't become any faster than original QTGMC?

I do not know how much faster the OpenCL version is. But perhaps it already helps to have an optimized version of the normal NNEDI3...

https://github.com/jpsdr/NNEDI3/releases

[cork_OS]

Originally Posted by ErazorTT

I do not know how much faster the OpenCL version is. But perhaps it already helps to have an optimized version of the normal NNEDI3...

https://github.com/jpsdr/NNEDI3/releases

Several NNEDI3 builds shows same speed on my QTGMC script, but NNEDI3ocl is faster NNEDI3 (221fps vs. 160 for 480p source, 117 vs. 36 for 720p source).

[LigH]

I would believe it depends a lot on the available GPGPU.

And furthermore, it might limit the parallelizability; but that has to be tested by people with experience.