ANSI functions do not support long paths, so I had to change
LoadLibraryExA to LoadLibraryExW.in compat/w32dlfcn.h as well.
I cannot find other uses of WinAPI functions ending with ..A(.
Looks like FFmpeg doesn't use ANSI functions anywhere else,
but the codebase is huge, so who knows.
Previous p
Previously there was GetModuleFileNameA. wchartoansi is used to match old
behaviour. I can replace it with wchartoutf8 if you wish.
> - if (GetModuleFileNameA(GetModuleHandleA(NULL), datadir, sizeof(datadir) -
> 1))
> + if (wchartoansi(datadir_w, &datadir))
> + datadir = NULL;
From: Martin Stor
> if the path later is going to end up in a codepath that expects it to be UTF8
> (please do check!), then we should go that way instead
I checked. datadir ends up in (cmdutils.c:2104)
base[2] = datadir;
and base[*] are later used in (cmdutils.c:2112 or 2116)
snprintf(filename, filenam
> 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.o
These functions are going to be used in libavformat/avisynth.c
and fftools/cmdutils.c when replacing MAX_PATH-sized buffers
with dynamically sized ones.
---
libavutil/wchar_filename.h | 51 ++
1 file changed, 51 insertions(+)
diff --git a/libavutil/wchar_filena
Also replaces a call to LoadLibraryExA with LoadLibraryExW
since ANSI functions do not support long paths.
---
compat/w32dlfcn.h | 74 ++-
1 file changed, 61 insertions(+), 13 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94ef
---
fftools/Makefile | 5 +
fftools/fftools.manifest | 10 ++
fftools/manifest.rc | 3 +++
3 files changed, 18 insertions(+)
create mode 100644 fftools/fftools.manifest
create mode 100644 fftools/manifest.rc
diff --git a/fftools/Makefile b/fftools/Makefile
index da420
---
fftools/cmdutils.c | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 4b50e15..e87601e 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -40,6 +40,7 @@
#include "libavutil/attri
---
libavformat/avisynth.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 2bd0c69..e28d832 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -34,6 +34,7 @@
/* Platform-specific directives. */
---
fftools/fftools.manifest | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fftools/fftools.manifest b/fftools/fftools.manifest
index 30b7d8f..d1ac1e4 100644
--- a/fftools/fftools.manifest
+++ b/fftools/fftools.manifest
@@ -3,8 +3,10 @@
-http://schemas.microso
> Ok, well maybe we should change that too, to use wchar paths (or utf8->whcar
> routines?).
Changed to wchartoutf8, and replaced fopen with av_fopen_utf8 throughout the
file. See https://ffmpeg.org/pipermail/ffmpeg-devel/2022-February/293229.html.
> doesn't use UTF-8 like everything else.
Th
These functions are going to be used in libavformat/avisynth.c
and fftools/cmdutils.c remove MAX_PATH limit.
---
libavutil/wchar_filename.h | 51 ++
1 file changed, 51 insertions(+)
diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
index 90f0
---
libavformat/avisynth.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 8ba2bde..f7bea8c 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -34,6 +34,7 @@
/* Platform-specific directives. */
---
compat/w32dlfcn.h | 78 ++-
1 file changed, 64 insertions(+), 14 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94ef..0f41f50 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -25,6 +25,30 @@
#if (_WIN32_WINNT < 0x
---
fftools/cmdutils.c | 38 +-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 5d7cdc3..a66dbb2 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -37,6 +37,7 @@
#include "libswresample/swre
---
fftools/Makefile | 5 +
fftools/fftools.manifest | 10 ++
fftools/manifest.rc | 3 +++
3 files changed, 18 insertions(+)
create mode 100644 fftools/fftools.manifest
create mode 100644 fftools/manifest.rc
diff --git a/fftools/Makefile b/fftools/Makefile
index 5ebf5
---
fftools/fftools.manifest | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fftools/fftools.manifest b/fftools/fftools.manifest
index 30b7d8f..d1ac1e4 100644
--- a/fftools/fftools.manifest
+++ b/fftools/fftools.manifest
@@ -3,8 +3,10 @@
-http://schemas.microso
Fails to apply to current master.
New version of these patches can be found at:
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/294654.html. Please review.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listin
---
libavfilter/vf_frei0r.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_frei0r.c b/libavfilter/vf_frei0r.c
index f11ae6e55c..727e96561a 100644
--- a/libavfilter/vf_frei0r.c
+++ b/libavfilter/vf_frei0r.c
@@ -31,6 +31,7 @@
#include "libavutil/a
wchartoutf8() converts strings returned by WinAPI into UTF-8,
which is FFmpeg's preffered encoding.
Some external dependencies, such as AviSynth, are still
not Unicode-enabled. utf8toansi() converts UTF-8 strings
into ANSI in two steps: UTF-8 -> wchar_t -> ANSI.
wchartoansi() is responsible for th
---
compat/w32dlfcn.h | 95 +--
libavcodec/mf_utils.h | 1 +
2 files changed, 74 insertions(+), 22 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94efafb..e4f46c488c 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -2
---
fftools/cmdutils.c | 53 +---
fftools/ffmpeg_opt.c | 9 ++--
2 files changed, 47 insertions(+), 15 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 5d7cdc3e10..5e7fbbe2ee 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmduti
1. getenv() is replaced with getenv_utf8() across libavformat.
2. New versions of AviSynth+ are now called with UTF-8 filenames.
3. Old versions of AviSynth are still using ANSI strings,
but MAX_PATH limit on filename is removed.
---
libavformat/avisynth.c| 39 +++---
> path_size <= INT16_MAX
>
> (the edge case is already covered by the equals)
Done: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-June/297590.html.
Don't quite understand what edge case you've meant:
INT16_MAX is 32767, which is the maximal path length allowed,
+ 1 is needed for the terminating n
---
compat/w32dlfcn.h | 95 +--
libavcodec/mf_utils.h | 1 +
2 files changed, 74 insertions(+), 22 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94efafb..e4f46c488c 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -2
---
libavfilter/vf_frei0r.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_frei0r.c b/libavfilter/vf_frei0r.c
index f11ae6e55c..727e96561a 100644
--- a/libavfilter/vf_frei0r.c
+++ b/libavfilter/vf_frei0r.c
@@ -31,6 +31,7 @@
#include "libavutil/a
wchartoutf8() converts strings returned by WinAPI into UTF-8,
which is FFmpeg's preffered encoding.
Some external dependencies, such as AviSynth, are still
not Unicode-enabled. utf8toansi() converts UTF-8 strings
into ANSI in two steps: UTF-8 -> wchar_t -> ANSI.
wchartoansi() is responsible for th
---
fftools/cmdutils.c | 53 +---
fftools/ffmpeg_opt.c | 9 ++--
2 files changed, 47 insertions(+), 15 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 5d7cdc3e10..5e7fbbe2ee 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmduti
1. getenv() is replaced with getenv_utf8() across libavformat.
2. New versions of AviSynth+ are now called with UTF-8 filenames.
3. Old versions of AviSynth are still using ANSI strings,
but MAX_PATH limit on filename is removed.
---
libavformat/avisynth.c| 39 +++---
> I guess we'd might have to add getenv to e.g. the SYSTEM_FUNCS list, so
> we'd get a HAVE_GETENV in config.h - then we could make getenv_utf8 a
> no-op if HAVE_GETENV is 0.
Done: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-June/297596.html
___
---
libavfilter/vf_frei0r.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_frei0r.c b/libavfilter/vf_frei0r.c
index f11ae6e55c..727e96561a 100644
--- a/libavfilter/vf_frei0r.c
+++ b/libavfilter/vf_frei0r.c
@@ -31,6 +31,7 @@
#include "libavutil/a
wchartoutf8() converts strings returned by WinAPI into UTF-8,
which is FFmpeg's preffered encoding.
Some external dependencies, such as AviSynth, are still
not Unicode-enabled. utf8toansi() converts UTF-8 strings
into ANSI in two steps: UTF-8 -> wchar_t -> ANSI.
wchartoansi() is responsible for th
---
compat/w32dlfcn.h | 100 --
libavcodec/mf_utils.h | 1 +
2 files changed, 79 insertions(+), 22 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94efafb..fb1aa1b72e 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -
1. getenv() is replaced with getenv_utf8() across libavformat.
2. New versions of AviSynth+ are now called with UTF-8 filenames.
3. Old versions of AviSynth are still using ANSI strings,
but MAX_PATH limit on filename is removed.
---
libavformat/avisynth.c| 39 +++---
---
fftools/cmdutils.c | 53 +---
fftools/ffmpeg_opt.c | 9 ++--
2 files changed, 47 insertions(+), 15 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 5d7cdc3e10..5e7fbbe2ee 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmduti
> With the +1 your while condition term is effectively
>
> path_size <= 32768
>
> But when the path_size is 32768, you do not need to
> go for another loop with an increased buffer because this is
> already as large as it can get. There won't be any 32769
> or 32770 (...) cases, I think.
Removed +
wchartoutf8() converts strings returned by WinAPI into UTF-8,
which is FFmpeg's preffered encoding.
Some external dependencies, such as AviSynth, are still
not Unicode-enabled. utf8toansi() converts UTF-8 strings
into ANSI in two steps: UTF-8 -> wchar_t -> ANSI.
wchartoansi() is responsible for th
---
fftools/cmdutils.c | 53 +---
fftools/ffmpeg_opt.c | 9 ++--
2 files changed, 47 insertions(+), 15 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 5d7cdc3e10..69a6f54ea3 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmduti
---
compat/w32dlfcn.h | 100 --
libavcodec/mf_utils.h | 1 +
2 files changed, 79 insertions(+), 22 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94efafb..fb1aa1b72e 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -
---
libavfilter/vf_frei0r.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/libavfilter/vf_frei0r.c b/libavfilter/vf_frei0r.c
index f11ae6e55c..9a7a11604a 100644
--- a/libavfilter/vf_frei0r.c
+++ b/libavfilter/vf_frei0r.c
@@ -31,6 +31,7 @@
#include "libavutil
1. getenv() is replaced with getenv_utf8() across libavformat.
2. New versions of AviSynth+ are now called with UTF-8 filenames.
3. Old versions of AviSynth are still using ANSI strings,
but MAX_PATH limit on filename is removed.
---
libavformat/avisynth.c| 39 +++---
---
libavfilter/vf_frei0r.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/libavfilter/vf_frei0r.c b/libavfilter/vf_frei0r.c
index f11ae6e55c..c3176ea1f7 100644
--- a/libavfilter/vf_frei0r.c
+++ b/libavfilter/vf_frei0r.c
@@ -31,6 +31,7 @@
#include "libavu
---
compat/w32dlfcn.h | 100 --
libavcodec/mf_utils.h | 1 +
2 files changed, 79 insertions(+), 22 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94efafb..fb1aa1b72e 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -
wchartoutf8() converts strings returned by WinAPI into UTF-8,
which is FFmpeg's preffered encoding.
Some external dependencies, such as AviSynth, are still
not Unicode-enabled. utf8toansi() converts UTF-8 strings
into ANSI in two steps: UTF-8 -> wchar_t -> ANSI.
wchartoansi() is responsible for th
---
fftools/cmdutils.c | 53 +---
fftools/ffmpeg_opt.c | 9 ++--
2 files changed, 47 insertions(+), 15 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 5d7cdc3e10..69a6f54ea3 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmduti
1. getenv() is replaced with getenv_utf8() across libavformat.
2. New versions of AviSynth+ are now called with UTF-8 filenames.
3. Old versions of AviSynth are still using ANSI strings,
but MAX_PATH limit on filename is removed.
---
libavformat/avisynth.c| 39 +++---
> Thanks, adding #define WIN32_LEAN_AND_MEAN in wchar_filename.h fixes the
> issue.
Added WIN32_LEAN_AND_MEAN:
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-June/297804.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/ma
> FWIW - I wasn't entirely sure we can conclude that we always pass through
> a case that initializes the err variable here, so just to be sure, I
> locally amended this patch to initialize the err variable to 0 too.
Fixed: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-June/297806.html
_
> Note that this should be #if HAVE_GETENV - these constants are always
> defined and evaluate to 0 or 1. No need to resend the patchset just for
> that. (I added an explicit #include "config.h" above here too, just to
> make it clearer.)
Fixed: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-Ju
> This forces allocations and frees in scenarios where this is wholly
> unnecessary. This can be avoided by adding a custom deallocator for
> strings returned via getenv_utf8: Namely a define/wrapper around av_free
> in the _WIN32 and a no-op else.
Done: https://ffmpeg.org/pipermail/ffmpeg-devel/2
wchartoutf8() converts strings returned by WinAPI into UTF-8,
which is FFmpeg's preffered encoding.
Some external dependencies, such as AviSynth, are still
not Unicode-enabled. utf8toansi() converts UTF-8 strings
into ANSI in two steps: UTF-8 -> wchar_t -> ANSI.
wchartoansi() is responsible for th
---
fftools/cmdutils.c | 53 +---
fftools/ffmpeg_opt.c | 9 ++--
2 files changed, 47 insertions(+), 15 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 5d7cdc3e10..69a6f54ea3 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmduti
---
compat/w32dlfcn.h | 100 --
libavcodec/mf_utils.h | 1 +
2 files changed, 79 insertions(+), 22 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94efafb..fb1aa1b72e 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -
---
libavfilter/vf_frei0r.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_frei0r.c b/libavfilter/vf_frei0r.c
index f11ae6e55c..1e01114b76 100644
--- a/libavfilter/vf_frei0r.c
+++ b/libavfilter/vf_frei0r.c
@@ -31,6 +31,7 @@
#include "libavutil/a
1. getenv() is replaced with getenv_utf8() across libavformat.
2. New versions of AviSynth+ are now called with UTF-8 filenames.
3. Old versions of AviSynth are still using ANSI strings,
but MAX_PATH limit on filename is removed.
---
libavformat/avisynth.c| 39 +++---
> Looks good overall, thanks! The freeenv_utf8 function needed a couple
> minor fixes though, to fix these warnings/errors:
Fixed: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-June/297841.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
> ./libavutil/getenv_utf8.h: In function ‘freeenv_utf8’:
> ./libavutil/getenv_utf8.h:69:1: error: parameter name omitted
> static inline void freeenv_utf8(const char *)
> ^~
Fixed: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-June/297841.html
__
> Or any reuses the #ifs from getenv_utf8.h.
> https://github.com/mkver/FFmpeg/commits/getenv contains a version that
> does this.
Introduced getenv_dup() and simplified #ifs a little:
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-June/297841.html
__
---
fftools/Makefile | 5 +
fftools/fftools.manifest | 10 ++
fftools/manifest.rc | 3 +++
3 files changed, 18 insertions(+)
create mode 100644 fftools/fftools.manifest
create mode 100644 fftools/manifest.rc
diff --git a/fftools/Makefile b/fftools/Makefile
index 81ad6
---
libavformat/avisynth.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 8ba2bdea..f7bea8c3 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -34,6 +34,7 @@
/* Platform-specific directives.
---
compat/w32dlfcn.h | 78 ++-
1 file changed, 64 insertions(+), 14 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94efa..0f41f50b 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -25,6 +25,30 @@
#if (_WIN32_WINNT <
---
fftools/cmdutils.c | 38 +-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 5d7cdc3e..a66dbb22 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -37,6 +37,7 @@
#include "libswresample/sw
These functions are going to be used in libavformat/avisynth.c
and fftools/cmdutils.c remove MAX_PATH limit.
---
libavutil/wchar_filename.h | 51 ++
1 file changed, 51 insertions(+)
diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
index 90f0
---
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 @@
-http://schemas.micro
No longer applies. New version are at:
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295391.html
From: Nil Admirari
To: ffmpeg-devel@ffmpeg.org
Subject: [FFmpeg-devel] [PATCH v8 5/6] fftools: Enable long path support on
Windows (fixes #8885)
Date: 28/03/2022 22:43:38 Europe/Moscow
These functions are going to be used in libavformat/avisynth.c
and fftools/cmdutils.c remove MAX_PATH limit.
---
libavutil/wchar_filename.h | 52 ++
1 file changed, 52 insertions(+)
diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
index 90f0
Newer versions of Windows (Windows 10 1607 and newer) can support path
names longer than MAX_PATH (260 characters). To take advantage of that, an
application needs to opt in, by including a small manifest as a resource.
Application must be prepared to handle filenames greater than MAX_PATH.
Additi
---
libavformat/avisynth.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 8ba2bdea..f7bea8c3 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -34,6 +34,7 @@
/* Platform-specific directives.
---
compat/w32dlfcn.h | 78 ++-
1 file changed, 64 insertions(+), 14 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94efa..2284ac7a 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -25,6 +25,30 @@
#if (_WIN32_WINNT <
Starting with Windows 1903 applications can set active code page to UTF-8
with the application manifest. It improves path name compatibility
with dependencies that use char* pathnames internally, but whose code page
has already been changed to UTF-8 via a manifest (e.g. AviSynth).
On older version
---
fftools/cmdutils.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 5d7cdc3e..af070c19 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -37,6 +37,7 @@
#include "libswresample/swresamp
---
libavformat/avisynth.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 8ba2bdea..f7bea8c3 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -34,6 +34,7 @@
/* Platform-specific directives.
---
fftools/cmdutils.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 5d7cdc3e..d42bb04e 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -50,6 +50,7 @@
#include "opt_common.h"
#ifdef _
These functions are going to be used in libavformat/avisynth.c
and fftools/cmdutils.c to remove MAX_PATH limit.
---
libavutil/wchar_filename.h | 51 ++
1 file changed, 51 insertions(+)
diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
index 9
---
compat/w32dlfcn.h | 78 ++-
1 file changed, 64 insertions(+), 14 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94efa..2284ac7a 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -25,6 +25,30 @@
#if (_WIN32_WINNT <
Newer versions of Windows (Windows 10 1607 and newer) can support path
names longer than MAX_PATH (260 characters). To take advantage of that, an
application needs to opt in, by including a small manifest as a resource.
Application must be prepared to handle filenames greater than MAX_PATH.
Additi
Starting with Windows 1903, applications can set active code page to UTF-8
in the application manifest. It improves path name compatibility
with dependencies that use char* pathnames internally, but whose code page
has already been changed to UTF-8 with a manifest (e.g. AviSynth).
On older version
> However while reviewing this, I noticed a preexisting issue regarding the
> av_fopen_utf8 function. This patchset extends the use of that function
> into fftools, which isn't great given the issue...
Reverted back to fopen().
> The other question is whether it's tolerable to use more non-inst
> This looks ok to me, but as mentioned in the other patch, I think CP_ACP
> actually would be more correct than the current CP_THREAD_ACP
utf8toansi was changed to use CP_ACP in
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295569.html, so avisynth.c
now uses CP_ACP as well.
___
> > +#include "compat/w32dlfcn.h"
> This adds a dependency on nonpublic headers - which I think can be
> tolerated as it's only a build-time issue, and fftools are currently built
> as part of the rest of the ffmpeg build anyway.
Currently the header consist entirely of static inline functions
> Does that sound like the correct explanation of the situation?
Yes, thanks. I altered the suggested message a bit.
New version of the patch:
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295571.html.
___
ffmpeg-devel mailing list
ffmpeg-dev
> 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
> 1. Patch 3/6 - Replace LoadLibraryExA with LoadLibraryExW
> What's the point in making changes to library loading? What does it fix?
From the commit
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295571.html:
... the path length limitation is only lifted for file APIs that pass paths a
> You normally don't load libraries from such longs paths.
And? 80% of FFmpeg functionality is normally not used.
> But file IO is a fundamental feature where a common and predictable
> behavior is crucial.
You're talking as if the manifest change somehow broke or fundamentally altered
file IO,
> Again, you have deleted my asking for an example scenario
> and which library would need to be loaded from a long path.
Because I don't think that an example would be relevant. Generic library
function must be able to load a library, no matter the location.
You're talking as if MAX_PATH limited
> What is the effect of the version attribute here? Would it be meaningful
> to replace the static dummy value with something more realistic like
> "5.1.n" or similar?
Version is a required attribute, see
https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests. It
does not h
> A code change for which no use case exists and does not provide
> any benefit is not relevant. That's my point.
You've deleted me saying
>> You're talking as if MAX_PATH limited library loader is self-evidently
>> superior, and it is the loader that has no such limitation that has to
>> justif
> What I'm saying is that prepending the long path prefix is the better way
> for supporting long paths and I mentioned our experience with it only to
> confirm that it's working well.
Maybe you'll even provide a patchset for such a wonderful approach?
> The .NET/corefx runtime uses the prefix
> This patchset does not provide reliable behavior.
Actually it does.
> This way, you won't be able to use long paths with ffmpeg within the next 5-8
> years at minimum,
Long paths can be used since August, 2 2016. Some ~6 years have already passed.
> because even in the latest versions of Win
> As soon as Microsoft actually makes UTF-8
> the default code page going forward, that issue will poof
> out of existence, as if by magic. It already does if you
> toggle it on in the system settings.
True. System-wide UTF-8 can cause problems with legacy software, but starting
with Windows 11 su
> Yes, because there is no realistic case in which ffmpeg will need
> to load any dll from a long path.
> I've asked you multiple times to give an example.
Managed to find time to actually test: https://postimg.cc/F1C64nq1.
Windows 10 21H2 LTSC, long paths are enabled and 8.3 paths are disabled
vi
> > As a matter of fact, you are. Your alternative method implies
> > ploughing
> > through hundreds of C files normalising path handling across the
> > entire application,
> Almost everybody here knows that this isn't true.
I do not. During the review of just this particular patchset it was foun
You have completely ignored my question, haven't you? Here it is again:
>> Is there a Path struct, analogous to LLVM class, that all of FFmpeg is using?
>> Or FFmpeg isn't using any special structs and paths are indistinguishable
>> from ordinary strings?
> Read again. As each lib gets its own co
> Paths are strings.
In other languages, paths are represented with classes, e.g.
std::filesystem::path in C++
or pathlib.Path in Python. In C classes have to be emulated with structs and
functions.
Even plain strings would've been OK to represent paths, if there was a set of
functions
everyone
> I think that can be changed easily.
How about writing the necessary patches yourself?
> A path using forward slashes can still be prefixed with '\\?\'
It cannot. Only backslashes are valid in \\?\ paths.
> The prefixing can be implemented as a function and then be used
> in file_open.c.
> Ot
> I'm not sure how much you had followed, so please excuse in case you
> had already read it: the manifest approach does not work on a default
> Windows installation.
> To activate long path support, the users needs to opt-in to a behavior
> that is probably deactivated by default for some reason.
> diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
> ...
> +static inline int path_is_extended(const wchar_t *path)
> ...
Why path handling functions ended up in wchar_filename.h?
Isn't it better to move them to file_open or os_support?
> +num_chars = GetFullPathNameW(*ppa
> diff --git a/libavformat/os_support.h b/libavformat/os_support.h
In addition to what you've already added, this file defines stat as:
#ifdef _WIN32
...
# ifdef stat
# undef stat
# endif
# define stat _stati64
...
which is
1. not wide-char aware (_wstati64 does exist)
2. not long path awar
> I have kept the individual functions separate on purpose, to make it easy to
> compare with the .NET impl. (compilers should inlinie those anyway)
Calling add_extended_prefix without pre-validation results in error,
since it does check for \\?\, \\.\, or \??\; only it's wrapper
get_extended_win
> All these paths end up either in win32_open (in file_open.c) or in
> one of the functions mapped inside os_support.h where they are now
> (with my submitted patchset) handled by the get_extended_win32_path()
> function, which handles all cases (e.g. forward slashes, relative paths,
> prefixed, n
1 - 100 of 140 matches
Mail list logo
