Port of NNEDI under new v2.6 AVS API

[Groucho2004]

Originally Posted by stax76

I did test r1576 and also Win10 natively (without vmware), problem persist.

I already asked you over at Don's forum - What client programs do you feed the script to? I don't think MPC-BE is a good choice for testing.
If the script works with VDub64, x264_64, AVSMeter64, I'd say your problem is not the plugin.

[videoh]

Originally Posted by Groucho2004

If the script works with VDub64, x264_64, AVSMeter64, I'd say your problem is not the plugin.

+ 1 Post of the day.

[stax76]

Just because a bug does not surface doesn't mean that the bug does not exist, the only thing that it sure at this point is that the bug exists, it can be in the avs plugin, it can be in the avs core, it can be in the client interop layer, it can be even in the CLR. I tested 15 plugins and only nnedi3, DGMPGDec and DGDecNV have a problem, chances are good we will find it, wherever it is.

[Groucho2004]

Originally Posted by stax76

Just because a bug does not surface doesn't mean that the bug does not exist

I can't quite imagine how the bug you reported (crash) can be concealed by other programs.

Originally Posted by stax76

DGMPGDec

When you search the forum, you'll find that there are all sorts of problems with the 64 Bit version of DGDecode.dll, missing IDCT modes, "green" frames, ...

[stax76]

When MediaInfo was new it wasn't working with any .NET application, I don't know what it was, it could be a bad pointer pointing into managed space I believe.

[videoh]

The 64-bit version of DGMPGDec's DGDecode is not made by Graft and is known to be buggy, as Groucho2004 pointed out. There are no known issues with 64-bit DGDecNV, so please demonstrate one if you can. Graft is always keen to fix issues in his code.

None of Graft's tools contain any "pointers pointing into managed space".

[jpsdr]

Originally Posted by Groucho2004

If the script works with VDub64, x264_64, AVSMeter64, I'd say your problem is not the plugin.

I personnaly would said "It may not be the pluggin, or don't focus only on pluggin".

Originally Posted by stax76

Just because a bug does not surface doesn't mean that the bug does not exist.

I also agree.

The fact also that's it's not crashing with opt=1 means that it's crashing only when using the ASM part code, meaning that something broke the register presevation rules.
If it was a bug in the ASM like a loop going too far or something like that, issue would have poped up earlier and on any system (i think).
This is why within a week or two, i'll take a long time to properly check that the ASM code is not breaking the x64 register preservation rules, according the standard fastcall_ calling procedures. I'll also check code itself, but this is the only thing i think for now.

stax76
You've asked benchmarks :

[General info]
Log file created with:   AVSMeter 2.0.1 (x64)
Avisynth version:        AviSynth+ 0.1 (r1576, x64) (2.6.0.5)
Avisynth DLL location:   C:\Windows\System32\AviSynth.dll


[Clip info]
Number of frames:                 4077
Length (hh:mm:ss.ms):     00:02:50.045
Frame width:                       960
Frame height:                      720
Framerate:                      23.976 (24000/1001)
Colorspace:                       YV12
Audio channels:                    n/a
Audio bits/sample:                 n/a
Audio sample rate:                 n/a
Audio samples:                     n/a


[Runtime info]
Frames processed:               4077 (0 - 4076)
FPS (min | max | average):      17.08 | 99.95 | 55.80
Memory usage (phys | virt):     93 | 91 MB
Thread count:                   37
CPU usage (average):            38%
Time (elapsed):                 00:01:13.060


[Script]
SetMemoryMax(64)
AVISource("Ken - 101.avi",False,"YV12").SetPlanarLegacyAlignment(True)
nnedi3_rpow2(rfactor=2,cshift="Spline36Resize",fwidth=960,fheight=720,nsize=0,nns=3,qual=2)

[General info]
Log file created with:   AVSMeter 2.0.1 (x64)
Avisynth version:        AviSynth+ 0.1 (r1576, x64) (2.6.0.5)
Avisynth DLL location:   C:\Windows\System32\AviSynth.dll


[Clip info]
Number of frames:                 4077
Length (hh:mm:ss.ms):     00:02:50.045
Frame width:                       960
Frame height:                      720
Framerate:                      23.976 (24000/1001)
Colorspace:                       YV12
Audio channels:                    n/a
Audio bits/sample:                 n/a
Audio sample rate:                 n/a
Audio samples:                     n/a


