Using Avisynth in FFmpeg ? (Unknown error occurred)

[wthreex]

I want to import avisynth in ffmpeg but it has error

ffmpeg -i test.avs -vcodec libx264 -preset ultrafast -crf 18 -acodec libopus -b:a 192k out.mkv

test.avs:

LoadPlugin("C:\Users\Downloads\Programs\MeGui\tools\ffms\ffms2.dll")

FFVideoSource("C:\Users\Downloads\Video\file.mkv")

Error : "test.avs: Unknown error occurred"



I had Avisynth 2.6 installed on my pc, But even i upgrade it to +3.6.0 still same error.

[Boulder]

Does the script open in Virtualdub? (Or any tool capable of opening avs scripts since you are using Linux)?

[wthreex]

No problem with Megui, I'm in Windows

[stax76]

Try the ffmpeg build in staxrip, it's from Patman and supports avisynth and vapoursynth input.

In staxrip there is an encoder dialog, at the bottom there is a dropdown menu where you can find a few useful command line features such as:

Execute Command Line
Show Command Line
Copy Command Line

Before using the features open a source file and if you can install Windows Terminal!

Another similar advanced GUI is Hybrid, GUIs can be useful for people that try to learn the console or look for builds, most dialogs in staxrip have a command line preview, the log file is very clean and list all command lines it executes.

staxrip has a Apps dialog that shows the version, the name who has built it, when it was built, which compiler was used etc. and it has download links, in the case of ffmpeg a link to Patmans MediaFire folder.

[wonkey_monkey]

Originally Posted by wthreex

No problem with Megui, I'm in Windows

Are you using the same architecture (x86 or x64) for both ffmpeg and Megui?

[wthreex]

Megui: Portable 2913 64-bit

Not sure about ffmpeg how do i found the x64 or x86 things on ffmpeg?

ffmpeg version N-89940-gb1af0e23a3 - built with gcc 7.2.0 (GCC)

[poisondeathray]

(c) 2000-2018 suggests it's an older ffmpeg binary - try upgrading to a newer version

[manolito]

Starting with version 3.1.2 the FFmpeg AVS interface has changed. To use an AVS script as the input for FFmpeg it is necessary to include the folder from which the AVS script loads plugins in your "PATH" variable (even if this is your "AviSynth\Plugins" autoload folder).

[StainlessS]

Originally Posted by manolito

Starting with version 3.1.2 the FFmpeg AVS interface has changed. To use an AVS script as the input for FFmpeg it is necessary to include the folder from which the AVS script loads plugins in your "PATH" variable (even if this is your "AviSynth\Plugins" autoload folder).

That could prove awkward when using Avisynth Universal Installer. [if you have to change path whenever you change avs version]

EDIT: What if you load some plugins from auto Plugins directory, and other plugins from other user directories, all gotta be in path ?

[Groucho2004]

Originally Posted by StainlessS

That could prove awkward when using Avisynth Universal Installer

Not necessarily. You can customise auto-load directory/directories in the batch file.

[StainlessS]

But would you not also need Path Add (or whatever the command is)

EDIT: And where manual load loading plugins in script then also somehow need do it there as well.

[Groucho2004]

Originally Posted by StainlessS

But would you not also need Path Add

Yes. Although there's probably a way to do this in the batch file "automatically".

[manolito]

Originally Posted by StainlessS

EDIT: What if you load some plugins from auto Plugins directory, and other plugins from other user directories, all gotta be in path ?

Yes, they all gotta be in the path...

I always try to establish upgrade paths for the AVStoDVD helper tools, and FFmpeg really gave me a headache when they changed their AVS interface.

AVStoDVD tries to be "self-sufficient", it loads all AVS plugins it needs explicitly from one of its own subfolders. Including these subfolders in the path did not make the error message disappear, and the reason was that I had added some stuff to the AVS script where the required plugins were autoloaded. Only after also adding the autoload folder to the path FFmpeg was happy again..

[StainlessS]

Damn, thats a bummer, guess I'll stick with v3.1.2 or thereabouts for avs.

EDIT: Maybe a bit of improvisation is required.
Somebody else improvising:- https://metro.co.uk/video/woman-impr...-mask-2179162/

[stax76]

Starting with version 3.1.2 the FFmpeg AVS interface has changed. To use an AVS script as the input for FFmpeg it is necessary to include the folder from which the AVS script loads plugins in your "PATH" variable (even if this is your "AviSynth\Plugins" autoload folder).

If plugins are loaded manually with LoadPlugin then these folders don't need to be in path!

ffmpeg does not use standard DLL loading, it does not find avisynth.dll in portable mode, standard DLL loading would find it when it's in path, I have to fake it with a soft link, staxrip has a dozen avisynth and vapoursynth clients included and ffmpeg is the only one paranoid enough to block default DLL loading...

[manolito]

Originally Posted by stax76

If plugins are loaded manually with LoadPlugin then these folders don't need to be in path!

You are dead wrong on this. How can you make such a statement without having tested it?

