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

From: nil-admirari@mailo.com
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
Date: Fri, 29 Apr 2022 20:52:00 +0200 (CEST)
Message-ID: <ea-mime-626c33d0-55b9-6b810815@www-7.mailo.com> (raw)
In-Reply-To: <DM8P223MB0365CA45BE0944C2AE4FB29CBAF89@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>

> 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.

> 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, if registry tweak
is too much a hassle for them; with the second they're stuck with workarounds—forever.

> 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.
There are probably other places like that. Examples you've given simply
do not exercise such code paths, but it does mean they do not exists.

_______________________________________________
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".