Avisynth+

[ultim]

hi

I have two aWarpSharp in autoload folder, aWarpSharp and aWarpSharp2 by SEt

In normal avs if I use


LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\aWarpSharp.dll")
someSource("E:\New.mkv")
aWarpSharp


green border will appear which mean that old aWarpSharp is using

but in avs+ only aWarpSharp2 will be used

I use this method in other cases also

Are you using the latest release (r1576)? This is something that should have been fixed there.

[real.finder]

Are you using the latest release (r1576)? This is something that should have been fixed there.

yes, and even r1595 the same thing

[ultim]

yes, and even r1595 the same thing
the only difference between 1576 and 1595 is the cache, so if the former one didnt work, the latter one is no surprise.

anyway, thx for reporting, i'll investigate.

[list]

In Avisynth 2.58, i used to make it portable, and just place avisynth.dll and devil.dll beside my mplayerc player and play any avs's, just needed to run this .reg with these values for "installing" on my system manually, without any installer.
The reg file contains these register key values:
REGEDIT4

[HKEY_CLASSES_ROOT\avifile\Extensions\AVS]
@="{E6D6B700-124D-11D4-86F3-DB80AFD98778}"

[HKEY_CLASSES_ROOT\Media Type\Extensions\.avs]
"Source Filter"="{D3588AB0-0781-11CE-B03A-0020AF0BA770}"

[HKEY_CLASSES_ROOT\CLSID\{E6D6B700-124D-11D4-86F3-DB80AFD98778}]
@="Avisynth"

[HKEY_CLASSES_ROOT\CLSID\{E6D6B700-124D-11D4-86F3-DB80AFD98778}\InProcServer32]
@="avisynth.dll"
"ThreadingModel"="Apartment"

[HKEY_CLASSES_ROOT\Wow6432Node\Media Type\Extensions\.avs]
@=""
"Source Filter"="{D3588AB0-0781-11CE-B03A-0020AF0BA770}"

[HKEY_LOCAL_MACHINE\SOFTWARE\CLASSES\WOW6432NODE\CLSID\{E6D6B700-124D-11D4-86F3-DB80AFD98778}\INPROCSERVER32]
@="AviSynth.dll"
"ThreadingModel"="Apartment"

But now, this dosn't work with avsPlus. So i needed to run the full install to make it work.
What would be the new .reg equivalent now to meke it portable if possible?
BTW the project looks promising :D

[qyot27]

I'm guessing that due to the use of C++11 (the future header and whatnot), the MT additions will bump the compiler requirements up to VS 2012 or higher?

[innocenat]

I'm guessing that due to the use of C++11 (the future header and whatnot), the MT additions will bump the compiler requirements up to VS 2012 or higher?

