Avisynth+

[ultim]

r2069 is out, and this build should be fun I encourage you all to take a look at it, as it brings some serious enhancements to MT, and then some. Let's see...

- First and foremost, I sincerely hope I can put issue #37 behind me, and unless somebody proves otherwise, plugins should now be able to reliably specify their MT-mode using the SetCacheHints() mechanism (for an example, see the usage of CACHE_GET_MTMODE here). This means, there is no need any more to use IScriptEnv2, which is still unstable. With this method there is also no need for plugins to differentiate between Avs 2.6 and Avs+, and it allows you to specify different MT modes for your filter depending on the construction parameters. With one word: use this, not IScriptEnv2.

- The calculation of the final MT mode got a lot smarter. For filter calls which create a hierarchy of nested filters, it is often incorrect or at least sub-optimal to use the MT-modes as specified directly. Avs+ will smartly make adjustments in such cases to ensure reliable results. Unless of course the filter or the user used the “force” option in SetFilterMtMode(), so don't force unless reeeeally necessary (e.g. because of a bug in a filter).

- The behavior of MT_SERIALIZED (mode 3) changed. While the earlier implementation caused all filters that are called from the serialized filter to be also serialized, now it only serializes the one and only filter that it is specified for. This has a couple of important consequences:
-- If you have a mode 3 filter towards the end of your script, the speed penalty is much-much less, since earlier basically your whole script went into mode 3, whereas now other filters can still execute in parallel. The placement of mode 3 filters in your script just got un-critical!
-- This also means it is now a really bad idea to have a big lock/mutex inside your GetFrame() instead of marking it as mode 3, because your plugin will exhibit the old behavior and you won't be able to benefit from the potential improvements at all.
-- There is also a downside: The new mode 3 theoretically does not provide the same amount of MT-protection as the old one. However, I'm not sure it matters to many plugins at all. If it does, the old mode will be re-introduced as mode 4. So keep me up-to-date!

- Avs+ will now automatically recognize source filters. If it sees a source filter which has no MT-mode specified at all, it will automatically use mode 3 instead of the default MT mode. This is great for source filters as in their case it rarely hurts performance and they often need mode 3 anyway, and it will help yet unclassified source filters perform correctly without any user action. One step closer to the "it just works" target.

- Avs+ received a logging facility. You can enable it using SetLogParams(target, level) at the beginning of your script. 'target' can be either "stderr", "stdout", or a path to a file. Level is LOG_ERROR/LOG_WARNING/LOG_INFO/LOG_DEBUG (not strings), with increasing verbosity. Log messages can be output by scripts using LogMsg(msg, level). I went for Log() initially but it was already taken by the math function.

- If logging is enabled, Avs+ will output log messages by itself too. It will automatically log errors, and will issue warnings and notes to the user to inform him about potential problems, buggy plugins, suboptimal settings etcetera. There are a couple of these log messages and they come in various colors. How many can you find? Gotta catch 'em all!


Edit: Despite my obvious enthusiasm, this build is still a test build. Please treat it as such.

[Sparktank]

Originally Posted by ultim

r1069

*r2069

[ultim]

Originally Posted by Sparktank

*r2069

lol, thx

[Sparktank]

This is definitely going to be fun to try out over the next while.

Really like where the future is headed.

Thanks to everyone for getting involved.

[Groucho2004]

Originally Posted by ultim

Avs+ received a logging facility. You can enable it using SetLogParams(target, level) at the beginning of your script. 'target' can be either "stderr", "stdout", or a path to a file. Level is LOGLEVEL_ERROR/WARNING/INFO/DEBUG (not strings), with increasing verbosity. Log messages can be output by scripts using LogMsg(msg, level). I went for Log() initially but it was already taken by the math function.

Just tried the SetLogParams(target, level) function, very cool:


However, I had to use "SetLogParams("stdout", 4), "LOGLEVEL_DEBUG" was not recognised.

[ultim]

Originally Posted by Groucho2004

Just tried the SetLogParams(target, level) function, very cool:


However, I had to use "SetLogParams("stdout", 4), "LOGLEVEL_DEBUG" was not recognised.

Ah, my bad. It is actually LOG_ERROR/WARNING..., not LOGLEVEL_... I corrected the post above. I mixed it up with the naming used by the C++ code. Thx!

