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

[Soft Works <softworkz@hotmail.com>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Martin Storsjö
> Sent: Monday, April 25, 2022 3:02 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
> utf8toansi
> 
> On Mon, 25 Apr 2022, Hendrik Leppkes wrote:
> 
> > On Mon, Apr 25, 2022 at 1:12 PM Soft Works <softworkz@hotmail.com>
> wrote:
> >>
> >> 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.
> >
> > "We have already worked around this problem in our deployment,
> > therefore there is no need to try to improve it" is surely not a
> very
> > strong argument.
> >
> > Will your work-around continue to work? Yes.
> > Will the changes actually impact anyone negatively? No known case is
> > documented, here or otherwise.
> > Will this change objectively improve the operation of ffmpeg on
> > Windows? Maybe not for everyone (yet), but certainly it'll allow it
> to
> > do so in controlled environments.
> >
> > I'm not seeing a good argument here to generally block the patch on,
> > as this entire thread boils down to .. what? Fear of change?
> > Unless you can demonstrate an actual problem resulting from applying
> > this patch, this line of arguments seems not very productive.
> 
> +1, I agree here.
> 
> Asking users to manually use \\?\ paths isn't something we should
> recommend as solution.
> 
> Internally prepending \\?\ when necessary could work (and would also
> be a
> possible fix, which at least would fix everything that goes through
> avio),
> but that's clearly much more risky than just adding a mostly-noop
> manifest. (And that only works for absolute paths; it requires some
> path
> munging logic to be able to do that.) I wouldn't mind going that way
> too,
> but the current patchset seems risk free to me.
> 
> FWIW, LLVM does something like that [1] - before opening files, it
> checks
> if a path seems to be too long, and if it is, it converts it into an
> absolute path and adds such a prefix. But that's clearly more risky
> and
> more nontrivial than this patchset.

I see it the other way round.

This patchset does not provide reliable behavior. This way, you won't 
be able to use long paths with ffmpeg within the next 5-8 years at minimum,
because even in the latest versions of Windows 11, this is not enabled by 
default in the operating system.

What is the value of adding a capability where it will be a lottery
game whether it will work or not on each system?

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-request@ffmpeg.org with subject "unsubscribe".