Yes, the MT additions will bump the compiler requirement to VS2012. (It's actually already available in MT branch on GitHub)

[qyot27]

Yes, the MT additions will bump the compiler requirement to VS2012. (It's actually already available in MT branch on GitHub)
Okay. That's why I asked; it failed to build under 2010.

[jpsdr]

Will avs+ still working under Windows XP after MT...?

[TurboPascal7]

Will avs+ still working under Windows XP after MT...?

Yes. Public builds have been compiled with VS2012 since the beginning I think.

But I'm afraid it won't work in wine anymore, at least my threaded plugins don't.

[ultim]

OK, seeing that words about the MT version is beginning to spread on the forums, I'd like to point out that it is very experimental and still has some problems. I am very gratefull if anybody wants to test and give feedback / problem reports, but if your motivation is not to test but to start using it earlier, don't. The quality is not there yet. I'll announce in this thread when it reaches a quality niveau worthy of public testing. That being said, you can find the experimental builds on http://goo.gl/e0VFYn . Just remember, don't use it until you're prepared that it will break.

[easyfab]

Do we need some setmtmode() or mt() or is it automaticaly multithreaded ?

[ultim]

Do we need some setmtmode() or mt() or is it automaticaly multithreaded ?

You need to enable MT operation in the script. But let's just first test the single-threaded mode...

[naoan]

You need to enable MT operation in the script. But let's just first test the single-threaded mode...

Is SetFilterMTMode disabled on that build?

[innocenat]

Is SetFilterMTMode disabled on that build?

There is no public MT build yet.

[naoan]

Oh sorry, I thought it is with experimental.

[TurboPascal7]

Okay, it appears I was right and new experimental threaded builds do not work in wine. If anyone figures how to run it - please feel free to post the instructions. Otherwise poor linux users won't be able to enjoy any newer build of avs+ until native support is implemented and plugins are ported or this gets fixed in wine.

[ultim]

Okay, it appears I was right and new experimental threaded builds do not work in wine. If anyone figures how to run it - please feel free to post the instructions. Otherwise poor linux users won't be able to enjoy any newer build of avs+ until native support is implemented and plugins are ported or this gets fixed in wine.

It is most probably because of the threading bits of the VC++2012 runtime.

Possible solutions:
- Get the VC++2012 runtime somehow correctly working on Wine.
- Submit bug report to Wine and have it fixed.
- Wait for native Linux support in avs+ so that Wine won't be needed.

[dvdan23]

The bug which prevents vc++2012 from installing under WINE was reported in 2009

http://bugs.winehq.org/show_bug.cgi?id=17273

Waiting for that to get fixed seems like a long shot, though it has been targeted for 1.8 for whatever that's worth.

As awesome as it sounds, waiting for "native Linux support" seems fraught with peril also, since many have attempted this in the past and not quite made it (Avisynth3, avxsynth, vapoursynth).

Ultim, have you taken some time to assess the downsides of limiting yourself to VC++2010 SP1? if you would consider it at least one linux user will rejoice.

http://appdb.winehq.org/objectManager.php?sClass=application&iId=5766

[TurboPascal7]

Actually, getting native linux support on the core side is not hard. You can expect the core to work in its full power, unlike avxsynth that removed optimizations and some filters which didn't have C versions, avisynth 3 that didn't happen or vsynth, which is vsynth. You'll also get some essential plugins from avs+ modernization efforts thread and maybe some more. But of course it'll be quite a while before any serious scripts like qtgmc can run on linux. As usual - patches welcome. :)

To replace vs2012 features with vs2010, one will need to introduce some huge dependency like boost. This was discussed already and we decided that using C++11 is a better option. Also Myrsloik promised to kill me if we don't go C++11 and you don't want that, do you? >__>

[ultim]

It is pretty much as Turbo explained. I have originally implemented avs+MT with only boost, and thus I could compile the code with VC++2010. Because of the threading part I was relying on the non-header-only libraries of boost (but even with headers only, boost is a beast considering its size). So later the requirement was bumped to VC++2012 in order to remove the boost dependency, because C++11 implements everything I used from boost, but VC++2010 doesn't yet implement the necessary parts of the standard.

Anyway, I didn't foresee that it would break Wine-support, that hit me unexpected. IMHO we should try to put some pressure on the Wine folks, and depending on what their reaction is, we either win, or I can step back and pull in boost again. I'd rather not though unless it is really necessary, so let's try convincing the Wine folks first. It's on their to-do list anyway :)

[dvdan23]

Turbopascal7, I certainly wouldn't want Myrsloik to kill you. I also don't want to see Linux compatibility killed though.

As I missed this discussion, I take it "requiring a huge dependency" was deemed the greater evil vs. breaking under Linux? FWIW, that wouldn't have been my vote.

If boost libraries are indeed of comparable quality, it seems to me it's a dependency either way. In my case, the dependency of windows is a far greater evil than the dependency on a free, portable library like boost. the boost licensing is pretty unrestrictive. How's the performance?

If the death of Avisynth+ on Linux is truly unavoidable, and last minute calls to the governor can't do anything to save it, might it be feasible to keep a single-threaded branch alive on the git hub and/or make a periodic build for folks who can't run VC2012++? if other solutions pan out that'll be great but I suspect that might be a few years.

[TurboPascal7]

