[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: Monday, April 25, 2022 11:52 AM
> To: ffmpeg-devel at 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