Avisynth+

[ultim]

Does it even have to do anything with the intrinsics there? Looks completely unnecessary (like most of the C++ duhuhu).

Those shuffles around line 458 need a compile-time constant expression, which is why lines 443-444 were made a constexpr, I suppose. Removing the constexpr needs different templating, different intrinsics, or a condition added in the depths of those loops...

[TurboPascal7]

Those shuffles around line 458 need a compile-time constant expression, which is why lines 443-444 were made a constexpr, I suppose. Removing the constexpr needs different templating, different intrinsics, or a condition added in the depths of those loops...
Welp. Imo just copypaste the whole function into three different functions for different sizeof(T) and the problem goes away on its own. The code will be better too.

[ultim]

Guess it's probably not a good idea to stay vs2010 or 2013, the latest c++ standard is c++14 so..
And vs2015 community is free anyways, what's the point of getting stuck at square one

Hopefully not for long.

VS2010-support is only for the public headers, not for compiling Avs+ core itself, so that you have a larger choice of compilers when writing your plugins.

VC2013 is the oldest supported compiler for compiling the core, and is only because of Wine, as apparently it still has some problems with the VC2015 runtimes. As soon as Wine gets with the times, I have no problem in dropping VC2013 support.

[RazorBurn]

Does someone here have links to Avisynth+MT r2005?

[fAy01]

Does someone here have links to Avisynth+MT r2005?

http://avs-plus.net/builds

2043 is the latest.

[tormento]

http://avs-plus.net/builds

2043 is the latest.

OMG... did not noticed it.

Changelog?

[ryrynz]

Changelog?

https://github.com/AviSynth/AviSynthPlus/commits/MT

Will 1858 be the last unofficial build with legacy plugin compatibility?

[MysteryX]

https://github.com/AviSynth/AviSynthPlus/commits/MT

Will 1858 be the last unofficial build with legacy plugin compatibility?
Just to be clear, the only plugins that are incompatible are those that used "env2" while ignoring the warning not to use it. Mostly to register their MT mode. Only a few plugins are doing that.

[RazorBurn]

http://avs-plus.net/builds

2043 is the latest.

Huge Thanks.. Bookmarked..!!

[ryrynz]

http://avs-plus.net/builds


If I install DirectShowSource.dll from link above to the latest build in my plugins folder I get a C++ exception when using avisynth+ffdshow.
I don't believe I'll use it anyway and have deleted it, but can someone quickly detail what features it provides?

[Reel.Deel]

If I install DirectShowSource.dll from link above to the latest build in my plugins folder I get a C++ exception when using avisynth+ffdshow.
I don't believe I'll use it anyway and have deleted it, but can someone quickly detail what features it provides?

The latest AviSynth+ releases incorporate pinterf's changes, as well as some bugs fixes, and also introduced support for 16/32 bit YUV formats. High bit depth is still a work-in-progress but there's already a handful of internal filters that support the new formats. Ultim is working on a longstanding MT issue and also mentioned that some MT optimizations are coming.

Will 1858 be the last unofficial build with legacy plugin compatibility?

There's nothing to worry about here, AviSynth+ still supports all the plugins it always has. The issue that MysteryX mentioned has been taken care of, the few affected plugins have been fixed and are working correctly. The latest nnedi3 (v0.9.4.22) is the only plugin currently not working but a fix is coming soon. Use an older version for the mean time.

[qyot27]

DirectShowSource is a source filter of last resort, because DirectShow support of X or Y format is often unstable (and the filter isn't frame accurate in general). Pretty much every other source filter does a better job for whatever format(s) they're designed to open, leaving DSS for extreme edge cases.

It was the only general-purpose source filter prior to 2007, but ever since FFmpegSource (and especially since FFMS2 and LSMASHSource/LwLibavSource), its importance has shrunk to a minimum.

Because it was one of the few plugins that had used IScriptEnv2, newer versions can only be used by newer versions of the AviSynth+ core. Pairing DirectShowSource.dll from AviSynth+ r2022 or r2043 with the core AviSynth.dll from r1858 or prior will, of course, fail spectacularly.

[pinterf]

Good evening.
New functions ported to 16 bit/float.


Info
ShowFrameNumber / ShowSMPTE / ShowTime
Subtitle


Info() additions:

display the name of the high bit-depth color spaces instead of Unknown color space.
display AVX CPU flag if detected.

[LigH]

Indeed, a good evening! :)

:thanks:

[real.finder]

does avs+ has same avs limit of 50 active plugins at one time?

[Chikuzen]

does avs+ has same avs limit of 50 active plugins at one time?

IIRC, the limit was gone after 2.57.
Both avs2.6 and avs+ has no imit of number of loading plugins.

[real.finder]

IIRC, the limit was gone after 2.57.
Both avs2.6 and avs+ has no imit of number of loading plugins.

it still existing in 2.6, I see it in some of my tests in complex script

[Groucho2004]

it still existing in 2.6, I see it in some of my tests in complex script
Indeed. In plugin.cpp (2.6 and also 2.6.1):
enum { max_plugins=50 };

