[FFmpeg-devel] [PATCH v9 6/6] fftools: Use UTF-8 on Windows
Martin Storsjö
martin at martin.st
Wed Apr 20 14:49:26 EEST 2022
On Fri, 15 Apr 2022, Nil Admirari wrote:
> ---
> fftools/fftools.manifest | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fftools/fftools.manifest b/fftools/fftools.manifest
> index 30b7d8fe..d1ac1e4e 100644
> --- a/fftools/fftools.manifest
> +++ b/fftools/fftools.manifest
> @@ -3,8 +3,10 @@
> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
> <assemblyIdentity type="win32" name="FFmpeg" version="1.0.0.0"/>
> <application xmlns="urn:schemas-microsoft-com:asm.v3">
> - <windowsSettings xmlns:ws2016="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
> + <windowsSettings xmlns:ws2016="http://schemas.microsoft.com/SMI/2016/WindowsSettings"
> + xmlns:ws2019="http://schemas.microsoft.com/SMI/2019/WindowsSettings">
> <ws2016:longPathAware>true</ws2016:longPathAware>
> + <ws2019:activeCodePage>UTF-8</ws2019:activeCodePage>
> </windowsSettings>
> </application>
> </assembly>
> --
> 2.32.0
This needs a similar commit message as what I suggested for the previous
commit, explaining what it does, when, why, and clarifying that this is a
noop for older versions.
In particular, it'd be interesting to know why we actually need this; we
normally should be doing all the conversions between wchar_t and utf8
everywhere anyway, so the exact codepage used shouldn't really matter
much? I presume the main noticable benefit is that it improves the path
name compatibility with avisynth which is stuck on using CP_ACP pathnames?
// Martin
More information about the ffmpeg-devel
mailing list