> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Martin Storsjö > Sent: Monday, April 25, 2022 3:02 PM > To: FFmpeg development discussions and patches <ffmpeg- > de...@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 <softwo...@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-requ...@ffmpeg.org with subject "unsubscribe".