From: Soft Works <softworkz@hotmail.com>
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
Date: Mon, 25 Apr 2022 13:17:16 +0000
Message-ID: <DM8P223MB03655D4603E93381AC5CDFE7BAF89@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CA+anqdzv7nqUz=eP99H5QED-dOqbm+LbbLzESHcCy8Ug_Feg5g@mail.gmail.com>
> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Hendrik Leppkes
> Sent: Monday, April 25, 2022 2:52 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, 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.
You may want to read this:
https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
> 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?
Pardon?
Seems you missed my point (probably you haven't followed the full conversation).
What I'm saying is that prepending the long path prefix is the better way
for supporting long paths and I mentioned our experience with it only to
confirm that it's working well.
The .NET/corefx runtime uses the prefix method internally, rclone is using it,
the Java runtime is using it, just to name a few examples.
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".
next prev parent reply other threads:[~2022-04-25 13:17 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-24 12:08 nil-admirari
2022-04-24 22:04 ` Soft Works
2022-04-25 9:03 ` nil-admirari
2022-04-25 9:31 ` Soft Works
2022-04-25 9:51 ` nil-admirari
2022-04-25 11:12 ` Soft Works
2022-04-25 12:51 ` Hendrik Leppkes
2022-04-25 13:02 ` Martin Storsjö
2022-04-25 13:36 ` Soft Works
2022-04-29 19:08 ` nil-admirari
2022-04-25 13:17 ` Soft Works [this message]
2022-04-29 18:59 ` nil-admirari
2022-04-29 18:52 ` nil-admirari
2022-04-30 12:34 ` Soft Works
2022-05-05 20:20 ` nil-admirari
2022-05-05 22:38 ` Soft Works
2022-05-06 16:07 ` nil-admirari
2022-05-07 2:57 ` Soft Works
2022-05-07 17:33 ` nil-admirari
2022-05-07 17:59 ` Soft Works
2022-05-10 21:22 ` nil-admirari
2022-05-10 22:59 ` Soft Works
2022-05-10 23:32 ` Soft Works
2022-05-11 7:46 ` Tobias Rapp
2022-05-11 7:57 ` Soft Works
2022-05-11 8:08 ` Hendrik Leppkes
2022-05-11 9:03 ` nil-admirari
2022-05-11 13:32 ` Tobias Rapp
2022-05-11 20:50 ` Soft Works
2022-05-11 8:57 ` nil-admirari
2022-05-14 0:42 ` Soft Works
2022-05-15 19:53 ` nil-admirari
2022-05-15 20:34 ` Soft Works
2022-05-16 8:49 ` nil-admirari
2022-05-08 19:48 ` Martin Storsjö
2022-04-25 20:51 ` Stephen Hutchinson
2022-04-29 19:25 ` nil-admirari
-- strict thread matches above, loose matches on Subject: below --
2022-04-23 20:56 Nil Admirari
2022-04-24 3:39 ` Soft Works
2022-05-07 17:57 ` Soft Works
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM8P223MB03655D4603E93381AC5CDFE7BAF89@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM \
--to=softworkz@hotmail.com \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git