| Message ID | 20220415080953.18753-1-nil-admirari@mailo.com |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel,v9,1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
| andriy/make_fate_aarch64_jetson | fail | Make fate failed |
| andriy/make_aarch64_jetson | warning | New warnings during build |
| andriy/make_armv7_RPi4 | success | Make finished |
| andriy/make_fate_armv7_RPi4 | success | Make fate finished |
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
> 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. Done: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295572.html. > 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? Yes, it is primarily due to AviSynth. From https://github.com/staxrip/staxrip/wiki/AviSynth-Unicode-support-on-Windows-10-1903: > All AviSynth apps used by StaxRip have a UTF-8 manifest to enable full Unicode support for AviSynth on Windows 10 1903 or higher: > ... > ffmpeg.exe (Patman Mod) > ... > On Windows 10 1903 or higher all these apps expect AviSynth scripts to be UTF-8 encoded, ANSI encoded scripts don't work.
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>