[FFmpeg-devel] [PATCH v9 4/6] fftools/cmdutils.c: Remove MAX_PATH limit and replace fopen with av_fopen_utf8

Martin Storsjö martin at martin.st
Wed Apr 20 14:39:14 EEST 2022


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



More information about the ffmpeg-devel mailing list