If boost libraries are indeed of comparable quality, it seems to me it's a dependency either way. In my case, the dependency of windows is a far greater evil than the dependency on a free, portable library like boost. the boost licensing is pretty unrestrictive. How's the performance?
Dependency on windows has always been there, nothing really changed on that front. The fact that wine has bugs is, well, a wine's problem. I don't think it's appropriate to make life of 99% of avisynth users and all contributors harder to compensate for it. Dependencies on external libraries over standard are pretty much always worse - it's harder to setup build enviroment, it takes longer to compile and usually produces large binaries.

I understand that it's quite unfortunate that avs+ won't work on linux, but it can't be helped. You could always setup a VM too. And if the demand for linux support is high, of course there will be some developers willing to port plugins to this platform.

If the death of Avisynth+ on Linux is truly unavoidable, and last minute calls to the governor can't do anything to save it, might it be feasible to keep a single-threaded branch alive on the git hub and/or make a periodic build for folks who can't run VC2012++? if other solutions pan out that'll be great but I suspect that might be a few years.
Not to mention that it might be quite hard to merge the changes, there's one more problem with this solution - the plugins. With MT implemented in avs+ core, internal threading in plugins is strongly discouraged and you can expect it to get removed from most "updated" plugins, leading a lot worse performance with singlethreaded versions of avisynth. Asking developers to maintain branches with internally threaded code in all of these plugins is way too much. So you'll be either enjoying crippled performance or will have to avoid newer versions of such plugins.

[dvdan23]

Learned something new from the Wine folks. Apparently the approach they are taking is to build a complete VC++ library replacement so you don't need to install VC++ runtimes. Apparently if the "Microsoft Foundation Classes" can be avoided, there's a better shot at Avisynth++ working under WINE.

From the bug $17273 "Applications affected" page;

NOTE: There is an ongoing effort in Wine to provide a complete Microsoft Visual C++runtime library replacement - removing the need of installing the Microsoft VC++ redistributable packages. This is a work in progress hence you might still need to install Microsoft VC++ runtime.

If the application uses MFC library (Microsoft Foundation Classes), there will be no replacement hence installation of Microsoft Redistributable is a requirement for applications and games to work!

TurboPascal7, I'm not going to argue with you because I'm thrilled with the work you are doing making more plugins 64-bit. I'll tell you though, I'm much more interested in stable, working, 64-bit non-threaded avisynth plugins than threaded ones. Keep up the good work.

[TurboPascal7]

The only thing I wanted to say is that making the wine guys fix their stuff is a lot better than limiting program functionality in any way. I'm sure if users complain enough, they'll get it working sooner than later. ;)

[qyot27]

It would appear that a deeper fix would be needed anyway, since while it is possible to yank the .dlls themselves out of the vcredist installer*, and thereby avoid the Wine errors concerning Apartment Threading when trying to install normally, the .dlls either need extra registering during the install process, or Wine has a problem with them regardless of the installer and needs fixing (which is also likely). Trying to use them with AviSynth+ and ffmpeg resulted in ffmpeg crashing with a C++ exception of some sort.

Granted, I was testing with Visual Studio 2013 builds and the corresponding vcredist, but I'm sure the same things apply for 2012 (or maybe they don't and for 2012 this would actually work; I don't know).


*Methodology ('dark' is dark.exe from the WiX Toolset):
dark vcredist2013.exe -x outputpath
go into vcRuntimeMinimum_x86 and use cabextract or 7-zip on the cab files; the MFC stuff is in vcRuntimeAdditional_x86
rename the F_CENTRAL files to .dll with the proper names (trim off the F_CENTRAL prefix and arch suffix, add .dll extension)
copy dlls to Wine's windows/system32 directory.

[ultim]

Ahh, d9 is back again. So in case if you want to know what is happening with AviSynth+: A lot!

First of all, we had a very long meeting last weekend where we focused on the most pressing matters about our GSoC application. Some still need finalization and most importantly, the ideas still need to be published in a well-formulated form. Also, please welcome our GSoC team. SEt, TurboPascal7, and myself are official mentors, while Innocenat and Firesledge have offered to help us from behind the scenes during GSoC. We'll let you know more about GSoC projects for Avs+ soon.

