On Fri, 15 Apr 2022, Nil Admirari wrote:
---
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/swresample.h"
#include "libavutil/avassert.h"
#include "libavutil/avstring.h"
+#include "libavutil/avutil.h"
#include "libavutil/channel_layout.h"
#include "libavutil/display.h"
#include "libavutil/mathematics.h"
@@ -50,6 +51,7 @@
#include "opt_common.h"
#ifdef _WIN32
#include <windows.h>
+#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.
#endif
AVDictionary *sws_dict;
@@ -812,28 +814,43 @@ FILE *get_preset_file(char *filename, size_t
filename_size,
{
FILE *f = NULL;
int i;
+#if HAVE_GETMODULEHANDLE && defined(_WIN32)
+ char *datadir = NULL;
+#endif
const char *base[3] = { getenv("FFMPEG_DATADIR"),
getenv("HOME"),
Hmm, I guess neither of these are commonly set on Windows - otherwise this
would suddenly change to interpret generic environment variables as UTF8.
FFMPEG_DATADIR, };
if (is_path) {
av_strlcpy(filename, preset_name, filename_size);
- f = fopen(filename, "r");
+ f = av_fopen_utf8(filename, "r");
} else {
As mentioned elsewhere, I realized that av_fopen_utf8 is problematic, but
that's an orthogonal issue, and the issue is already preexisting, and it's
used for a fairly marginal feature here, so I guess that can be tolerated
too (and if the root cause is fixed, this gets taken care of at the same
time too).
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".