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

From: Soft Works <softworkz@hotmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v14 4/5] libavformat: Remove MAX_PATH limit and use UTF-8 version of getenv()
Date: Mon, 13 Jun 2022 22:01:32 +0000
Message-ID: <DM8P223MB0365A83DFEAFDE93FC9C2055BAAB9@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <DM8P223MB03652677C1EF37BCDCAC089DBAAB9@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Soft Works
> Sent: Monday, June 13, 2022 11:53 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v14 4/5] libavformat: Remove
> MAX_PATH limit and use UTF-8 version of getenv()
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > nil-admirari@mailo.com
> > Sent: Monday, June 13, 2022 10:53 PM
> > To: ffmpeg-devel@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).

Before somebody will ask how I come to make such claims, here's 
why: 

As of Win 11, the Explorer still warns or even prevents you from 
creating long paths, but you are free to use any kind of non-ANSI
characters for file and folders names. This does not only apply to 
the file management application, but includes the file open and save
dialogs of all applications that are using the standard dialogs.

sw
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".