The plugin loading in AVS+ is quite different and from what I've seen, there's no plugin limit in the code (or maybe I didn't look thoroughly).

[Myrsloik]

I will just put this link here (http://stevedower.id.au/blog/building-for-python-3-5-part-two/). Dlls are fun.

[ultim]

Indeed. In plugin.cpp (2.6 and also 2.6.1):
enum { max_plugins=50 };

The plugin loading in AVS+ is quite different and from what I've seen, there's no plugin limit in the code (or maybe I didn't look thoroughly).

In Avs+ there's no limit.

[ultim]

r2069 (http://avs-plus.net/builds) 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 (https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/filters/field.cpp#L618)). 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]

r1069 (http://avs-plus.net/builds)

*r2069 :devil:

[ultim]

*r2069 :devil:

lol, thx

[Sparktank]

:thanks: 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]

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:
https://s31.postimg.org/mibto65ff/Image1.png

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

[ultim]

Just tried the SetLogParams(target, level) function, very cool:
https://s31.postimg.org/mibto65ff/Image1.png

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]

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]

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 (https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/filters/field.cpp#L618))

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]

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]

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]

Just tried the SetLogParams(target, level) function, very cool:
https://s31.postimg.org/mibto65ff/Image1.png

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

Ehm... where is 2.3.1? :cool:

[yup]

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

[Groucho2004]

Ehm... where is 2.3.1? :cool:
On my hard drive. ;)

[Groucho2004]

Hi all!
Please advice how install test version?
yup.
Install this (https://www.dropbox.com/s/xrh84z02sm2hpg8/AviSynth%2B%20r2022.7z?dl=0) 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]

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]

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?

[yup]

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

[Groucho2004]

After install Your package r2022, Windows 10 64.
Did you install the latest runtimes (14.0.23506)?

[yup]

Did you install the latest runtimes (14.0.23506)?
No!
I can find only 14.0.23206.
Please give me link.
On my PC installed 14.0.24210
yup.

[Groucho2004]

No!
I can find only 14.0.23206.
Please give me link.
On my PC installed 14.0.24210
yup.
"14.0.24210" is indeed the latest, my mistake. As for your problem, I have no idea, try cleaning up the auto-load directory so you have only the DLLs installed with AVS+.

[ultim]

I fixed a false positive in the diagnostic messages and pulled pinterf's latest high bit-depth work in r2076.

[burfadel]

14.0.24210 is known to be buggy though in some scenarios.

[ultim]

No!
I can find only 14.0.23206.
Please give me link.
On my PC installed 14.0.24210
yup.

just did a clean install of avs+ using official installer from website, then replaced it with newest build from avs-plus.net/builds. works as expected.

i doubt it is the runtimes, probably some plugin. if you have a plugin from jpsdr, mysteryx or chikuzen, you will need a recent build of them to not crash. also make sure when you copy a new build of avs+, you also copy the plugin dlls that come with it into the correct folders.

[pinterf]

Today's Avisynth Plus news:

Blur and Sharpen ported to 16 bit/float.


P.S. is there anybody who runs avisynth plus on a non SSE2 capable processor?

For me the 32 bit version with compile option SSE2 instead of SSE yielded almost 10% gain. Maybe because this script uses high bitdepth routines that are mostly in C?

lsmashvideosource("13HoursCUT.mp4", format="YUV420P8")
Crop(0, 140, 0, -140)
Spline64Resize(400,340)
orig = last
x8=orig.Blur(1.0,1.5).Info()
x8d=orig.Sharpen(1.0, 1.0).Info()
x16=orig.ConvertTo16bit().Blur(1.0, 1.0).Info()
x16d=orig.ConvertTo16bit().Sharpen(1.0, 1.0).Info()
x32=orig.ConvertToFloat().Blur(1.0, 1.0).Info()
x32d=orig.ConvertToFloat().Sharpen(1.0, 1.0).Info()
StackHorizontal(\
StackVertical(x8.ConvertTo8bit(),x16.ConvertTo8bit(),x32.ConvertTo8bit()),\
StackVertical(x8d.ConvertTo8bit(),x16d.ConvertTo8bit(),x32d.ConvertTo8bit())\
)
ConvertTo8bit()

[TheFluff]

P.S. is there anybody who runs avisynth plus on a non SSE2 capable processor?
I dunno about avs+ specifically but if there's anywhere you can find people who actually own functioning non-SSE2 CPU's in 2016, it's doom9. This guy (http://forum.doom9.org/showthread.php?p=1764874#post1764874) turned up in the FFMS2 thread a few months ago, for example.

Still, SSE2 was introduced fifteen years ago so I think it's pretty reasonable to expect people who do CPU-intensive tasks like video encoding to have it. The only CPU that was even remotely popular that didn't have SSE2 after 2001 was the Athlon XP, and those things really aren't too common anymore.

[tedkunich]

snip...The only CPU that was even remotely popular that didn't have SSE2 after 2001 was the Athlon XP, and those things really aren't too common anymore.

I retired mine about 5 years ago.... :D