martin53
2nd June 2016, 20:38
Hi Reel.Deel,
1) MT_NICE_FILTER or not
I think I obeyed all stringent rules ultim wrote down here (http://forum.doom9.org/showthread.php?p=1649886#post1649886) (no internal frame caching, no env pointer saving, no class variable writing etc.), but added internal multithreading.
Before I decided to learn multithread coding, I did extensive tests to use the Avisynth_MT / Avisynth+ multithreading. But it worked only with synthetical source filters and very simple filter graphs. I have a 3000+ lines avsi function library to e.g. automatically choose source filters, open playlists (m3u files containing video file names) etc., and the syntax differences, but also the instability/unreliability seemed impossible to master with that library, so I gave up on that and decided to optimize xNLMeans for a single threaded script environment. I think it is reasonable because the NLMeans algorithm is really slow compared to almost anything else that would typically be done in an Avisynth script.
Since I only succedded in testing xNLMeans in extremely simple MT environments, and more complex setups failed before I even included a xNLMeans() call, I can only say it's a MT_NICE_FILTER to the best I know, but I still might have missed something. Maybe one of the pros would like to have a look at the source code.
P.S.: 2 posts later, ultim writes that MT mode=1 will create one plugin instance for several Avisynth threads and call that with different environment pointers. I'ts a bit difficult for me at the moment to imagine what that will do with local, non-static instance variables, when the instance is re-entered. I did (and do) assume that only one plugin class is available in MT mode=1, but every instance has control over its local variables.
Btw. I sticked to Avisynth+ r1779, because LoadVirtualDubPlugin() failed in r1825 on my PC. Didn't know about r1849 yet.
2) Thread exit code, strange error msgs.
The internal thread function (xNLMeans_GetframeXX.cpp) only provides exit code 0, and 0x0815 to indicate a specific internal calculation issue. All other codes must come from abnormal program execution external to the thread function itself, e.g. windows thread management. The internet did not give me very enlighting information about 0x103, but it might indicate premature master thread end, while a slave thread is still active? This should be impossible from line 301 of xNLMeans.cpp ... but I remember that I might have experienced similar issues in MT environments, and at some point stopped to investigate further since I don't have the time to do a complete debug including the Avisynth code calling the plugin.
Some Avisynth concepts like SetMemoryMax() are dubious to me to this day; and I was even unable to use the Avisynth+ dispatcher together with AvsPmod, and I lost interest in a concept that does only work with certain viewers/encoders.
3) Detection of external MT
I fully agree that would be nice, just don't have any idea how it could be done. If someone gives a hint, I'll be glad to add it.
1) MT_NICE_FILTER or not
I think I obeyed all stringent rules ultim wrote down here (http://forum.doom9.org/showthread.php?p=1649886#post1649886) (no internal frame caching, no env pointer saving, no class variable writing etc.), but added internal multithreading.
Before I decided to learn multithread coding, I did extensive tests to use the Avisynth_MT / Avisynth+ multithreading. But it worked only with synthetical source filters and very simple filter graphs. I have a 3000+ lines avsi function library to e.g. automatically choose source filters, open playlists (m3u files containing video file names) etc., and the syntax differences, but also the instability/unreliability seemed impossible to master with that library, so I gave up on that and decided to optimize xNLMeans for a single threaded script environment. I think it is reasonable because the NLMeans algorithm is really slow compared to almost anything else that would typically be done in an Avisynth script.
Since I only succedded in testing xNLMeans in extremely simple MT environments, and more complex setups failed before I even included a xNLMeans() call, I can only say it's a MT_NICE_FILTER to the best I know, but I still might have missed something. Maybe one of the pros would like to have a look at the source code.
P.S.: 2 posts later, ultim writes that MT mode=1 will create one plugin instance for several Avisynth threads and call that with different environment pointers. I'ts a bit difficult for me at the moment to imagine what that will do with local, non-static instance variables, when the instance is re-entered. I did (and do) assume that only one plugin class is available in MT mode=1, but every instance has control over its local variables.
Btw. I sticked to Avisynth+ r1779, because LoadVirtualDubPlugin() failed in r1825 on my PC. Didn't know about r1849 yet.
2) Thread exit code, strange error msgs.
The internal thread function (xNLMeans_GetframeXX.cpp) only provides exit code 0, and 0x0815 to indicate a specific internal calculation issue. All other codes must come from abnormal program execution external to the thread function itself, e.g. windows thread management. The internet did not give me very enlighting information about 0x103, but it might indicate premature master thread end, while a slave thread is still active? This should be impossible from line 301 of xNLMeans.cpp ... but I remember that I might have experienced similar issues in MT environments, and at some point stopped to investigate further since I don't have the time to do a complete debug including the Avisynth code calling the plugin.
Some Avisynth concepts like SetMemoryMax() are dubious to me to this day; and I was even unable to use the Avisynth+ dispatcher together with AvsPmod, and I lost interest in a concept that does only work with certain viewers/encoders.
3) Detection of external MT
I fully agree that would be nice, just don't have any idea how it could be done. If someone gives a hint, I'll be glad to add it.