## [Feature Request] Support architecture-specific FFmpeg DLL subdirectory for multi-arch VirtualDub2 build

[rmmaniac]

Background

Currently, avlib_vdplugin requires FFmpeg 8.0 DLLs to be placed in the main VirtualDub2\ folder [[1]].
However, some VirtualDub2 distributions (e.g., vdfiltermod builds) use a shared root directory for both 32-bit and 64-bit versions, with separate plugins32\ and plugins64\ subfolders.

Problem

When using such multi-arch builds:

• x86 and x64 FFmpeg DLLs cannot coexist in the same root folder (naming conflicts)
• Users must manually manage DLLs or maintain separate VirtualDub2 installations

Proposed Solution

Allow the plugin to load FFmpeg DLLs from an architecture-specific subdirectory:
VirtualDub2/
├── plugins32/
│ ├── avlib-1.vdplugin
│ └── dll/ ← new: place x86 FFmpeg DLLs here
│ ├── avcodec-62.dll
│ └── ...
├── plugins64/
│ ├── avlib-1.vdplugin
│ └── dll/ ← new: place x64 FFmpeg DLLs here
│ ├── avcodec-62.dll
│ └── ...

Technical Approach (suggestion)

1. Use GetModuleFileNameW(NULL, ...) or GetModuleHandleEx to get the plugin's own path
2. Construct candidate path: <plugin_directory>\dll\*.dll
3. Attempt to load FFmpeg DLLs from this subdirectory first
4. Fallback to current behavior (root VirtualDub2 folder) for backward compatibility

Benefits

• ✅ Better compatibility with multi-arch VirtualDub2 distributions
• ✅ Cleaner directory organization
• ✅ No breaking change for existing users (fallback mechanism)

Questions for maintainer

1. Would you accept such a change if implemented?
2. Do you prefer a compile-time flag or runtime detection for this behavior?
3. Any coding style or testing requirements I should follow?

Thank you for maintaining this useful plugin! 🙏

[v0lt]

• x86 and x64 FFmpeg DLLs cannot coexist in the same root folder (naming conflicts)

Don't mix x64 and win32 binaries.

I won't be making it possible to place executables and plugins for different architectures in the same folder.