Port of NNEDI under new v2.6 AVS API

[luquinhas0021]

jpsdr, can you make the modification on nnedi3 algorithm, which tritical never did? Here will go the change, speaked by tritical: replace L1 and L2 by L0.5 (sqrt(abs(error)).

[feisty2]

Not possible

[luquinhas0021]

why isn`t?

[feisty2]

Go retrain nnedi and you could have any new feature you want, mr daydreamer

[jpsdr]

Not possible, because this is a part of the training wich produces the neural network datas, not a part of the algorithm itself. In the filter, when you choose L1 or L2, it just changes what data package will be used.

[Groucho2004]

The latest build crashes with Evaluate: System exception - Access Violation.

I took the DLL from "NNEDI3_v0_9_4_20.7z", x86, Release_XP (the other XP builds crash as well).

Script:
colorbars(width = 1920, height = 540, pixel_type = "yv12").killaudio().assumefps(25, 1)
NNEDI3(dh = true)

This is on XP32SP3, any Avisynth version.

I seem to recall that previous builds worked. However, I can't find them on your github page, there is only the latest release.

SEt's Avisynth MT returns this (probably because it has better exception handling):
Avisynth: access violation at 0x00011C0D in E:\Apps\VideoTools\AVSPlugins\AutoLoad\nnedi3.dll,
attempting to read from 0x00000000

It crashes with mpc-hc and AVSMeter but not with VirtualDub.

[jpsdr]

Argh.... Not crashing with VDub is annoying, can't have disassembled code.
Nevertheless, it's not something related/specific to x64, so it's probably not an issue with the ASM code.
Is it XP specific ? Do you have tihs issue on others OS (if you have others OS) ?
I think the last version is the first version compiled with VS2015. If you recall previous build worked, maybe this is a clue.
Now i have VS2015Updt1. I'll PM you a link with a new build for test, just in case.
Otherwise, I'll do more tests after WE, at work i have XP32SP3, with VS2010.

[Groucho2004]

Argh.... Not crashing with VDub is annoying, can't have disassembled code.
Nevertheless, it's not something related/specific to x64, so it's probably not an issue with the ASM code.
Is it XP specific ? Do you have tihs issue on others OS (if you have others OS) ?
I think the last version is the first version compiled with VS2015. If you recall previous build worked, maybe this is a clue.
Now i have VS2015Updt1. I'll PM you a link with a new build for test, just in case.
Otherwise, I'll do more tests after WE, at work i have XP32SP3, with VS2010.
VS2015 is compatible with XP but you probably have to set a target platform flag in your project properties. You should also not link statically, with newer versions of VS and DLLs it is not advisable (source (https://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.140%29.aspx)).

[Reel.Deel]

I seem to recall that previous builds worked. However, I can't find them on your github page, there is only the latest release.


Do you remember which version? I have v0.9.4.7 through v0.9.4.18.

[Groucho2004]

Do you remember which version? I have v0.9.4.7 through v0.9.4.18.
No, I don't remember. The problem is most likely the switch to the VC14 compiler.

[jpsdr]

VS2015 is compatible with XP but you probably have to set a target platform flag in your project properties.
Even that seems not enough. I think i'll try to install back VS2013. Once done, i'll probably make a new release, but don't expect things too soon.
I think only the last (.20) is compiled with VS2015.

[Groucho2004]

Even that seems not enough. I think i'll try to install back VS2013. Once done, i'll probably make a new release, but don't expect things too soon.
I think only the last (.20) is compiled with VS2015.
Don't change anything just on my account. The "original" nnedi3, (or rather my fturn mod) suits my needs.

[Groucho2004]

Even that seems not enough. I think i'll try to install back VS2013. Once done, i'll probably make a new release, but don't expect things too soon.
I think only the last (.20) is compiled with VS2015.
This (https://connect.microsoft.com/VisualStudio/feedback/details/1789709/visual-c-2015-runtime-broken-on-windows-server-2003-c-11-magic-statics) may be a potential cause.

[TheFluff]

just drop support for xp already, jeez

encouraging people to upgrade to an os from this decade isn't going to kill anyone, and the people who are determined to be stuck in 2001 for as long as possible are kind of a lost cause anyway

[hello_hello]

encouraging people to upgrade to an os from this decade isn't going to kill anyone, and the people who are determined to be stuck in 2001 for as long as possible are kind of a lost cause anyway

You seem to be confusing "determination" with Microsoft's inability to produce a better OS, while assuming everyone only owns a single PC. Not to mention the fact Microsoft decided to exclude XP from the free upgrade to Win10 offer, which is more about opportunity than determination.

[jpsdr]

@Groucho2004
Issue has been reported around 5 months ago, i don't remember when the Update 1 of VS2015 was out.
Thanks for this information.

[Groucho2004]

just drop support for xp already, jeez

encouraging people to upgrade to an os from this decade isn't going to kill anyone, and the people who are determined to be stuck in 2001 for as long as possible are kind of a lost cause anyway
Dropping support for XP (or even Win2K for that matter) just for the heck of it seems rather silly. If the code doesn't use APIs that are only supported in Win7/8/10 I can't find a reason to deliberately break compatibility with earlier OS versions.

Your post is yet another predictable rant, I find it peculiar that you get so upset about people's personal choices.

[Daemon404]

Dropping support for XP (or even Win2K for that matter) just for the heck of it seems rather silly. If the code doesn't use APIs that are only supported in Win7/8/10 I can't find a reason to deliberately break compatibility with earlier OS versions.


I don't know where you saw this was deliberate. New tools, shockingly, do not support old OSes which have not been supported by their maker since before the release of said tools.

I think it's somewhat unreasonable to use an OS that has no support from its make, and is EOL'd, yet to expect things written/compiled in 2016 still work on them.

[Groucho2004]

New tools, shockingly, do not support old OSes which have not been supported by their maker since before the release of said tools.I was referring to VS2013/2015 which, according to MS, do support XP. Besides, there is nothing in the code of nnedi3 that would prevent it from running on XP and jpsdr even provides binaries targeted for XP.

I think it's somewhat unreasonable to use an OS that has no support from its make, and is EOL'd, yet to expect things written/compiled in 2016 still work on them.I'm not sure why the year in which something was written/compiled is relevant. If something is written using APIs exclusive to WinNT 6.x I do of course not expect it to run on WinNT 5.x. However, if the code and the compiler support NT 5.x, why drop support for it?

[hello_hello]

Regarding the problem with the XP flavour of NNEDI3 0.9.4.20....

Is it possible the XP and Win7 versions in the 7z package are the same file? There's differences.... the modified times are 10 seconds apart and they have a different MD5 Hash, but they appear to be exactly the same in size. They also behave the same way for me (running XP).

QTGMC 3.33 results in an access violation error message at lines 729 and 510 (in QTGMC script) when opening a script with MPC-HC and MeGUI. That applies to both the XP and Win7 versions of NNEDI3.
The same script opens fine in VirtualDubMod when using either version.
Not that I know if it means anything, but it seems a little co-incidental.

[Groucho2004]

Regarding the problem with the XP flavour of NNEDI3 0.9.4.20....
It appears that this (http://forum.doom9.org/showthread.php?p=1759707#post1759707) was the cause of the VS2015 builds crashing on XP.

Is it possible the XP and Win7 versions in the 7z package are the same file?
...
they have a different MD5 Hash
I don't know how to respond to this...

[jpsdr]

Is it possible the XP and Win7 versions in the 7z package are the same file?
No.

the modified times are 10 seconds apart
I build them one after another, so the difference in time is the time to build, change the profile in VS, build the next, etc...
So, of course, expect several seconds between them.

Soon (within less than 2 weeks i hope) i'll release a .21 version, with build fix for XP, thanks to Groucho2004 who provides me the links about the issue, and was nice to test...;)

[hello_hello]

"Is it possible the XP and Win7 versions in the 7z package are the same file?"

I don't know how to respond to this...

I mentioned the difference in modified time and MD5 Hash because I thought it might indicate the two files were created using the same settings rather than one literally being a copy of the other. I don't know if that'd result in a different MD5 Hash, but simply copying a file doesn't change it's modified time either.

Try again with a bit more context.

"There are differences ...the modified times are 10 seconds apart and they have a different MD5 Hash"

Apparently I should have explained why I mentioned it, although in hindsight I'll admit describing them as "the same file" rather than "the same" was a newbee mistake and an open invitation for someone to be "clever".

[StainlessS]

Different MD5 is different file (Time and other attributes make no difference).

[hello_hello]

Soon (within less than 2 weeks i hope) i'll release a .21 version, with build fix for XP

Thanks.
Admittedly I thought it was unlikely they were the same file or accidentally created using the same settings because it seemed a little too obvious, but you never know, so I thought I'd ask.
I'll look forward to the new version.
Thanks again.

[jpsdr]

but they appear to be exactly the same in size.

Just for the record, i've noticed that very often final builds have exactly the same size, even when between them there is code change. Only case of realy minor code change, of course.

[Groucho2004]

"Is it possible the XP and Win7 versions in the 7z package are the same file?"

I mentioned the difference in modified time and MD5 Hash because I thought it might indicate the two files were created using the same settings rather than one literally being a copy of the other. I don't know if that'd result in a different MD5 Hash, but simply copying a file doesn't change it's modified time either.

Try again with a bit more context.

"There are differences ...the modified times are 10 seconds apart and they have a different MD5 Hash"
The context makes no difference. The time stamp of the files has nothing to do with their content.

"the same file" rather than "the same"
:confused::confused:

Apparently I should have explained why I mentioned it, although in hindsight I'll admit describing them as "the same file" rather than "the same" was a newbee mistake and an open invitation for someone to be "clever".
I was not trying to be clever, I was simply stumped that a member who's been around here for 5 years and has posted ~2500 messages doesn't know what a MD5 hash is.

[ryrynz]

"Is it possible the XP and Win7 versions in the 7z package are the same file?"


Yeah not to drag this out, but if a programmer smart enough to create a port of NNEDI3 for Avisynth releases & multiple versions of it, you can be sure there's a difference.
And if for some reason a mistake was made, you'd be sure one of the doom9 members here would've picked up on it a long time ago.
Give people the benefit of the doubt, especially when you don't understand the technical aspects. This should hopefully close the topic.

[hello_hello]

The context makes no difference. The time stamp of the files has nothing to do with their content.

If a file was simply a copy of another they'd have the same modified time. Once again, I mentioned the difference in MD5 Hash and modified time to indicate I thought rather than one file being a direct copy of another they might be the same file created twice with identical settings. Open an MKV with MKVMergeGUI and remux it. Remux it again. The resulting MKVs are essentially the same file but they'll have a different MD5 Hash, and believe it or not, a different modified time. I thought it'd be obvious that's what I was referring to. I thought I'd adequately explained it in my last post but apparently it didn't help, even after admitting I probably should have said "the same" rather than "the same file" for those easily stumped. Third time lucky, maybe?

Yeah not to drag this out, but if a programmer smart enough to create a port of NNEDI3 for Avisynth releases & multiple versions of it, you can be sure there's a difference.
And if for some reason a mistake was made, you'd be sure one of the doom9 members here would've picked up on it a long time ago.
Give people the benefit of the doubt, especially when you don't understand the technical aspects. This should hopefully close the topic.

I already admitted it was unlikely the files were the same or they were created with the same settings, but I thought I'd ask just in case. Thanks for dragging out a topic that should have been closed already.
Just to be clarify though.... I can be sure someone else would pick up a mistake that I can be sure wouldn't be made in the first place. Is that how it works?

[StainlessS]

It is quite understandable that someone who has never had cause, to not know that file/dir attributes are not part of the file.
Hello_Hello, for instance on Fat FileSys, the times stamps, file size, read/write status, etc are stored in the directory for the
file, and if copy is done, then attributes (where appropriate) are duplicated to the target directory for the copy.
I have no idea how NTFS stores general attributes, but expect that it is pretty much the same.

EDIT: Further to FAT: Fat only stores data on where clusters are located. Cluster being a group of consecutive sectors,
to reduce the amount of 'tracking' data, so a file even if it only occupies a single byte will occupy at least a single cluster (normally 8
512 byte sectors, especially if standard compression/encryption is involved [standard compression/encryption only works on 8 sector
clusters ie 4KB, unless things have changed]). The file itself consists of a number of bytes [spread out over a number of clusters], the only
way the filesystem can determine size, is to view the directory information, and to curtail any additional data after that [rest is rubbish]).
FAT: has no Access Control Lists, which are additional attributes to the file in NTFS, and I have no real idea on how that is accomplished.
(I have in past [2 decades ago] written equivalent to FAT ChkDisk software, but running upon non PC equipment, so I [at least at one time]
had some general idea of how that stuff works).

[hello_hello]

I'll confess I don't understand how the file attributes not being part of the file affect anything I said. Mind you I hadn't really thought about it until now, but if a copy of a file has exactly the same MD5 Hash as the original, it seems logical they can't be.
I pointed out the difference in MD5 Hash and modified time to indicate I realised one file wasn't likely to be a direct copy of another but possibly created using the same settings, although it's not impossible for a file to be a copy that's altered in some way so it has a different modified time and MD5 Hash as a result. An example might be opening an MKV with MKVToolNix's header editor and changing an attribute. It wouldn't necessarily change the functionality of the MKV, or it's file size. Unfortunately though, not explaining that in detail led to the assumption I don't know what an MD5 Hash is, while I assumed mentioning the different MD5 Hash meant I wouldn't have to explain it.

[StainlessS]

An MD5 (or similar) is a numerical 'Fingerprint' which identifies (with almost 100.0% certainty) that two files are the same.
(MD5 is calculated from the numbers/bytes within the file, the how does not matter but you can look it up).
Even a small change in a file (1 byte, 1 bit) results in a big difference in MD5, making it very difficult to forge the same MD5.
It is possible for more than a one single unique content file to produce that same checksum (MD5) but in almost all circumstances the
two files would be completely different, and same MD5 can occur just by accident, ie obvious that it is not a forgery
because content is totally different. [eg a 500 bytes text file COULD have exact same MD5 as a 2GB Movie file,
but it would be obvious that they are not the same file, it would take an exceptional amount of computer power to
change a small text file to be different and still make sense (ie make forgery by changing original a little)].

EDIT: MD5 is calculated from the file contents, a number/fingerprint calculated from the contents, not the Timestamp etc.
You can change time/date read/write status hidden attribute etc without it affecting the MD5. There would be no point to MD5 if it
changed for everybody that eg saved it at different times (timestamp, there are 3 different timestamps for a FAT file,
Creation, Modification and Last Access).

EDIT: An MD5 CAN with 100% certainty make it clear that two files are different.

[hello_hello]

Thanks for the info, although to be honest I can't see anything I've written that implies I don't know what an MD5 is, and I did state it's logical that timestamps and attributes wouldn't effect the MD5. I honestly thought I was originally implying I knew the two files couldn't be exact copies due to the different MD5, because that's the main reason I specifically mentioned it, but the possibility the two files were created independently using the same settings crossed my mind, as did the possibility one was initially a copy of the other, but later modified in some way. The latter didn't seem likely, but I had no idea I was giving the impression I didn't understand what an MD5 was or that I mentioned the different modified date for any other reason than it also indicated the files aren't exact copies.
In hindsight I probably could have phrased the question a little less literally so as not to upset the pedantic police, but at the time it didn't seem necessary.

[jpsdr]

New build, see first page.

[bxyhxyh]

I've been wondering since I started to use it.
What is core2 builds for?
For core2duo processor or any Intel processor with 2 cores?

[ryrynz]

I've been wondering since I started to use it.
What is core2 builds for?
For core2duo processor or any Intel processor with 2 cores?
You don't have optimised builds for dual cores.. Only instruction sets. First guess is correct.

[hello_hello]

New build, see first page.

I haven't used it yet, but thank you!

[DJ-1]

So if im using the x64 version with a 3770K the Release_W7 version is the right one to use?

Sent from my LG-H815 using Tapatalk

[ryrynz]

So if im using the x64 version with a 3770K the Release_W7 version is the right one to use?


W7_Core2_SSE4.2

[DJ-1]

Thanks...just need to find the update 2 runtime it mentions....

Sent from my LG-H815 using Tapatalk

[jpsdr]

Switching discuss here about MT.
Don't want to mess with the core structure, i also want it continue working on any avisynth version, i'm working on something which should make the filter "NICE" (i think.. hope), with the less code change in the core structure.
Just have to find/gather some informations of how doing some things with Visual Studio. Allready find how to use mutex, just have to find how i can do something similar to mutex, but not exactly a mutex. In fact, something that will wait for a change of state of some "mutex like" object. I'll probably find what i'm looking for in searching on google something like "thread synchronization visual studio"...

[MysteryX]

Switching discuss here about MT.
Don't want to mess with the core structure, i also want it continue working on any avisynth version, i'm working on something which should make the filter "NICE" (i think.. hope), with the less code change in the core structure.
Just have to find/gather some informations of how doing some things with Visual Studio. Allready find how to use mutex, just have to find how i can do something similar to mutex, but not exactly a mutex. In fact, something that will wait for a change of state of some "mutex like" object. I'll probably find what i'm looking for in searching on google something like "thread synchronization visual studio"...

Search C++, not Visual Studio

[jpsdr]

Question for avisynth masters.
In the nnedi3 constructor, there is :

child->SetCacheHints(CACHE_GET_WINDOW,3);

What does this do ?
Is it still necessary ?
Or is it interesting to keep this on not MT mode, but remove it on MT mode ?

Otherwise, i think i've found what i was looking for in my previous post.

[shekh]

Look for winapi documentation for synchronization primitives (msdn). "mutex like".. are you looking for critical section?

[jpsdr]

Ok MT guys ! ;)

You can test, benchmark, MT_NICE, torture this (https://github.com/jpsdr/NNEDI3/releases/tag/beta) version.

It's for now only x86, and compiled with VS2010 (so, should also work on XP...).

EDIT : I've add on the release page the modified files (nnedi3.cpp and nnedi3.h) in nnedi3_src_beta.7z.

[GMJCZP]

Thank you for your effort, jpsdr!
Still I am a XP user, lol.

EDIT: MT is about SEt MT?

[jpsdr]

Yes, but also avs+ MT.

[MysteryX]

Question for avisynth masters.
In the nnedi3 constructor, there is :

child->SetCacheHints(CACHE_GET_WINDOW,3);

What does this do ?
Is it still necessary ?
Or is it interesting to keep this on not MT mode, but remove it on MT mode ?

If I remember correctly, someone mentioned recently that SetCacheHints is a hack that could be used for the filter to define its MT compatibility modes without having to configure it manually.

It's not intuitive but it's the only place that they could put the extra information without needing to change the API.

[Chikuzen]

Question for avisynth masters.
In the nnedi3 constructor, there is :

child->SetCacheHints(CACHE_GET_WINDOW,3);

What does this do ?
Is it still necessary ?
Or is it interesting to keep this on not MT mode, but remove it on MT mode ?

Otherwise, i think i've found what i was looking for in my previous post.

child->SetCacheHints(CACHE_GET_WINDOW, any_int_value) do nothing and just returns cache filter's current h_span value of window if cache is inserted.
on avisynth2.6, it will always return 0 (default value of LRU cache).
on avisynh+MT, it always returns 2 (hard coded value).

anyway, I think that the code is not necessary because the return value is not used at all.

[Wilbert]

Looking at the 0.94 sources it should be SetCacheHints(CACHE_WINDOW, frame_range), but i have no idea whether it is necessary.