AVStoDVD has a "Lib" subfolder where the AviSynth plugins and the "A2DSource.avsi" are located. Here is the relevant part from this AVSI:

# Following AviSynth plugins are required in the same folder:
# ffms2.dll more info @ https://github.com/ffms/ffms2
# avss_26.dll more info @ https://forum.doom9.org/showthread.p...01#post1699301
# GetSystemEnv.dll more info @ http://avisynth.org/stickboy
# NicAudio.dll more info @ http://nicaudio.codeplex.com


global OPT_AllowFloatAudio = True

LoadCPlugin("ffms2.dll")
LoadPlugin("avss_26.dll")
LoadPlugin("GetSystemEnv.dll")
LoadPlugin("NicAudio.dll")

The plugins are loaded explicitly, the full path is not required because this "Lib" folder is the active folder when the AVSI is called.

This works fine with older FFmpeg versions, but using a current version will crash FFmpeg. The only way to prevent this crash is to add the "AVStoDVD\Lib" folder to the Path environment variable (or go back to an older FFmpeg version).


So please before you make such a false statement the next time, take the time to test it yourself...

[manolito]

The Windows convention is like this:

If you call a file in the currently active folder then it is not necessary to specify the absolute path. Just specifying the file name is all which is required in this case.

If the active folder is elsewhere then the full absolute path is required to call a file.

If the folder where the requested file is stored is contained in the "Path" variable then it is never required to specify the full path to the file. The file name is all which is needed.

The FFmpeg devs decided to break this convention a while ago. Even if the "LoadPlugin" call contains the full path of the plugin, the plugin will not load and you will get an error message unless the folder where the plugin is stored is part of the "Path" environment variable.

I really hate the FFmpeg devs for making such a decision. But like it or not, this is the current state of things...

[stax76]

If you call a file in the currently active folder then it is not necessary to specify the absolute path. Just specifying the file name is all which is required in this case.

I think DLL loading is a complete different topic than relative paths for any type of file. I don't know why the ffmpeg devs decided to block default DLL loading, security sure but it's a pain for a lot of people, if it doesn't exist then they probably should make a statement why this decision was made.

[manolito]

This whole thing with FFmpeg suddenly breaking the loading of plugins happened in 2016, so I rechecked it today.

WinXP SP3 32-bit
Classic AVS 2.6.1 Alpha
The latest XP compatible build of FFmpeg by Reino
An older Sherpya XP compatible build from 2015

Case one:
All plugins located in the autoload folder, folder is not in the path.

I have to mention that I have a few C-Plugins in the autoload folder which I autoload with the help of a separate AVSI which has a LoadCPlugin command to load this C-Plugin (the ffms2 C-Plugin comes with such an AVSI).

Using the current FFmpeg version I get an error message that a C-Plugin cannot be loaded, then FFmpeg aborts. This happens even if none of the C-Plugins is used in the script.

No problem with the older FFmpeg version. To make it work with the new FFmpeg I need to include the autoload folder in the path.

The issue is probably not present under AVS+ because AVS+ can autoload C-Plugins.


Case two:
Autoload folder is empty, all plugins located in a separate folder where nothing gets autoloaded. This folder is not in the path.

Using LoadPlugin commands which specify the full path of the plugins works, also with the new FFmpeg version.

But making this plugin folder the active folder first and then use LoadPlugin commands specifying just the file name does not work with the new FFmpeg version. (This is how AVStoDVD does it so the new FFmpeg versions crash)

Again this method works with the old FFmpeg version, while the new version requires that the plugin folder is in the path.


And not to forget that this is solely an FFmpeg issue. Other encoders like HCenc are not affected, they work without the need to add plugin folders to the path for both usage cases.

[qyot27]

For specific reference, these two commits are what manolito is talking about:
Safe win32 dlopen implementation: https://git.videolan.org/?p=ffmpeg.g...e2c2e6136931eb
Switching AviSynth to said dlopen implementation: https://git.videolan.org/?p=ffmpeg.g...05b7e257778e1f

Right at the top of compat/w32dlfcn.h:

/**
28 * Safe function used to open dynamic libs. This attempts to improve program security
29 * by removing the current directory from the dll search path. Only dll's found in the
30 * executable or system directory are allowed to be loaded.
31 * @param name The dynamic lib name.
32 * @return A handle to the opened lib.
33 */

On another commit concerning the use of win32 dlopen, the actual reason for this is spelled out more clearly:

dlopen contains additional security to prevent dll hijacking compared to standard LoadLibrary.

And a more spelled-out version in the original patchset's mailing list thread:
https://ffmpeg.org/pipermail/ffmpeg-...st/198519.html


That said, this issue doesn't exist on Windows 10. The if blocks in w32dlfcn.h are #if _WIN32_WINNT < 0x0602 - i.e. anything below Windows 8. So XP (until the bcrypt switchover in 2018, anyway, as that was when FFmpeg dropped XP support), Vista, and 7 would be subject to that block, and 8, 8.1, and 10 are not, because the issue this was meant to address (KB2533623) was already fixed in the RTM of Windows 8.