> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Nil > Admirari > Sent: Saturday, April 23, 2022 10:56 PM > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: > Add whcartoutf8, wchartoansi and utf8toansi > > These functions are going to be used in libavformat/avisynth.c > and fftools/cmdutils.c to remove MAX_PATH limit. > ---
Hi, thanks for submitting this patchset. I'm afraid that I hadn't found time to look into this at an earlier stage, so please apologize if one of my questions has been covered before. 1. Patch 3/6 - Replace LoadLibraryExA with LoadLibraryExW What's the point in making changes to library loading? What does it fix? Which dll cannot be loaded with the current implementation and what would be the location of the dll and the location of the exe in that case? Could you please give an example of a situation that this is supposed to fix? 2. Patches 5/6 and 6/6 - Add Fusion Manifest The manifest that you want to add includes two settings: - longPathAware effective on Windows 10, version 1607 or later - activeCodePage effective on Windows 10, version 1903 or later Both of these manifest attributes are affecting the runtime behavior of an application running on Windows - but only starting from a certain OS version. That means - effectively you would end up having an ffmpeg executable with three different kinds of behavior: 1. Win < 1607 2. Win >= 1607 && < 1903 3. Win >= 1903 An ffmpeg executable, where you can't rely on the exposed behavior being consistent and where you would need to check the operating system version before using to make sure that you are providing parameters in the "right" way - I'm not sure whether that would make much sense. 3. All Patches x/6 - Remove MAX_PATH limit The punch line sounds compelling. But how is the current situation and what exactly would be the benefit? What's important to understand is that the basic Windows file APIs are supporting long (> MAX_PATH length) for a long time already. MS has just been a bit hesitant regarding the transition and wanted to avoid breaking changes to the API. The outcome was that long paths are only supported when using a lower-level path syntax, which is as simple as prepending "\\?\" to the actual path, no matter whether drive or UNC network path. As an example, the following command runs without issue on Windows with a normal current ffmpeg build: .\ffmpeg.exe -i "\\?\U:\TestMedia\This is a very long path - This is a very long path - This is a very long path - This is a very long path - This is a very long path -\This is a very long path - This is a very long path - This is a very long path - This is a very lon\aaaaaaaaaaaaaassssssssssssssdddddddddd\TestMediaThis is a very long path - This is a very long path - This is a very long path - This is a very long path - This is a very long path -This is a very long path - This is a very long path - Thi - 不要抬头.ts" It's not only a path with len > MAX_PATH, the name also includes Chinese (non-ANSI) characters. All this is working in a predictable and reliable way on all common Windows versions. Recently, MS have taken additional effort in order to ease compatibility and improve platform portability, by allowing applications to use ANSI file APIs with long paths and UTF-8 charset. BUT: there are several prerequisites for this to work: 1. Windows version needs to be >= 1903 (for being able to have both attributes in effect) 2. Application needs to be compiled with and manifest file as resource 3. A registry key or group policy needs to be set on Windows to enable this ´ (in both cases, administrative permission/UAC is required to set it) 4. Even when registry key or group policy is set, it might still be pending a reboot SUMMARY From my understanding, the benefit of this patchset would be: When 1. and 2. and 3. and 4. are fulfilled (and only then) - it would be possible to use long path names in ffmpeg _without_ prefixing it with '\\?\' On the other side, there's a risk of regressions by adding those manifest attributes. I wonder whether it wouldn’t be a better idea, to simply auto-add this prefix in the ffmpeg file handling code if: - OS == Windows - len > MAX_PATH This would work on all common Windows versions and would be predictable and reliable. Best regards, softworkz _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
