From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 768EB42685 for ; Mon, 25 Apr 2022 13:02:29 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B6AF868B29B; Mon, 25 Apr 2022 16:02:26 +0300 (EEST) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E6FBB68AF51 for ; Mon, 25 Apr 2022 16:02:20 +0300 (EEST) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 23PD2Jba024153-23PD2Jbb024153 for ; Mon, 25 Apr 2022 16:02:19 +0300 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id A2BE9A1513 for ; Mon, 25 Apr 2022 16:02:19 +0300 (EEST) Date: Mon, 25 Apr 2022 16:02:17 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: Message-ID: <4ce25d8b-efc0-2431-dc6-c2ad04d5f41@martin.st> References: MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-15"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Mon, 25 Apr 2022, Hendrik Leppkes wrote: > On Mon, Apr 25, 2022 at 1:12 PM Soft Works 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 condit= ions >> 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]=A0- 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. [1] https://github.com/llvm/llvm-project/blob/llvmorg-14.0.0/llvm/lib/Suppo= rt/Windows/Path.inc#L98-L124 // Martin _______________________________________________ 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".