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"

https://i.imgur.com/YfSynG7.png

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]

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]

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]

That could prove awkward when using Avisynth Universal InstallerNot 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]

But would you not also need Path AddYes. Although there's probably a way to do this in the batch file "automatically".

[manolito]

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-improvises-post-office-wont-serve-without-face-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]

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.php?p=1699301#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... :devil:

[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.git;a=commit;h=85553b42f92457a581e13edbd3e2c2e6136931eb
Switching AviSynth to said dlopen implementation: https://git.videolan.org/?p=ffmpeg.git;a=commit;h=d6f85ec2700e40b3ec864d5ee405b7e257778e1f

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 (https://git.videolan.org/?p=ffmpeg.git;a=commit;h=f0c0ad4455e5f72edf175e81a06e52562cdd1ab2), 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-devel/2016-August/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 (https://support.microsoft.com/en-us/help/2533623/microsoft-security-advisory-insecure-library-loading-could-allow-remot)) was already fixed in the RTM of Windows 8.

[stax76]

@qyot27

Thanks for the clarification.

Even in Win 10 it seems to be necessary to put an avisynth.dll soft link next to ffmpeg in order to make ffmpeg use avisynth in portable mode.

I believe it's paranoid and even if things go wrong it's not their fault but rather the not particular secure default behavior of windows. I think there should be a switch/option to enable default search.

[qyot27]

Even in Win 10 it seems to be necessary to put an avisynth.dll soft link next to ffmpeg in order to make ffmpeg use avisynth in portable mode.
Like it said, 'Only dll's found in the executable or system directory are allowed to be loaded.'

If you're trying to access a library from an arbitrary point in the file system, that DLL must be in a system directory (read: on the $PATH).

If it's in some sort of self-contained package that isn't available system-wide, then it must be in the executable directory (read: sitting next to ffmpeg.exe, and the shell calling the program has to acknowledge that it is executable - cmd does without any special syntax, PowerShell and bash do not, and require the use of the directory anchor prefix¹ to fully allow it).

¹'./' on Unix-like systems, '.\' on PowerShell on Windows (as I'm sure PowerShell on *nix uses './', although I've never bothered to install PS on *nix). It's a pseudo-absolute path that states, 'yes, this executable is located here in relation to the current directory'. '.' is the current directory and the \ or / is the usual directory path separator. It's necessary as a short-hand for executing non-$PATH programs because it's quicker than giving a fully-spelled-out absolute path, but means exactly the same thing if you're in the same directory as the program you're trying to run.