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 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, 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]

Originally Posted by raffriff42

If you prefer autoloading, you need to determine the autoload folder. I use regedit, but I hope someone knows a better way

AVSMeter -avsinfo

[qyot27]

Originally Posted by raffriff42

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]

Originally Posted by qyot27

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]

Originally Posted by raffriff42

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]

Originally Posted by hello_hello

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! LOL

Originally Posted by 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).

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]

Originally Posted by 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.

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)

Originally Posted by VideoBeginner

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]

Originally Posted by hello_hello

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]

Originally Posted by sneaker_ger

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.

[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