| Message ID | 20220216150859.16844-5-nil-admirari@mailo.com |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel,v3,1/5] libavutil/wchar_filename.h: Add wchartoansi and utf8toansi | expand |
| Context | Check | Description |
|---|---|---|
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
| andriy/make_ppc | success | Make finished |
| andriy/make_fate_ppc | success | Make fate finished |
| andriy/make_aarch64_jetson | success | Make finished |
| andriy/make_fate_aarch64_jetson | success | Make fate finished |
| andriy/make_armv7_RPi4 | success | Make finished |
| andriy/make_fate_armv7_RPi4 | success | Make fate finished |
On Wed, 16 Feb 2022, nihil-admirari wrote: > --- > fftools/Makefile | 5 +++++ > fftools/long_paths_utf8.manifest | 12 ++++++++++++ > fftools/long_paths_utf8.rc | 3 +++ > 3 files changed, 20 insertions(+) > create mode 100644 fftools/long_paths_utf8.manifest > create mode 100644 fftools/long_paths_utf8.rc > > diff --git a/fftools/Makefile b/fftools/Makefile > index da42078..53438b6 100644 > --- a/fftools/Makefile > +++ b/fftools/Makefile > @@ -11,6 +11,11 @@ ALLAVPROGS_G = $(AVBASENAMES:%=%$(PROGSSUF)_g$(EXESUF)) > > OBJS-ffmpeg += fftools/ffmpeg_opt.o fftools/ffmpeg_filter.o fftools/ffmpeg_hw.o > > +# Windows resource files > +OBJS-ffmpeg-$(HAVE_GNU_WINDRES) += fftools/long_paths_utf8.o > +OBJS-ffplay-$(HAVE_GNU_WINDRES) += fftools/long_paths_utf8.o > +OBJS-ffprobe-$(HAVE_GNU_WINDRES) += fftools/long_paths_utf8.o > + > define DOFFTOOL > OBJS-$(1) += fftools/cmdutils.o fftools/$(1).o $(OBJS-$(1)-yes) > $(1)$(PROGSSUF)_g$(EXESUF): $$(OBJS-$(1)) > diff --git a/fftools/long_paths_utf8.manifest b/fftools/long_paths_utf8.manifest > new file mode 100644 > index 0000000..d1ac1e4 > --- /dev/null > +++ b/fftools/long_paths_utf8.manifest > @@ -0,0 +1,12 @@ > +<?xml version="1.0" encoding="UTF-8" standalone="yes"?> > + > +<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" > + xmlns:ws2019="http://schemas.microsoft.com/SMI/2019/WindowsSettings"> > + <ws2016:longPathAware>true</ws2016:longPathAware> > + <ws2019:activeCodePage>UTF-8</ws2019:activeCodePage> Generally UTF-8 codepage should not be needed, because unicode windows functions should be used everywhere, right? I'd perfer if you enable UTF8 codepage in a separate patch. And use simple fftools/fftools.manifest and fftools/manifest.rc as filenames, because later other things might be put there, not only utf8/longpath support. Thanks, Marton > + </windowsSettings> > + </application> > +</assembly> > diff --git a/fftools/long_paths_utf8.rc b/fftools/long_paths_utf8.rc > new file mode 100644 > index 0000000..f33de76 > --- /dev/null > +++ b/fftools/long_paths_utf8.rc > @@ -0,0 +1,3 @@ > +#include <windows.h> > + > +CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "long_paths_utf8.manifest" > -- > 2.32.0 > > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
> Generally UTF-8 codepage should not be needed, because unicode windows functions should be used everywhere, right? No. FFmpeg does not seem to use WinAPI ANSI functions explicitly, but it still uses ordinary stdlib functions (fopen etc.) instead of their wide equivalents. See https://ffmpeg.org/pipermail/ffmpeg-devel/2022-February/293169.html. > And use simple fftools/fftools.manifest and fftools/manifest.rc as filenames, because later other things might be put there, not only utf8/longpath support. Done in https://ffmpeg.org/pipermail/ffmpeg-devel/2022-February/293204.html. > I'd perfer if you enable UTF8 codepage in a separate patch. Done in https://ffmpeg.org/pipermail/ffmpeg-devel/2022-February/293207.html. Actually, UTF-8 codepage was already absent in the fourth version of this patch: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-February/293168.html. Microsoft documentation (https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests) says that manifests can be added to DLLs too, and does not say whether longPathAware and activeCodePage apply to the process or to individual DLLs loaded into it. Thus I wasn't sure whether ANSI-encoded strings passed to external APIs will be decoded correctly. Unfortunately, if it were that longPathAware is per DLL, manifests would need to be added to avformat.dll etc., so I decided to test how things actually work. It turned out that longPathAware and activeCodePage are applied per process, which means that all externally loaded libraries will have CP_ACP set to CP_UTF8, which means that there should be no problem in using activeCodePage in FFmpeg. For some reason, fifth version of patches ended up being sent as separate messages. Only the second part (https://ffmpeg.org/pipermail/ffmpeg-devel/2022-February/293206.html) is a reply to the first (https://ffmpeg.org/pipermail/ffmpeg-devel/2022-February/293205.html). It's a strange email glitch. I swear I used git send-email to send these patches.
diff --git a/fftools/Makefile b/fftools/Makefile index da42078..53438b6 100644 --- a/fftools/Makefile +++ b/fftools/Makefile @@ -11,6 +11,11 @@ ALLAVPROGS_G = $(AVBASENAMES:%=%$(PROGSSUF)_g$(EXESUF)) OBJS-ffmpeg += fftools/ffmpeg_opt.o fftools/ffmpeg_filter.o fftools/ffmpeg_hw.o +# Windows resource files +OBJS-ffmpeg-$(HAVE_GNU_WINDRES) += fftools/long_paths_utf8.o +OBJS-ffplay-$(HAVE_GNU_WINDRES) += fftools/long_paths_utf8.o +OBJS-ffprobe-$(HAVE_GNU_WINDRES) += fftools/long_paths_utf8.o + define DOFFTOOL OBJS-$(1) += fftools/cmdutils.o fftools/$(1).o $(OBJS-$(1)-yes) $(1)$(PROGSSUF)_g$(EXESUF): $$(OBJS-$(1)) diff --git a/fftools/long_paths_utf8.manifest b/fftools/long_paths_utf8.manifest new file mode 100644 index 0000000..d1ac1e4 --- /dev/null +++ b/fftools/long_paths_utf8.manifest @@ -0,0 +1,12 @@ +<?xml version="1.0" encoding="UTF-8" standalone="yes"?> + +<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" + xmlns:ws2019="http://schemas.microsoft.com/SMI/2019/WindowsSettings"> + <ws2016:longPathAware>true</ws2016:longPathAware> + <ws2019:activeCodePage>UTF-8</ws2019:activeCodePage> + </windowsSettings> + </application> +</assembly> diff --git a/fftools/long_paths_utf8.rc b/fftools/long_paths_utf8.rc new file mode 100644 index 0000000..f33de76 --- /dev/null +++ b/fftools/long_paths_utf8.rc @@ -0,0 +1,3 @@ +#include <windows.h> + +CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "long_paths_utf8.manifest"