[FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Hendrik Leppkes
> Sent: Monday, April 25, 2022 2:52 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
> utf8toansi
> 
> On Mon, Apr 25, 2022 at 1:12 PM Soft Works <softworkz at hotmail.com>
> wrote:
> >
> > From my point of view:
> > ffmpeg is already working pretty well in handling long file paths
> (also with
> > Unicode characters) when pre-fixing paths with \\?\, and this is
> working
> > on all Windows versions without all the caveats, requirements and
> conditions
> > that I mentioned.
> 
> "We have already worked around this problem in our deployment,
> therefore there is no need to try to improve it" is surely not a very
> strong argument.
> 
> Will your work-around continue to work? Yes.
> Will the changes actually impact anyone negatively? No known case is
> documented, here or otherwise.

You may want to read this:

https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

> Will this change objectively improve the operation of ffmpeg on
> Windows? Maybe not for everyone (yet), but certainly it'll allow it to
> do so in controlled environments.
> 
> I'm not seeing a good argument here to generally block the patch on,
> as this entire thread boils down to .. what? Fear of change?

Pardon?

Seems you missed my point (probably you haven't followed the full conversation). 
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.

The .NET/corefx runtime uses the prefix method internally, rclone is using it,
the Java runtime is using it, just to name a few examples.

Best regards,
softworkz