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 699B342066 for ; Mon, 25 Apr 2022 09:04:00 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 1B95E68B2BE; Mon, 25 Apr 2022 12:03:58 +0300 (EEST) Received: from msg-1.mailo.com (msg-1.mailo.com [213.182.54.11]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 7E65068AFF6 for ; Mon, 25 Apr 2022 12:03:51 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1650877430; bh=jR+vXF0Uedj1hcFGmKzGwXol2vbKlKuivjoU+q1kXR0=; h=X-EA-Auth:From:To:Date:Subject:MIME-Version:X-Mailer:Message-ID: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CxPa9z2AFbV8uNE5U5Qb5dE8ncjQxvLzlj0Qo4Ap14ge3qKx/zJWt4hPZvmtlDNVt OmRmlm/4z9IlFgE/hgngJUxKje3tmHQzKRNBcs5IjiSTeI6Lh0NsRIWDxOxYtKdh4w rxzKQET+rI5Gg+Ui8UEBMdyL4QcnYY8gCOafCHvg= Received: by www-7.mailo.com with http webmail; Mon, 25 Apr 2022 11:03:50 +0200 (CEST) X-EA-Auth: SLA1CfUV8bzmbgI3f5G2SQ7nfHo3ooRhf2BX2b/YTiQnRofBVoBUQwksKUMIikPxFP8nEtva8Q0vFYqKHjVoFsfrWC4D0lqn From: nil-admirari@mailo.com To: ffmpeg-devel@ffmpeg.org Date: Mon, 25 Apr 2022 11:03:50 +0200 (CEST) X-Priority: 3 MIME-Version: 1.0 X-Mailer: COMS/EA21.01/r20220415 Message-ID: In-Reply-To: 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: > You normally don't load libraries from such longs paths. And? 80% of FFmpeg functionality is normally not used. > But file IO is a fundamental feature where a common and predictable > behavior is crucial. You're talking as if the manifest change somehow broke or fundamentally altered file IO, which it clearly did not. > That's true, but the file IO in ffmpeg does not use MAX_PATH buffers, > so it's only about those few specific cases: I'm glad it doesn't use MAX_PATH everywhere. Takes only 6 pathes to fix, not a thousand. > Patch 2/6: Removing the fixed-size buffer is surely a good change, > but can't you just completely remove the charset > conversion and use the same file IO patterns that ffmpeg > is using everywhere else? If you were to look at the code, you would've seen that charset conversion was already there. AviSynth is not Unicode-aware, it expects ANSI strings. Inline charset conversion was replaced by a library call, which, again, was already there, only slightly extended. > Patch 4/6: Seems to be pointless because you cannot run ffmpeg.exe from > a long path anyway. Neither with cmd nor with powershell. > Even if you could, it would be a pretty exotic use case. This current limitation may disappear in a future version of Windows, the same way path limit disappeared. > And the servers? Servers have the same lifecycle as client versions do. > And all those which are still using older versions? For them manifest change is a no-op. > Yes it is. Especially when you don't know that it's needed or whether > it's needed or when it is needed. > Also it requires administrative permissions which not everybody has. > Further it's a serious change to OS behavior and you cannot expect that > all users are educated enough for being able to make this decision > and be confident that it won't have any unexpected side effects. What does all of that have to do with these patches? > That's what I tried to explain. "Any other patch" makes a change > after which you know that the change has been made. > > But adding those attributes will impose changes that will be effective > under certain conditions only and about which neither the user nor the > application "knows" whether they are effective or not. Before these patches FFmpeg cannot handle long paths. After these patches, it can. They are certainly not invisible. > No. There's are common file APIs where such change could be made. During the review of these patches it was found that parts FFmpeg use av_fopen_utf8, while others use plain fopen. There is no common file API. > PS: Your line breaks were all doubled. Please check before replying. Were normal in email client. I don't know how they got garbled. My previous messages didn't have such a problem. _______________________________________________ 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".