[Groucho2004]

Originally Posted by ultim

Ah, my bad. It is actually LOG_ERROR/WARNING..., not LOGLEVEL_... I corrected the post above.

That works, thanks.

[LigH]

You provided r2069 as a whole subdirectory (r2069-MT-test) in your "builds" base directory; its download returned a 51.3 MB ZIP, due to including both MSVC Redist installers. I guess you might add a 7zip archive of this directory, excluding both runtimes, in the "builds" base directory, so that people who already installed the runtimes may download a smaller archive instead.

[jpsdr]

Originally Posted by ultim

and unless somebody proves otherwise, plugins should now be able to reliably specify their MT-mode using the SetCacheHints() mechanism (for an example, see the usage of CACHE_GET_MTMODE here)

If i understand properly, i just have to re-define the SetCacheHints function of my filter class, is it ?
This SetCacheHints function will be afterward use by avisynth core, i don't have to use it myself in my filter ?

[jpsdr]

I've done it for nnedi3, but i can't do this for nnedi3_rpow2 because this last one is not a class filter, only the function create exist. We'll have to wait a stable IScriptEnvironment2 to set its MT mode for this last one. It is disable for now, waiting, but shouldn't prevent it to work, because there's still the mutex for safety.

[ultim]

Originally Posted by jpsdr

If i understand properly, i just have to re-define the SetCacheHints function of my filter class, is it ?
This SetCacheHints function will be afterward use by avisynth core, i don't have to use it myself in my filter ?

Correct. Just override the function, and return your MT mode when called with CACHE_GET_MTMODE.

[ultim]

Originally Posted by jpsdr

I've done it for nnedi3, but i can't do this for nnedi3_rpow2 because this last one is not a class filter, only the function create exist. We'll have to wait a stable IScriptEnvironment2 to set its MT mode for this last one. It is disable for now, waiting, but shouldn't prevent it to work, because there's still the mutex for safety.

Then there is no need to specify an MT mode for nnedi3_rpow2. Its MT-mode will be determined dynamically based on the other filters it creates. With different words, don't use IScriptEnvironment2 for nnedi3_rpow2 even when it becomes stable, because you only need to set the MT mode for class filters. No need to wait for anything.

[pinterf]

ultim, thanks for the new mt stuff, does it have any measurable overhead (speedwise) for the already "well-behaving" scripts?

[tormento]

Originally Posted by Groucho2004

Just tried the SetLogParams(target, level) function, very cool:


However, I had to use "SetLogParams("stdout", 4), "LOGLEVEL_DEBUG" was not recognised.

Ehm... where is 2.3.1?

[yup]

Hi all!
Please advice how install test version?
yup.

[Groucho2004]

Originally Posted by tormento

Ehm... where is 2.3.1?

On my hard drive.

[Groucho2004]

Originally Posted by yup

Hi all!
Please advice how install test version?
yup.

Install this and overwrite the files with the ones from r2069.

[yup]

Groucho2004!
After install, I am get error during check with avsmeter -avsinfo

AVSMeter 2.3.0 (x86) - Copyright (c) 2012-2016 Groucho2004

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module:   Cannot determine module
Address:  0x00000001

All Microsoft dll installed.
At wsndows\system32 I am see Avisynth.dll dated 6 July.
yup.

[ultim]

Originally Posted by pinterf

ultim, thanks for the new mt stuff, does it have any measurable overhead (speedwise) for the already "well-behaving" scripts?

Not in general.

The "already well-behaving" part is tricky though, as it might be that, depending on implementation details in a specific filter, it might behave correctly, while a different one might not under the exact same conditions (same MT mode, same nesting etc.). The new MT "stuff" favors correctness in this sense, not speed. I'd be interested if anybody can show numbers as I don't yet have many, but I think performance degradations, if any at all, should be negligible and rare.

[Groucho2004]

Originally Posted by yup

After install, I am get error during check with avsmeter -avsinfo

AVSMeter 2.3.0 (x86) - Copyright (c) 2012-2016 Groucho2004

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module:   Cannot determine module
Address:  0x00000001

All Microsoft dll installed.
At wsndows\system32 I am see Avisynth.dll dated 6 July.
yup.

Define "after install". After installing r2022 or after copying over the r2069 files? Which version(s) do you want to install? What OS?