> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of nil- > admir...@mailo.com > Sent: Monday, April 25, 2022 11:52 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v11 1/6] > libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and > utf8toansi > > > Again, you have deleted my asking for an example scenario > > and which library would need to be loaded from a long path. > > Because I don't think that an example would be relevant.
A code change for which no use case exists and does not provide any benefit is not relevant. That's my point. > > For the longpaths attribute, you could surely argue that it's "just" > > that you don't know whether it will work or not. > > But forcing a different code page for a process _IS_ a fundamental > > alteration. > > Which is necessary for compatibility with AviSynth, and commit message > says exactly that: https://ffmpeg.org/pipermail/ffmpeg-devel/2022- > April/295572.html. Yes, I understand. You want to make a fundamental change to ffmpeg because of AviSynth. > > I'm restoring the line of your own question which you have deleted: > > > > > > Is it a big deal to change a registry and reboot? > > My response to that was: > > ... > > Really? I answer your question and then you delete your question > > and ask what my answer would have to do with the patchset? > > Sorry, I should've directly asked what: > > > 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 > > has to do with this patchset, instead of asking a rhetorical question > of whether > it's a big deal or not. 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. If not - I'm in no way authoritative for ffmpeg, others may have different opinions. 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. 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".