On 18 Jul 2024, at 16:21, Ramiro Polla wrote:
> On Thu, Jul 18, 2024 at 3:41 PM Stefan Oltmanns via ffmpeg-devel
> <ffmpeg-devel@ffmpeg.org> wrote:
>> Am 18.07.24 um 15:04 schrieb Ramiro Polla:
>>>>>> [...]
>>>>>>
>>>>>> +static VSScriptLibrary vs_script_library;
>>>>>
>>>>> Does vs_script_library have to be a global?
>>>>>
>>>>
>>>> I think it has to: ffmpeg allows multiple input files, in case you open
>>>> two VapourSynth files you want to load the Library only once.
>>>
>>> It should be possible to dlopen()/LoadLibrary() multiple times, and
>>> the library only gets really unloaded after the last call to
>>> dlclose()/FreeLibrary(). In that case you could move that struct to
>>> the context. If it's unavoidable to keep the global, at least add some
>>> locks to access it.
>>
>> Yes, that should be possible. I did a quick search at it seems that
>> dlopen()/LoadLibrary() is smart and will not open the same library
>> multiple times, but return the same pointer.
>> As dlclose won't be used anymore when removing the atexit handler, that
>> is not an issue at all.
>
> dlclose() will have to be called at some point (i.e.: in read_close).
>
>>>> This is exactly how it's done for AviSynth.
>>>
>>> Perhaps AviSynth is not the best example to follow :)
>>>
>>>>>> +
>>>>>> +static int vs_atexit_called = 0;
>>>>>> +
>>>>>> +static av_cold void vs_atexit_handler(void);
>>>>>> +
>>>>>> +#ifdef _WIN32
>>>>>> +static av_cold char* get_vs_script_dll_name(void) {
>>>>>> + LONG r;
>>>>>> + WCHAR vss_path[512];
>>>>>> + char *vss_path_utf8;
>>>>>> + DWORD buf_size = sizeof(vss_path) - 2;
>>>>>> + r = RegGetValueW(HKEY_CURRENT_USER, L"SOFTWARE\\VapourSynth",
>>>>>> + L"VSScriptDLL", RRF_RT_REG_SZ, NULL,
>>>>>> + &vss_path, &buf_size);
>>>>>> + if (r == ERROR_SUCCESS && wchartoutf8(vss_path, &vss_path_utf8)
>>>>>> == 0)
>>>>>> + return vss_path_utf8;
>>>>>> + r = RegGetValueW(HKEY_LOCAL_MACHINE, L"SOFTWARE\\VapourSynth",
>>>>>> + L"VSScriptDLL", RRF_RT_REG_SZ, NULL,
>>>>>> + &vss_path, &buf_size);
>>>>>> + if (r == ERROR_SUCCESS && wchartoutf8(vss_path, &vss_path_utf8)
>>>>>> == 0)
>>>>>> + return vss_path_utf8;
>>>>>> + if (wchartoutf8(L"VSScript.dll", &vss_path_utf8) == 0)
>>>>>> + return vss_path_utf8;
>>>>>> + return 0;
>>>>>> +}
>>>>>> +#endif
>>>>>
>>>>> Don't fetch the path on the registry on Windows. The user should set the
>>>>> path outside of FFmpeg.
>>>>
>>>> How exactly should the user do that? Additional option to ffmpeg?
>>>
>>> By making sure the libraries are accessible in the PATH environment
>>> variable. For example by adding the VapourSynth path to the PATH
>>> environment variable, or overriding PATH on the call to FFmpeg on a
>>> script. Either way that's outside the scope of FFmpeg.
>>
>> Well, the DLL directory is added to PATH by the VapourSynth installer,
>> but for safety reasons ffmpeg explictly tells the LoadLibrary function
>> to only search the application directory and system32, quote from
>> w32dlfcn.h:
>>
>>> /**
>>> * Safe function used to open dynamic libs. This attempts to improve
>>> program security
>>> * by removing the current directory from the dll search path. Only dll's
>>> found in the
>>> * executable or system directory are allowed to be loaded.
>>> * @param name The dynamic lib name.
>>> * @return A handle to the opened lib.
>>> */
>> So ffmpeg prevents that solution on purpose. Or should that behavior be
>> changed in the w32dlfcn.h?
>
> Oh, bummer. I would expect that overriding the PATH environment
> variable would work kind of like how LD_LIBRARY_PATH works on Linux. I
> don't know why that was changed. I don't really follow what goes on in
> Windowsland anymore. Does anyone else care to comment on this? Martin,
> maybe?
IIRC this is done to prevent DLL injection attacks
https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security
>
> Ramiro
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
