Where do I put ffms2

[VideoBeginner]

I'm know that this will sound absurd to most (or all) of you, but I do not know where to place the files for ffms2.

Background info:

I was being helped with this topic (http://forum.doom9.org/showthread.php?t=175252) where I was given this:
v=BlankClip(fps=25)
a=ffaudiosource("source.mkv")
AudioDub(v, a)
AssumeFPS(24000, 1001, true)
ResampleAudio(48000)
Opening the script in MPC-HC came the error "There is no function named 'audiosource'" and when I mentioned this I was told to download ffms2.

But... now what? Do I place all of the files in my ffmpeg directory? AviSynth+ plugins/plugins+/plugins64/plugins64+ folders? What about ffms2's "include" folder?



I have tried moving the files to a number locations and continue to get the error when I run the above script as an .avs file through MPC-HC, so I am obviously failing at something that should be obvious.

[Midzuki]

There is a *plugins* folder in the Avisynth install directory, BUT I highly recommend that you do not use it.

So, you should create an independent directory for your AVS plugins, and then load them manually, that is, only when you really need them.

Example:
LoadPlugin("B:\AVSplugins\FFMS2\ffms2.dll")

or
LoadCPlugin("B:\AVSplugins\FFMS2\c\ffms2.dll")

[raffriff42]

I agree with Midzuki, although others may prefer autoloading.

When you extract the files from the zip (https://github.com/FFMS/ffms2/releases), you will have 2 subfolders: "x86" and "x64." The others don't matter right now.

If you prefer autoloading, you need to determine the autoload folder. I use regedit, but I hope someone knows a better way:
x86 plugin folder = HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Avisynth\PluginDir2_5
x64 plugin folder = HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth\PluginDir2_5
Copy the x86 and x64 files to the registered locations.

If you prefer manual loading, put the files anywhere you like (keep the x86 and x64 folder separate though)

I was under the impression that you had to put ffmsindex.exe in the autoload folder, or maybe in the same folder with ffms2.dll, but after some investigation I find that this file is not needed at all for use in AviSynth. (I just spent way too much time confirming that statement, by deleting all my copies of ffmsindex.exe. The indexing function 'ffindex' is incorporated in the DLL. The index is generated just fine without ffmsindex.exe present on the computer.)

ffms2.lib is also not needed for Avisynth (it's for developers)

[Groucho2004]

If you prefer autoloading, you need to determine the autoload folder. I use regedit, but I hope someone knows a better way
AVSMeter (https://forum.doom9.org/showthread.php?t=174797) -avsinfo :)

[qyot27]

I was under the impression that you had to put ffmsindex.exe in the autoload folder, or maybe in the same folder with ffms2.dll, but after some investigation I find that this file is not needed at all for use in AviSynth. (I just spent way too much time confirming that statement, by deleting all my copies of ffmsindex.exe. The indexing function 'ffindex' is incorporated in the DLL. The index is generated just fine without ffmsindex.exe present on the computer.)
The only reason it might be better put in the autoload folder is that said autoload folder may already be on the system %PATH%, and at least there, it's kept in the same spot as the plugin itself and FFMS2.avsi, rather than lost somewhere in C:\Windows or system32/syswow64 like many people automatically throw stuff that goes on the %PATH%.

It's simply more convenient to use ffmsindex.exe, because having ffms2.dll index when the script opens still occasionally gets complaints about 'it's doing nothing' or 'it's frozen', because indexing on script open doesn't visibly do anything, aside from create a *.ffindex file in the directory. That doesn't happen with ffmsindex, since when you use it, the only thing you're doing is indexing, you know that's what it's doing, and it gives you a progress meter to show how much has been indexed. And then opening the script with said index is instantaneous (within the bounds of what it takes to actually decode/render the target media).

[VideoBeginner]

<sigh> Apparently, Avisysnth hates me.

I placed the plugin files in their own directory and added the load script at the top of the existing lines of code. When trying to load the 64 bit DLL, I get the same "no function" error message as before. If I try loading the 32 bit DLL, I get: "Cannot load 32 bit DLL in 64 bit Avisynth:" (I did not even realize I had installed the 64 bit version. I suppose my next step is to go back and install the 32 bit version of Avisysnth and try again.)


How could something that I thought would be so simple turn into such a pain?

[sneaker_ger]

With what software are you trying to open the script? If it's a 64 bit software (e.g. MPC-HC 64, ffmpeg 64, VirtualDub 64 ...) it will automatically try to load 64 bit AviSynth (and vice versa).

[qyot27]

This might be a bug with very recent versions of AviSynth+. I experienced something similar in testing the 64-bit GCC build, but since I don't have a 64-bit Windows install (only 64-bit Wine, which is more cumbersome to do accurate testing with), I couldn't do a thorough write-up.

The short version: the 64-bit builds may be failing to autoload any plugins or .avsi, and may even explicitly ignore Program Files locations even if you explicitly LoadPlugin from them. Try putting the .dll in the same folder as the video file and LoadPlugin it locally. It should work then.

[hello_hello]

It's simply more convenient to use ffmsindex.exe, because having ffms2.dll index when the script opens still occasionally gets complaints about 'it's doing nothing' or 'it's frozen', because indexing on script open doesn't visibly do anything, aside from create a *.ffindex file in the directory. That doesn't happen with ffmsindex, since when you use it, the only thing you're doing is indexing, you know that's what it's doing, and it gives you a progress meter to show how much has been indexed. And then opening the script with said index is instantaneous (within the bounds of what it takes to actually decode/render the target media).

I smell an opportunity for an argument. ;)
FFIndex() is an Avisynth function, incorporated into ffms2.dll
ffmsindex is an exe for accessing the FFIndex() function via the command line (the way I understand it). If ffms2.dll isn't in the same folder as ffmsindex.exe, it'll complain. On the other hand, FFIndex() doesn't need ffmsindex.exe to index.

I don't know if the same applies to ffmsindex.exe, but one advantage of indexing automatically (or with FFIndex) is the ability to avoid indexing the audio if you don't need it, which speeds up the indexing of large files.

One disadvantage of letting the indexing happen automatically, is ffms2.dll only indexes the video streams by default (I'm pretty sure). As a result it'll index the video, then if the script contains audio, it has to run the indexing again, so if you want the audio indexed you should open it with ffaudiosource in a script before opening the video with ffvideosource.

Or even better, don't use ffvideosource/ffvideosource. and use FFmpegSource2 or FFMS2 instead. I'm pretty sure audio is disabled by default, but if you enable it before opening the script (Atrack=-1 or higher), FFmpegSource2() or FFMS2() will index the video and audio at the same time with FFIndex().

At least that's how it worked when FFmpegSource2/FFMS2 were separate functions in a script. I assume nothing changed when they were incorporated into ffms2.dll, but I don't know for sure.

Does ffmsindex.exe have the same options as FFIndex()?
I've never used it and the help file barely makes mention of it, so I'm curious.....

[hello_hello]

I agree with Midzuki, although others may prefer autoloading.

Out of curiosity, what's the argument for not putting plugins in the auto-loading folder?

I have 372 files in mine. Dlls, text and html help files and scripts. It all works fine, although if ever I do have a problem the first thing I do is rename the plugins folder so they won't auto-load and manually load the required plugins while fault-finding. To date, disabling autoloading hasn't fixed any problems, which logically means it hasn't caused any either. [touch wood] :)

[raffriff42]

I like loading manually because those Import and LoadPlugin statements document the dependencies right there in the script. Since my 3rd party scripts & plugins are organized in a big folder tree by author, project, version, and x86/64, all that information is in the script as well, embedded in the load/import paths. I know exactly what I used, and what worked, when I return to a script five years later.

[qyot27]

I smell an opportunity for an argument. ;)
FFIndex() is an Avisynth function, incorporated into ffms2.dll
ffmsindex is an exe for accessing the FFIndex() function via the command line (the way I understand it). If ffms2.dll isn't in the same folder as ffmsindex.exe, it'll complain. On the other hand, FFIndex() doesn't need ffmsindex.exe to index.

I don't know if the same applies to ffmsindex.exe, but one advantage of indexing automatically (or with FFIndex) is the ability to avoid indexing the audio if you don't need it, which speeds up the indexing of large files.

One disadvantage of letting the indexing happen automatically, is ffms2.dll only indexes the video streams by default (I'm pretty sure). As a result it'll index the video, then if the script contains audio, it has to run the indexing again, so if you want the audio indexed you should open it with ffaudiosource in a script before opening the video with ffvideosource.

Or even better, don't use ffvideosource/ffvideosource. and use FFmpegSource2 or FFMS2 instead. I'm pretty sure audio is disabled by default, but if you enable it before opening the script (Atrack=-1 or higher), FFmpegSource2() or FFMS2() will index the video and audio at the same time with FFIndex().

At least that's how it worked when FFmpegSource2/FFMS2 were separate functions in a script. I assume nothing changed when they were incorporated into ffms2.dll, but I don't know for sure.

Does ffmsindex.exe have the same options as FFIndex()?
I've never used it and the help file barely makes mention of it, so I'm curious.....
The only thing I mentioned was that it was more convenient because it doesn't cause the script to take a long time to start playing the first time opening it, and it gives you a progress meter to indicate how far along in the indexing process it is.

But anyway,
Yes, ffmsindex.exe is dynamically linked against ffms2.dll. They both need to be on the %PATH% or at least in the same directory. With the assumption that your plugins folder is on the %PATH%, this eliminates the need to go spelunking in the Windows system folders.

ffmsindex indexes audio if you tell it to (with the -t option), otherwise it only indexes video.

And yes, ffmsindex exposes all options FFIndex does (custom cachefile name, audio indexing mask, audio decoder error level, overwriting the index), plus one from FFVideoSource (timecodes), an equivalent to the FFSetLogLevel() function, and one that doesn't seem to have a direct analogue in existing plugin functions (outputting keyframe positions to a text file).
FFmpegSource2 indexing app
Usage: ffmsindex [options] inputfile [outputfile]
If no output filename is specified, inputfile.ffindex will be used.

Options:
-f Force overwriting of existing index file, if any (default: no)
-v Set FFmpeg verbosity level. Can be repeated for more verbosity. (default: no messages printed)
-p Disable progress reporting. (default: progress reporting on)
-c Write timecodes for all video tracks to outputfile_track00.tc.txt (default: no)
-k Write keyframes for all video tracks to outputfile_track00.kf.txt (default: no)
-t N Set the audio indexing mask to N (-1 means index all tracks, 0 means index none, default: 0)
-s N Set audio decoding error handling. See the documentation for details. (default: 0)

[VideoBeginner]

Woa... slow down guys. I am confused enough dealing with what is apparently a not-so-common problem (or extreme user error on my part... yea... let's go with that one) on top of not knowing much about what I am doing. Alternate discussions are only going to make things worse! :scared: LOL


With what software are you trying to open the script? If it's a 64 bit software (e.g. MPC-HC 64, ffmpeg 64, VirtualDub 64 ...) it will automatically try to load 64 bit AviSynth (and vice versa).
MPC-HC x64... just because it seemed the fastest way to test and see if the plugin is loading. In the end, all that I want to use is Avisynth in a command line to quickly adjust a collection of only 21 files. Everything else that I need to do to the files after that I can do on my own in about 10 minutes.

[sneaker_ger]

This might be a bug with very recent versions of AviSynth+. I experienced something similar in testing the 64-bit GCC build, but since I don't have a 64-bit Windows install (only 64-bit Wine, which is more cumbersome to do accurate testing with), I couldn't do a thorough write-up.

The short version: the 64-bit builds may be failing to autoload any plugins or .avsi, and may even explicitly ignore Program Files locations even if you explicitly LoadPlugin from them. Try putting the .dll in the same folder as the video file and LoadPlugin it locally. It should work then.
FWIW: auto-loading 64 bit ffms works fine for me. This includes the ffms2.avsi helper. (AviSynth+ r2580-MT, both ffms2-2.23.1-msvc and ffms2000-test8)

MPC-HC x64
Ok, try this:
Copy "ffms2.dll" from "x86" folder to "plugins" folder. Copy "ffms2.dll" from "x64" folder to "plugins64" folder.

Try again to open the script with MPC-HC 64 bit. If this doesn't work try to open the script in MPC-HC 32 bit.

[Groucho2004]

If you're auto-loading, the best way to check if everything is in the right place and has the correct bitness is to use AVSMeter with the switch "-avsinfo".

If you're loading plugins explicitly via "LoadPlugin()" you can also use AVSMeter to specify the directory where your plugins are located by combining "-avsinfo" with "-c".

[Midzuki]

Out of curiosity, what's the argument for not putting plugins in the auto-loading folder?

Because conflicts MAY happen when Avisynth loads *tens* of plugins at the same time. You see, Windows is not perfect, Avisynth is not perfect, plugins may have their own bugs and design flaws... In other words, better safe than sorry ^_^

In the extinct Doom10 forum there was a long thread about (if I'm not mistaken) a MEncoder failure that happened when the OP tried to open an AVS file with it. In the end, he found that the problem happened because the default plugins folder contained a deprecated DLL which was Avisynth-related but was not a plugin :-/

[VideoBeginner]

Ok, try this:
Copy "ffms2.dll" from "x86" folder to "plugins" folder. Copy "ffms2.dll" from "x64" folder to "plugins64" folder.

Try again to open the script with MPC-HC 64 bit. If this doesn't work try to open the script in MPC-HC 32 bit.
Same errors.

Forget it. It obviously hates me and refuses to cooperate when no other user is having this problem. It looks like I will have to find another method to solve my original problem/question (which hasn't been easy to do thus far.)

[raffriff42]

Sorry you're having trouble. Try a GUI that installs FFMS2 for you, such as StaxRip (http://staxrip.readthedocs.io/tools.html).

[qyot27]

Are the plugin autoload folders on the system %PATH%? This was never answered, and yes, it can cause errors in some programs if the autoload folders aren't.

MPC-HC, if you're using LAV Filters to decode, uses libavformat's AviSynth demuxer. libavformat uses its own dlopen routines on Windows to deal with loading DLLs, and part of that is the requirement that any loaded DLLs, even chainloaded ones (like AviSynth plugins) have to all be visible on the %PATH% (in which case, the current directory is included if you explicitly use LoadPlugin in the script). If you tried using FFmpeg - or FFplay, since we're talking about previewing the script here - on the command line, the very same thing is likely to happen unless the plugins are on the %PATH% too.

[manolito]

I think that qyot27 is right on the money with his suspicion...

The "PATH" requirement whenever FFmpeg interfaces with AviSynth was introduced in mid 2016 just before v. 3.1.2. The requirement is even worse than qyot27 explains it because it does not only affect autoloaded plugins. Whenever some software which relies on FFmpeg loads a plugin explicitly from just any folder then this folder must be in the environment path as soon as AviSynth is involved (e.g. use an AVS script as the source for FFmpeg).

This silly "improvement" has broken some third party software like AVStoDVD for me, and without qyot's help I would probably not have found the reason. If the AVStoDVD Lib folder is not in the path then FFmpeg will just crap out without any visible error message.


Cheers
manolito

[VideoBeginner]

Sorry you're having trouble. Try a GUI that installs FFMS2 for you, such as StaxRip (http://staxrip.readthedocs.io/tools.html).
I am not sure what that is at the moment, but I will look into it, thanks.

Are the plugin autoload folders on the system %PATH%? This was never answered, and yes, it can cause errors in some programs if the autoload folders aren't.
Sorry if I missed this one.

C:\ffmpeg\
C:\Program Files (x86)\AviSynth+\plugins\
C:\Program Files (x86)\AviSynth+\plugins+\
C:\Program Files (x86)\AviSynth+\plugins64\
C:\Program Files (x86)\AviSynth+\plugins64+\ (oh look... a downhill slope, just like where I fell I am going at this point! :p)
...also
C:\Program Files (x86)\~ Video Tools\AviSynth\plugins\

MPC-HC, if you're using LAV Filters to decode...
Going over my head, but I will take a guess at what you are asking for:

In MPC-HC I went to "Options | Internal Features | Audio Decoder" and in the bottom corner it says "LAV Audio Decoder 0.70.2.1-git"

... but I feel like that may be going beyond the scope of my original problem. It is not about making sure that it runs in MPC-HC. I was only running the script there to test it because it was a bit quicker than going to Command Prompt since running the .avs file in CMD returned the same errors as running in MPC-HC.

[sneaker_ger]

But you are still getting the "There is no function named 'audiosource'" error or a different one?

[StainlessS]

C:\Program Files (x86)\AviSynth+\plugins\
C:\Program Files (x86)\AviSynth+\plugins+\
C:\Program Files (x86)\AviSynth+\plugins64\
C:\Program Files (x86)\AviSynth+\plugins64+\ (oh look... a downhill slope, just like where I fell I am going at this point! :p)
...also
C:\Program Files (x86)\~ Video Tools\AviSynth\plugins\


Please clarify:
The above paths are in your environment %PATH%, yes ? (run CMD, enter the text "path" [without quotes]).
[EDIT: And match what is actually installed.]
What is in the registry ? (run REGEDIT, go to "HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth")
You really need 3 versions of avisynth ?

Think I would uninstall all 3 and then get them working one at a time.

[raffriff42]

This thread is way longer than it should have been for such a simple question.
VideoBeginner, you are being too vague. Please give better information.

Post a MediaInfo report on your source video.
(text mode preferred - see here (https://daxcloud.zendesk.com/hc/en-us/articles/207143307-Using-MediaInfo-to-inspect-the-media-properties-of-a-video-or-audio-file), bottom of page)

Post your script. :script:

Quote any AviSynth error messages exactly.
(e.g. in VirtualDub/VdubFM, go to View menu, Log, right-click, Copy to clipboard).

[qyot27]

It just dawned on me that maybe one other possibility is that, if the normal C++ version of FFMS2 is being used here, OP doesn't have the correct version of the 64-bit MSVC redist installed. That would preclude ffms2.dll from working at all, AviSynth+ wouldn't be able to launch it as a plugin, and the 'no such function' messages could be the result.

[Groucho2004]

It just dawned on me that maybe one other possibility is that, if the normal C++ version of FFMS2 is being used here, OP doesn't have the correct version of the 64-bit MSVC redist installed. That would preclude ffms2.dll from working at all, AviSynth+ wouldn't be able to launch it as a plugin, and the 'no such function' messages could be the result.Exactly my thoughts.
I provided a way to check this above but the OP doesn't seem to be interested, or he possibly solved the problem already.

[raffriff42]

Out of curiosity, what's the argument for not putting plugins in the auto-loading folder?
Here's another autoloading issue I had forgotten about -- "rogue" plugins (used to get 'em with VirtualDub as well; stopped autoloading about ten years ago)So your theory is basically that there are incompatible plugins in my folder and they trigger the error, even if the one I'm actually requesting is not responsible for the error? (since I was able to load it with loadPlugin after disabling autoload)
Yes.

[hello_hello]

Here's another autoloading issue I had forgotten about -- "rogue" plugins (used to get 'em with VirtualDub as well; stopped autoloading about ten years ago)

I recall a problem regarding one C plugin (ffavisynth.dll) and I checked the avsi script that came with the old C plugin version of ffms2 and found it loads the dll the same way. The script is intended to live in the autoloading folder along with ffms2.dll

LoadCPlugin("ffms2.dll")

For ffavisynth.dll, I recall the plugin would load when opening scripts with some software, but not others (MPC-HC and VirtualDubMod being two examples of it not loading).

The solution was to specify the full path, and I think I may have needed to use Load_Stdcall_Plugin instead of LoadCPlugin. ie

Load_Stdcall_Plugin("C:\Program Files\AviSynth\Plugins\ffms2.dll")

I don't know if the OP is using the C version of ffms2 or if the above has anything to do with his problem, but these days I auto-load C plugins the same way, only I keep the dlls in a separate folder.

I'll confess I still don't see using the autoloading folder as problematic as such. The first thing I do if I have a problem, which doesn't happen often, is to rename the auto-loading folder so nothing auto-loads, then I manually load just the required plugins. If it magically fixed an issue I'd find the problem plugin and move it.

Well.... I have discovered a a few misbehaving plugins in the past, such as old Avisynth 2 plugins requiring LoadPluginEx2.dll, so I quickly learned to load them manually, and if I was to use a VirtualDub plugin I'd do the same, but it seems overkill to let a few bad (and ancient) apples spoil the bunch.

Plus... a fair while ago I renamed all the dlls to include their version numbers to make it easy to see which versions I'm using. I can swap them out in the auto-loading folder, but if I was manually loading them I'd have to change the dll names in scripts.

[qyot27]

Load_Stdcall_Plugin is merely an alias of LoadCPlugin (http://avisynth.nl/index.php/LoadCPlugin#LoadCPlugin). It's not any different, just more awkward to type. Either it was the 'first' name used for that plugin type, or it was necessary to use aliases back when it was still very common for users to have the separate avisynth_c.dll loader plugin floating around causing problems despite that very same C plugin loader (or an evolution thereof) was added to the AviSynth 2.5 core.

Not that it matters for AviSynth+, since C plugin support is integrated even more tightly into the core - LoadPlugin handles everything now (making LoadCPlugin itself just an alias of LoadPlugin (https://github.com/AviSynth/AviSynthPlus/blob/2d3cb6c011f520fc9433d6bff61a6d697cb09ecb/avs_core/core/PluginManager.cpp#L759)), and C plugins aren't kept from autoloading like they used to be.

[hello_hello]

When I said I might have needed to use Load_Stdcall_Plugin, I could have made it up. Or remembered incorrectly.

ffms2.avsi uses LoadCPlugin for loading the C version. I suspect when I was trying to solve the problem, a forum member advised me to switch to Load_Stdcall_Plugin, and at the time I didn't know any different, so I changed methods as suggested. Or maybe I just made all that up too. It was fair while ago. :)

[StainlessS]

could have made it up. Or remembered incorrectly.


Yep probably, or maybe this:-

http://forum.doom9.org/showthread.php?p=1641795#post1641795

AutoLoadPlugs.avsi

Update on previous posted script,
Can load, CPP dll, C v2.5 dll, C v2.0 dll, Import AVSI, Import AVS, all from same directory.

NOTE, As Script may Load Kevin Atkinson Avisynth_c.dll, you MUST use Aviynth v2.5+ builtin Alias for LoadCPlugin, (EDIT: Thereafter)
ie Load_Stdcall_Plugin() instead, as Avisynth_c.dll overrides LoadCPlugin() function for v2.0 dll loads.



if(Bingo==False && RT_BitTST(Flgs,1)) {
try{
# Alias for BUILT-IN v2.5 LoadCPlugin(which may have been overridden by Avisynth_c.dll).
# Once Avisynth_c.dll loaded, MUST use Load_Stdcall_Plugin, LoadCPlugin name hijacked by Avisynth_c.dll.
Load_Stdcall_Plugin(S)
(DEBUG) ? RT_Debug(myName,"v2.5 C Plugin '"+S+"' SUCCESS",false) : NOP
Bingo=True
CV25_DLL_SUCCESS=CV25_DLL_SUCCESS+1
} catch (err_msg) {
(DEBUG && VERBOSE) ? RT_Debug(myName,S+" NOT LOADED as v2.5 C dll",False) : NOP
(DEBUG && VERBOSE) ? RT_Debug(myName,"System Message= *** "+RT_TxtGetLine(err_msg,0)+" ***",False) : NOP
}
}
if(Bingo==False && RT_BitTST(Flgs,2)) {
try{
LoadCPlugin(S) # Using Kevin Atkinson Avisynth_c.dll, NOTE now overrides built in LoadCPlugin().
(DEBUG) ? RT_Debug(myName,"v2.0 C Plugin '"+S+"' SUCCESS",false) : NOP
Bingo=True
CV2_DLL_SUCCESS=CV2_DLL_SUCCESS+1
} catch (err_msg) {
(DEBUG && VERBOSE) ? RT_Debug(myName,S+" NOT LOADED as v2.0 C dll",False) : NOP
(DEBUG && VERBOSE) ? RT_Debug(myName,"System Message= *** "+RT_TxtGetLine(err_msg,0)+" ***",False) : NOP
}
}
(DEBUG && !Bingo) ? RT_Debug(myName,"DLL "+S+" *** FAILED ***",False) : NOP
DLL_FAILED=(!Bingo)?DLL_FAILED+1:DLL_FAILED
Done = (Bingo) ? Done + 1 : Done
(DEBUG)?RT_Debug(myName,false) : NOP
}


Dont know if Avs+ loads v2.0 C plugs. [EDIT: On 2nd thoughts, I dont think avs+ can load v2.0 C plugs]

[RRD]

The latest release (2.40 2020-08-22) (https://github.com/FFMS/ffms2/releases) still contains the FFMS2.avsi file, while the changelog of version 2.22 (2015-10-12) says "avisynth: Moved all source functions in ffms2.avsi into the actual plugin (Myrsloik)".

Is this file still necessary? If yes, in which folder should it be located when using 64-bit AviSynth+?

[kedautinh12]

Can you try another mod, it's more stable
https://forum.doom9.org/showpost.php?p=1928993&postcount=2655