The MT capability of AviSynth+ is coming along nicely too, and after some more pushes from me the others have starting looking at making all the internal filters MT-safe. There is also a new API that is noteworthy, because it allows lower memory usage in general (even in single-threaded scripts!) for all filters that reserve memory on construction. Filters are being modified to make use of that too. After some bug fixes the MT build seems pretty stable, but the performance is not at its top yet. Nevertheless, this weekend or shortly after that there will probably be a public test, for the interested amongst you.

Also, I've heard today that Innocenat is experimenting with a Linux port of AviSynth+. Don't expect it to come in a couple of days since he only started recently, but work has been started nonetheless.

One kind of help we could use is if somebody stepped up to maintain the website. There will be more pages to post there real soon, so the current layout won't cut it for long. Not to mention the code duplication between pages currently isn't exactly maintainer-friendly. So it'd be nice if one of you could alter it or come forward with a new design, and maybe make changes in the future when we have new content to post. So let us know if you can help here.

Cheer for us to be successfull, we'll be back with more updates later. And don't forget to star us on GitHub :)

[turbojet]

Does this mean Innocenat is done working on tivtc (http://forum.doom9.org/showthread.php?p=1655991&highlight=tivtc#post1655991)?

If so, was there no gains or something else?

[TurboPascal7]

Does this mean Innocenat is done working on tivtc (http://forum.doom9.org/showthread.php?p=1655991&highlight=tivtc#post1655991)?
No, it doesn't.

[innocenat]

Does this mean Innocenat is done working on tivtc (http://forum.doom9.org/showthread.php?p=1655991&highlight=tivtc#post1655991)?

If so, was there no gains or something else?

No, I am not.

There are times when I have free time with only Linux available, so I use that time to port.

[turbojet]

I see, thanks for the update, eagerly anticipating a faster tivtc or a wip ivtc filter that's just as capable. Maybe you've seen it but tritical's post (http://forum.doom9.org/showthread.php?p=1658871#post1658871) may help.

[Paser]

When I try to replace the AviSynth.dll in SysWOW64 with my newly compiled one, I get this error after trying to load an avs in VirtualDub:

http://puu.sh/6HLni.png

Any way to fix this?

[Stereodude]

Maybe you should post your script...

[ultim]

When I try to replace the AviSynth.dll in SysWOW64 with my newly compiled one, I get this error after trying to load an avs in VirtualDub:

http://puu.sh/6HLni.png

Any way to fix this?

The current builds definetely work with VirtualDub. Are you using the correct architecture? E.g. if you are placing the plugin in SysWOW64, you must be running 32-bit VirtualDub, and you must use the 32-bit version of AviSynth.

If all else fails, try running AviSynth+'s setup, that does the upgrade for you correctly. But given that you take the correct DLL versions, just replacing the avisynth.dll should also be enough.

[ryrynz]

Is it stable yet? I been waiting for MT build for months. I has the itch, go go go! :D

[TurboPascal7]

You can always build it yourself or join our IRC channel (#avs-plus on Rizon) if you want to test things before they make it to this forum. ;)
MT is not fully "stable" yet, but test builds will follow very soon.

[ultim]

OK, sorry that I missed the release on the weekend, but it is not easy to stay on time with lots of things going on, like overtime and deadlines at work, private server upgrade (which must also be done on deadline or else I'll loose my data), internet outage, lot's of GSoC preparations, and even (yes) some coding for AviSynth, to name a few from the top of my head.

But I bring you now a shiny new test build, r1689, which - in contrast to the previous one - is actually usable. Probably even much better than that. So I strongly suggest everyone to give it a shot, aside that I can probably improve on the thread scheduler for some more performance, you'll have fun with it (in a good way). Just make sure you set the correct MT mode for your filters. Here (https://pad.riseup.net/p/avs_plus_mt_modes) is a snippet that you can start with, but please add some new filters to that list on your own too. Don't bother with built-in filters though, they're already handled internally, so you only need to add filters from external plugins.

The MT branch is now also the main branch of AviSynth+, which means all (even non-MT) improvements end up here, and it will be merged into "master" as soon as it has received enough testing. But now you might wonder what are the "other" user-visible changes compared to the stable release. Mainly:

innocenat has worked more on the resizers, which are now even faster and require less memory, especially (but not only) when working on planar video and you have SSE3.
This (http://forum.doom9.org/showthread.php?p=1662595#post1662595) issue is fixed, which sometimes caused that a filter function from the wrong DLL would get used. Thx for reporting the issue, real.finder.
If a plugin DLL cannot be loaded, a human-readable error from Windows is also displayed, giving the user a clue what is wrong.
Filters that reserve memory on construction can now share that same piece of memory between multiple instances, giving large memory savings in many cases. Most affected internal filters have been updated to make use of this capability, most by tp7. Some external filters will follow when the API is officially stable.
The new caching system is done, and it will result in noticably lower memory usage than any previous "classical" AviSynth version. Give it a try, you'll be surprised how much memory it brings in complex scripts.
SSE2 has been a requirement for Avs+ by mistake, this is fixed now, and you now only need an SSE-machine.

Of course all the above is paired with a lot of rewrites, refactorings, and cleanups. And then there's MT. :)

"Yeah-yeah-yeah, enough with the talk, just give me a build already." Right, http://goo.gl/e0VFYn. And don't forget to add some filters (after testing them) yourself to this list: https://pad.riseup.net/p/avs_plus_mt_modes

In my next post I'll briefly summarize how to use AviSynth+ in its multithreaded mode.

[ultim]

So, how to use MT in AviSynth+? Most of it has been posted earlier actually, but let me summarize it.

By default, your script will run in single-threaded mode, just like with SEt's build. Also, just like in SEt's build, you'll have to make sure that filters use the correct MT mode, or else they might wreak havoc. There are three MT modes (1,2,3), and they are the same modes as in (yeah you guessed correctly) SEt's build. Which means you can use the same modes that you have used with AviSynth-MT.

There are some things though that are different and/or new in AviSynth+. The first difference is *how* you set the MT mode. In AviSynth-MT, you had to use SetMTMode(X), which caused all filters following that line to use mode X (until the next call to SetMTMode()). This meant if you needed to use multiple MT modes, you had to insert all those calls in the middle of your script, littered over many places.

Setting MT modes
AviSynth+ does it differently. In AviSynth+, you specify the MT-mode for only specific filters, and those filters will then automatically use their own mode, even if there were other MT-modes inbetween. This means you can specify all the MT modes at the beginning without polluting your script. You can even make a SetMTMode.avsi if you wish and let it autoload for all of your scripts, or import() it from their top. This is much cleaner, and it allows you to maintain all your MT-modes centrally at a single place. To make this distinction clear from AviSynth+, SetMTMode() is called SetFilterMTMode() in AviSynth+.

Enabling MT
The other difference is how you actually enable multithreading. Calling SetFilterMTMode() is not enough, it sets the MT mode, but the MT mode only has an effect if MT is enabled at all. Note this means you can safely include/import/autoload your SetFilterMTMode() calls in even single-threaded scripts, and they will not be messed up. Uhm, onto the point: You enable MT by placing a single call to Prefetch(X) at the *end* of your script, where X is the number of threads to use.

Example
# This line causes all filters that don't have an MT mode explicitly use mode 2 by default.
# Mode 2 is a relatively safe choice until you don't know most of your calls to be either mode 1 or 3.
# Compared with mode 1, mode 2 trades memory for MT-safety, but only a select few filters will work with mode 1.
SetFilterMTMode("DEFAULT_MT_MODE", 2)

# FFVideoSource(), like most source filters, needs MT mode 3
SetFilterMTMode("FFVideoSource", 3)

# Now comes your script as usual
FFVideoSource(...)
trim(...)
MCTemporalDenoise(...)
...

# Enable MT!
Prefetch(4)

Closing notes (don't skip!)

Remember that MT is only stable as long as you have specified a correct MT mode for all filters.
Instead of the numbers 1-2-3, you can also use symbolic names for MT modes: MT_NICE_FILTER (1), MT_MULTI_INSTANCE (2), MT_SERIALIZED (3)
Mode 3 is evil. It is necessary for some filters, and it is usually no problem for source filters, but it can literally completely negate all advantages of MT, if such a filter is placed near the end of your script. Let us know if you meet a non-source mode 3 filter, we might be able to do something about it, but in general, avoid such calls if you want performance. (And of course, insert what you have found into here (https://pad.riseup.net/p/avs_plus_mt_modes).)
The new caches will save you a lot of memory in single-threaded scripts, but due to the way they work, they will also use more memory than before with MT enabled. The memory usage will scale much closer with the number of threads you have. Just something to keep in mind.
MT-enabled AviSynth+ triggers a latent bug in AvsPmod. Until a new version of AvsPmod is officially released, use this (http://files.line0.in/builds/AvsPmod-2.5.1-r426-x86-04874ed.7z) build. A thousand thanks to vdcrim for the fix.
Using too many threads can easily hurt performance a lot, because there are other bottlenecks too in your PC than just the CPU. For example, if you have a quad-core machine with 8 logical cores, less than 8 threads will often work much better than 8 or more.

[easyfab]

Thanks Ultim and avs+ team for this release, here my first little test on an intel I2600K.

http://pastebin.com/Di0w2Y0y

Not bad for a first version :) ,
for info avs+ single thread -> FPS (min | max | average): 28.47 | 32.69 | 30.88

The difference I see is in frame count 145 vs 103, could it explain the difference in speed ?

[ultim]

The old masktools2-a48 has a serious issue that will make things blow up/crash if MT is used. Newer rebuilds of that same plugin work correctly, such as the one from QTGMC's Modded Plugin Package (http://forum.doom9.org/showthread.php?t=156028), or TurboPascal7's rewrite (http://forum.doom9.org/showthread.php?t=169832).

[easyfab]

I have mt_masktools-26.dll (from 06_taro ) and I try with TurboPascal7's rewrite It give me the ~ same result -> FPS (min | max | average): 33.20 | 144.55 | 74.46

[ultim]

Thanks Ultim and avs+ team for this release, here my first little test on an intel I2600K.

http://pastebin.com/Di0w2Y0y

Not bad for a first version :) ,
for info avs+ single thread -> FPS (min | max | average): 28.47 | 32.69 | 30.88

The difference I see is in frame count 145 vs 103, could it explain the difference in speed ?

Hi, thanks for the test. You can also try with a bit fewer threads (5-6), it will often result in better speeds. Otherwise, as noted above, you can expect further performance improvements from MT in the future, as I'm still working on it. This was just an early test build.

As for the thread count, I'm not sure to be honest. Probably because a mode 2 plugin has internal threading too. Both are way too high though, but I'm glad to see that Avs+ has the less threads.

[easyfab]

Ultim,

You're right about threads:

threads : Prefetch(8) vs Prefetch(5)
fps average : 76.77 vs 81.52
And less memory 520 vs 444

[Groucho2004]

As for the thread count, I'm not sure to be honest. Probably because a mode 2 plugin has internal threading too. Both are way too high though, but I'm glad to see that Avs+ has the less threads.
The 145 threads from the first example are easily explained:

setmtmode(5,8) #8 threads for MT

QTGMC(preset="fast", EdiThreads=8).selecteven() #8 Edithreads * 8 MT threads = 64 threads

distributor() #Distributor is already called in AVSMeter so calling it twice makes 64 * 2 = 128 threads

Finally, add some threads for other filters and you have your 145 threads.

[Groucho2004]

@ultim
Before I start digging through the AVS+ code - How do I determine the MT mode in Avisynth+?
In AVSMeter, I have been doing it like this so far (for SEt's MT DLL), pretty much the same as it's done in x264:
AVSValue AVS_temp;
int iMTMode = 0;
try
{
AVS_temp = AVS_env->Invoke("GetMTMode", false);
iMTMode = AVS_temp.IsInt() ? AVS_temp.AsInt() : 0;
if ((iMTMode > 0) && (iMTMode < 5) && settings.bInvokeDistributor)
AVS_main = AVS_env->Invoke("Distributor", AVS_main);
}
catch (IScriptEnvironment::NotFound)
{
}


Also, is Prefetch() similar to the Distributor() call?

[qyot27]

I've run into an issue with resampling audio.

As sometimes happens, if you use AssumeFPS's sync_audio parameter, the resultant sample rate gets wonky, requiring a follow-up use of SSRC to correct it. Even worse, depending on the source and output samplerates, you have to use SSRC twice - once before the AssumeFPS, and again afterward. The canonical example would be something like 44.1kHz synced to 30000/1000 fps, resampled to 48kHz synced to 30000/1001 fps.

In 2.6a5 and r1576, this worked like it always does. But somewhere between r1576 and r1636 (r1689 also shows it), possibly in the MT or cache changes, the above operation can cause an error at the end of encoding and audio truncation when using FFAudioSource as the input source. Now, I'm not entirely sure if it's something that needs to be fixed on FFMS2's side or not, but the problem is as follows:

Script Input -> Script Output FFmpeg log message
44.1kHz -> 44.1kHz no error
44.1kHz -> 48kHz [avisynth @ 03922860] FFAudioSource: Out of bounds audio samples requested (single use of SSRC, no fps change)
44.1kHz@30fps -> 48kHz@29.97fps same error, plus truncated* (SSRC->AssumeFPS w/sync_audio=true->SSRC)
48kHz -> 48kHz no error

*IIRC, 44.1->48 without an fps change might have also had some truncation, but it wasn't nearly as bad as the resample+fps change test was.

r1689 = error, truncated
r1636 = error, truncated
r1576 = works, no truncation
2.6a5 = works, no truncation

Script:
FFmpegSource2("[AKROSS Con 2013] Okami - Quiet.mp4",atrack=-1,fpsnum=30000,fpsden=1000)
SSRC(48000,fast=false)
AssumeFPS(29.97,sync_audio=true)
SSRC(48000,fast=false)

FFmpeg:
ffmpeg -i test.avs -vn -acodec pcm_s16le test-48re.wav

This was all single-threaded. I wasn't using any MT-related functions at all (not to mention that I'm using a single-core CPU without hyperthreading).

Saving a resampled (but not fps-resynced) PCM file and then importing that in with WAVSource before doing the AssumeFPS and SSRC adjustment results in no error and possibly no truncation (or the much more minor one I mentioned above).

[ultim]

How do I determine the MT mode in Avisynth+?

You cannot get the MT mode in Avs+. IMHO it wouldn't make too much sense because an MT-mode is always associated with a filter. So at best you could ask which MT mode is a particular filter configured to use. You can ask for the number of threads though, but that is part of IScriptEnv2, which is not officially stable yet.

Also, is Prefetch() similar to the Distributor() call?

Yes, I think it is (given that I undertsand Distributor() halfway correctly). But Prefetch() shouldn't be inserted automatically, it should always be added by the user when they want a multithreaded chain. All in all, I don't think Avs+MT should need special handling in tools like Avs-MT did with the Distributor().

[Groucho2004]

You cannot get the MT mode in Avs+. IMHO it wouldn't make too much sense because an MT-mode is always associated with a filter. So at best you could ask which MT mode is a particular filter configured to use. You can ask for the number of threads though, but that is part of IScriptEnv2, which is not officially stable yet.

Thanks. I basically just want to know if a script is running multi-threaded or not.

[ultim]

I've run into an issue with resampling audio.

...


Hi qyot27,

Could you please check these special builds for you if you experience the same problem with either of them? And if so, which one?
EDIT: lol, sry i forgot to post the link: https://mega.co.nz/#F!sZkDjKRD!ZZz7oQvYP6FQ0F0rAeYOoQ

[ryrynz]

Just wondering why this is crashing my media player am using ffdshow raw.

SetFilterMTMode("", 2)
SetFilterMTMode("ffdshow_source", 3)
ffdshow_source()
Psharpen()
Prefetch(4)

I've tried stating Psharpen in a SetFilterMTMode as well but same deal. I just copied the Avisynth DLL into my SYSWOW64 folder. What am I missing?
Also is SetMemoryMax still something that should be set?

[ultim]

Thanks. I basically just want to know if a script is running multi-threaded or not.

Yes, you can tell that using IScriptEnvironment2::GetProperty(AEP_FILTERCHAIN_THREADS), but please don't use it before the whole IScriptEnvironment2 is finalized. This is not a licensing restriction, it has to do with the fact that if you start using it and the class changes after that, your application will break.