[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 nil-
> admirari at mailo.com
> Sent: Friday, April 29, 2022 8:52 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
> utf8toansi
> 
> > A code change for which no use case exists and does not provide
> > any benefit is not relevant. That's my point.
> 
> You've deleted me saying
> 
> >> You're talking as if MAX_PATH limited library loader is self-
> evidently
> >> superior, and it is the loader that has no such limitation that has
> to justify
> >> its existence. As far as I'm concerned it just the other way
> around.
> 
> and now claim that code change is irrelevant.

Yes, because there is no realistic case in which ffmpeg will need
to load any dll from a long path.
I've asked you multiple times to give an example.

> > Imagine, you are creating a software (no matter whether you're big
> or small,
> > open or closed source, targeting business or home users, using a
> custom or
> > public built ffmpeg) and you bundle ffmpeg.exe with your software
> like many
> > are doing. Now, re-read my comments, maybe it will make more sense
> to you.
> 
> They do not. Customer ask for long path support and gets two
> responses:
> 
> 1. Enable long path support via registry once, and never care about it
> again.
> 2. Convert path to absolute and prefix it with \\?\ every time you use
> our software.
> 
> I don't see how second workaround can be any good at all. With the
> first option,
> customers can at least pressure Microsoft into making it a default

So, ffmpeg should implement something that doesn't work without a
registry change in order to "pressure Microsoft" to change it at 
some point in the future?

> , if
> registry tweak
> is too much a hassle for them; with the second they're stuck with
> workarounds—forever.

I apologize when I have created the impression that ffmpeg should
be left as is and users should continue adding the long path prefix
themselves. I'm not opposed to adding support for long paths, I'm
just opposed to the method.

Implementing long path support by adding the prefix is not 
a "workaround". Those kinds of paths are part of OS functionality
since Windows NT and will still work in Windows 20 or whatever
may come. 

What IS a workaround is having to add the prefix manually to 
paths when using ffmpeg.

You wrote

> with the second they're stuck with
> workarounds—forever.

But it's just the other way round: 
Because with the first, you cannot rely that long paths are
working, you would be stuck needing to continue prefixing paths 
manually "forever".
(to also cover cases where it's not working)


> > ffmpeg is already working pretty well in handling long file paths
> (also with
> > Unicode characters) when pre-fixing paths with \\?\
> 
> It handles them most of the time, but not always. I already mentioned
> that the code from
> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295568.html
> explicitly converts all backslashes into forward slashes for unknown
> reasons,
> and that code will not work with \\?\ paths because //?/ is not a
> valid prefix.

IIRC this code is handling code paths relative to the executable path,
and the executable doesn't run from a long path anyway.

Nonetheless it might make sense to adjust that slash replacement for 
Windows. Same like you, I don't know why it has been added.

> > This patchset does not provide reliable behavior.
> 
> Actually it does.
> 
> > This way, you won't be able to use long paths with ffmpeg within the
> next 5-8 years at minimum,
> 
> Long paths can be used since August, 2 2016. Some ~6 years have
> already passed.

You know what I meant: it's not activated by default.

> > because even in the latest versions of Windows 11, this is not
> enabled by
> > default in the operating system.
> 
> FFmpeg isn't bundled by default either. And not everyone has rights to
> download and run arbitrary software on their machines.

That's right, but that's not a question that matters because that's
not in the hands of ffmpeg.

What is in the hands of ffmpeg though, is requiring a change which
needs administrative privileges or not.

> > What is the value of adding a capability where it will be a lottery
> > game whether it will work or not on each system?
> 
> Windows 10 > 1607 + registry key = it works. Otherwise it doesn't.
> There is no lottery.

I don't want to argue about the term lottery.

What I'm saying is that a solution is preferable which doesn't have
an "Otherwise it doesn't" part.

Best regards
softworkz