[Runtime info]
Frames processed:               1903 (0 - 1902)
FPS (min | max | average):      15.32 | 36.55 | 26.79
Memory usage (phys | virt):     92 | 91 MB
Thread count:                   37
CPU usage (average):            74%
Time (elapsed):                 00:01:11.047


[Script]
SetMemoryMax(64)
AVISource("Ken - 101.avi",False,"YV12").SetPlanarLegacyAlignment(True)
nnedi3_rpow2(rfactor=2,cshift="Spline36Resize",fwidth=960,fheight=720,nsize=0,nns=3,qual=2,opt=1)

Input video is encoded with UT Video codec.

[foxyshadis]

Originally Posted by stax76

Just because a bug does not surface doesn't mean that the bug does not exist, the only thing that it sure at this point is that the bug exists, it can be in the avs plugin, it can be in the avs core, it can be in the client interop layer, it can be even in the CLR. I tested 15 plugins and only nnedi3, DGMPGDec and DGDecNV have a problem, chances are good we will find it, wherever it is.

Can you capture a crash dump in WinDbg, or install VS on the VM to debug it realtime? That might help a lot more. Access Violation on its own doesn't really tell a lot.

[stax76]

I already migrated to Win10 and Visual Studio 2015 Community Edition RC, I can try things but would need some hints because my C++ knowledge is only very basic.

[jackoneill]

Originally Posted by stax76

I use x64 exclusively everywhere so it's difficult for me to test. I would have to download and setup everything. Is there a big performance difference between c and asm path? QTGMC uses nnedi3 and still works.

The ASM is something like 10 times faster, if I remember correctly (with default parameters).

jpsdr: I noticed this while perusing your ASM: https://github.com/jpsdr/NNEDI3/blob..._x64.asm#L1414 I don't know if that function is even used when it crashes, since stax76 hasn't provided the parameters passed to nnedi3...

[jpsdr]

Good !!! And I don't know if it's related or the cause (there a good chance), but it's clearly a miss from my part wich need to be corrected.
Even with stax76 parameters, i don't know if i can say if this function is called or not.
I'll try to make a new build as soon as i can.

[jpsdr]

New buid avaible for test.

[stax76]

It still crashes, I'm trying to build the solution now with VS 2015 RC, it says /ZI and /O2 are incompatible.

[Groucho2004]

Originally Posted by stax76

it says /ZI and /O2 are incompatible.

Optimizations have to be turned off for debug builds.

[stax76]

Thanks, I turned off optimizations and replaced

this line:

#include "afxres.h"

with:

#include "WinResrc.h"
#define IDC_STATIC -1

I thought MFC is included with Community Edition?

The build succeeds now but why doesn't it output any DLLs?

[stax76]

It's always breaking as access violation in this line:

https://github.com/jpsdr/NNEDI3/blob...edi3.cpp#L1258

There is however something in my code because I just noticed it only happens in the preview dialog and it loads in the crop dialog fine, I didn't expect that. I don't remember I do threading or something special. At least we have some hints now.

edit:

crop dialog does not use any other filters than the source I was forgetting

[Groucho2004]

Originally Posted by stax76

It's always breaking as access violation in this line:

https://github.com/jpsdr/NNEDI3/blob...edi3.cpp#L1258

There is however something in my code because I just noticed it only happens in the preview dialog and it loads in the crop dialog fine, I didn't expect that. I don't remember I do threading or something special. At least we have some hints now.

edit:

crop dialog does not use any other filters than the source I was forgetting

Have you tried "threads=1" with nnedi?

[stax76]

Originally Posted by Groucho2004

Have you tried "threads=1" with nnedi?

does not make a difference, it works fine with opt=1

[jpsdr]

Picture information is interesting. If registers value are correct, RAX & RCX at 0, crash is expected. But issue is that RAX shouldn't be at 0, it's the source pointer. As this crash occur during the y loop, is the crash occuring at the first occurence of the loop, or after several ?

[jpsdr]

I think i found another miss from my part, i'll do another build ASAP (but stay with same version).