[FFmpeg-devel] [PATCH v14 4/5] libavformat: Remove MAX_PATH limit and use UTF-8 version of getenv()

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> nil-admirari at mailo.com
> Sent: Monday, June 13, 2022 10:53 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v14 4/5] libavformat: Remove
> MAX_PATH limit and use UTF-8 version of getenv()
> 
> > 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/40900dc1c54c14ea9f188
> c7242b88d464d067a44
> three years after utf8 was implemented. If I'm not mistaken, there is
> no way to check
> for a particular revision.
> 
> > Two ideas came to my mind how this could be done better.
> > What's actually needed here is not a string conversion, we need
> > a valid and usable filename, and the function could be more
> > something like "get_ansi_filename()".
> >
> > The first thing that this function could do is to convert the
> > the filename to ANSI and right back to UTF-8, then compare the
> > UTF-8 result with the original UTF-8 string. When both are equal,
> > we know that the conversion is safe, otherwise we know that it
> > won't work.
> >
> > Then, we can use the win32 API GetShortFileName(). Which returns
> > file and directory names in 8.3 notation which (IIRC) contains
> > only letters which are valid in the ANSI code page.
> >
> > 8.3 file names do not always exist (depending on system config),
> > but it's always worth trying.
> >
> > Should both of these procedures fail, we could at least output
> > a useful message, explaining why it doesn't work.
> >
> > Let me know what you think.
> 
> Too much work for something that was fixed on AviSynth+ side two
> years ago.

I wasn't sure how important AviSynth is for you. Until I had given
the hint at the UTF8 option in AviSynth, it seemed to be a high
priority to enable the use of long paths with AviSynth, and what
I was thinking is that this might be of interest because paths 
with non-ANSI chars are a way more frequent case than long paths
(on Windows).

Anyway, as long as people are using a non-ancient version of 
AviSynthPlus, it's all covered by your patch, and I'm totally
fine with this part!

Thanks,
sw