[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