> 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
__
> ./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
__
> 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
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 | 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
---
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
@@ -
---
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
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
> 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
> 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
> 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
_
> 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
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..69a6f54ea3 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmduti
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
@@ -
---
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
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 | 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
---
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
@@ -
---
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
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
> 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 +
---
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 +++---
---
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
---
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
> 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
___
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
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
---
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
---
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
> 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
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
---
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
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
---
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
> I like the version check. I don't know about all the derivatives
> of AviSynth, but I assume you have checked that it's valid for
> the common ones (or at least the original non-Plus variant)?
Interface version was changed to 7 in 2020:
https://github.com/AviSynth/AviSynthPlus/commit/40900dc1c54
> Why do you use a 'do' loop? Can't you use the normal 2-step
> approach, i.e. call the winapi function with a NULL buffer,
> and then use the returned size to allocate the buffer.
> This way you always need a single allocation only.
GetModuleFileNameW does not follow this convention:
https://docs
> Presumably, the original manifest idea, parsed down to only using it to
> force FFmpeg into UTF-8, would be sufficient for this, right?
UTF-8 in manifest was rejected as too far-reaching, and then longs paths
were reimplemented with \\?\ prefixes, so now there is no manifest at all.
> The Wind
> src/libavutil/wchar_filename.h: In function ‘add_extended_prefix’:
> src/libavutil/wchar_filename.h:211:9: error:
> ‘wcscpy_instead_use_StringCbCopyW_or_StringCchCopyW’
> undeclared (first use in this function)
> wcscpy(temp_w, unc_prefix);
are fixed by defining NO_DSHOW_STRSAFE:
https://ffmpeg
> ...
> > - defining NO_DSHOW_STRSAFE in libavcodec/mf_utils.h
> ...
> Or if we'd add the define projectwide in e.g. configure it probably
> wouldn't be that bad? Kinda like how we already add
> "-D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS" in MSVC builds.
> Then we wouldn't need to wor
>> ...
>> 1. fopen() is replaced with avpriv_fopen_utf8(), getenv() is made
>> Unicode-aware
>> on Windows, and wide version of get_module_filename() is used as it is now.
> ...
> For that, the first option sounds better - that sounds to me more like a
> direction forward, not backwards.
Done: h
---
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 +++---
---
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
---
compat/w32dlfcn.h | 80 ++-
libavcodec/mf_utils.h | 1 +
2 files changed, 65 insertions(+), 16 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94efafb..e49d3841aa 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -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
> Why not use the AviSynth mechanism that allows to supply a UTF-8 string?
>
> https://github.com/AviSynth/AviSynthPlus/blob/c377916aa4146d2f4386852d91dc177d49103c16/avs_core/core/parser/script.cpp#L477-L481
Was not aware such a mechanism exists.
Commit dates back to 10 April 2017, first release
> Right, I wasn't aware that the -A version would return a
> guaranteed-ansi-compatible version of the filename. If that's really the
> case, this patch would indeed be a minor step backwards.
Two options are available:
1. fopen() is replaced with avpriv_fopen_utf8(), getenv() is made Unicode-aw
> This error isn't reproducible in git master - it's triggered by your
> yet-unmerged patches (that include wchar_filename.h in w32dlfcn.h).
Ok. It can be fixed by either
- defining NO_DSHOW_STRSAFE in libavcodec/mf_utils.h
- or by migrating os_support.h to StrSafe.h functions.
Which way is pref
> wcscpy is defined in corecrt_wstring.h, included in string.h,
> included in winnt.h included in windef.h, included in windows.h
Not so easy, it's the same as https://trac.ffmpeg.org/ticket/999:
> In file included from /opt/ct-ng/i686-w64-
> mingw32/sysroot/mingw/include/dshow.h:33
NO_DSHOW_ST
> This looks fine to me, and the discussion seems to have converged, so I'll
> go ahead and push this.
Build is now failing:
https://github.com/yt-dlp/FFmpeg-Builds/runs/6819319105?check_suite_focus=true.
In file included from
/opt/ct-ng/i686-w64-mingw32/sysroot/mingw/include/dshow.h:33,
>> I'm wondering why it converts wchar back to ansi instead of utf8 in 4/4 and
>> whether it won't fail then, when a path contains non-ANSI chars.
>
> Yes, that's a preexisting problem there. That patch gets rid of the fixed
> path lengths without touching the rest of the charset handling there.
>
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 f
---
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 | 80 +--
1 file changed, 64 insertions(+), 16 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94ef..6b0dd7d 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -22,9 +22,31 @@
#ifdef _WIN32
#includ
---
fftools/cmdutils.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 5d7cdc3..d42bb04 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -50,6 +50,7 @@
#include "opt_common.h"
#ifdef _WI
#if (_WIN32_WINNT < 0x0602) || HAVE_WINRT
#include "libavutil/wchar_filename.h"
#endif
caused build error due to utf8towchar being undefined.
Made wchar_filename.h include unconditional.
Also removed manifest changes since it was decided to adopt \\?\ prefixes
instead.
New version is at
https:
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
---
fftools/cmdutils.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 5d7cdc3..d42bb04 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -50,6 +50,7 @@
#include "opt_common.h"
#ifdef _WI
---
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 | 80 +--
1 file changed, 64 insertions(+), 16 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94ef..6b0dd7d 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -22,9 +22,31 @@
#ifdef _WIN32
#includ
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
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
> No, it is intended and expected that the structs are different.
> ...
> That's why the structs are different and the fields of
> win32_stat always large enough, no matter which struct
> is being used internally.
Please document that there is a potential difference in time types
and that the dif
> + struct win32_stat
> + {
> + _dev_t st_dev; /* ID of device containing file */
> + _ino_t st_ino; /* inode number */
> + unsigned short st_mode; /* protection */
> + short st_nlink; /* number of hard links */
> + short st_uid; /* user ID of owner */
> + short st_gid; /* group ID of owner */
> +
> If we would
> want to get rid of this, we could define the struct as follows:
>
> struct win32_stat
> {
> union
> {
> struct _stati64;
> struct _stati64 stat;
> };
> };
>
> The union is anonymous and includes _stati64 twice: once anonymous
> and once named.
>
> This would allow us to define our w
>> Not possible for stat precisely because of function and struct sharing a
>> name.
> That's exactly what is said above and before :-)
My previous question was not answered, so I had to look up the answer myself.
> I'm actually wondering how does it even compile. All stat structs in code
> beco
> I thought the purpose of all those re-mappings would be that plain
> Posix functions can still be used..?
> It's already the Posix declaration where the function name
> is the same as the structure name (stat).
Not possible for stat precisely because of function and struct sharing a name.
That'
> Yes, that's true. But there are hundreds of other things someone could
> define which makes compilation fail.
Doesn't mean that yet another such thing should be added by incorrectly
redefining structs already defined correctly by system headers.
> Probably you didn't spot it. It's already there
> stat wasn't already defined as win32_stat.
> win32_stat was already defined but not mapped. That's what my change
> does.
There are two defines in os_support.h:
# ifdef stat
# undef stat
# endif
# define stat _stati64
and
DEF_FS_FUNCTION2(stat, _wstati64, _stati64, struct stat*)
which
> And what's the point about this?
Point is obvious: extended paths are difficult to handle correctly.
get_extended_win32_path cannot be used on its own, only as a final step
before getting FILE* or a file descriptor.
___
ffmpeg-devel mailing list
ffm
> I have left those out by intention because they are pending removal
> and are only for debugging.
Is dvdsubdec.c parse_ifo_palette pending removal? What about
- vf_pnsr.c init()
- vf_vidstabdetect.c config_input()
- vf_vidstabtransform.c config_input()?
___
> The functions are needed in both. file_open.c cannot be included
> in libavformat/os_support.h and neither the other way round,
> so they need to be in a 3rd place. How about renaming
> wchar_filename.h to windows_filename.h ?
Probably it's better to rename.
> I have skipped those checks becau
> We already have win32_stat, but what's a bit tricky is that the
> struct that this function takes as a parameter is named the same
> as the function itself.
Sorry, I thought is was a definition of a function, not a struct.
Since stat function is already defined as win32_stat,
It's better to re
> +static inline int path_is_extended(const wchar_t *path)
> +{
> + size_t len = wcslen(path);
> + if (len >= 4 && path[0] == L'\\' && (path[1] == L'\\' || path[1] == L'?')
> && path[2] == L'?' && path[3] == L'\\')
Length check is probably unnecessary: comparisons will reject '\0'
and further com
> 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
> 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
> 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
> 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
> 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.
> 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
> 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
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
> > 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
> 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 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
> 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
> 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
> 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 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
> 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
> 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,
> 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
> 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
> 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
1 - 100 of 140 matches
Mail list logo
