| Message ID | 20220520211254.47116-1-martin@martin.st |
|---|---|
| State | Accepted |
| Commit | 3fb924464244bc317a5d19ab25625ae35abde512 |
| Headers | show |
| Series | [FFmpeg-devel,1/3] fftools: Stop using av_fopen_utf8 | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Martin > Storsjö > Sent: Friday, May 20, 2022 11:13 PM > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 > > Provide a header based inline reimplementation of it. > > Using av_fopen_utf8 doesn't work outside of the libraries when built > with MSVC as shared libraries (in the default configuration, where > each DLL gets a separate statically linked CRT). > --- > fftools/ffmpeg_opt.c | 3 +- > fftools/fopen_utf8.h | 71 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 73 insertions(+), 1 deletion(-) > create mode 100644 fftools/fopen_utf8.h > > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c > index 47e8b9b7bd..a5cd989d35 100644 > --- a/fftools/ffmpeg_opt.c > +++ b/fftools/ffmpeg_opt.c > @@ -28,6 +28,7 @@ > #endif > > #include "ffmpeg.h" > +#include "fopen_utf8.h" > #include "cmdutils.h" > #include "opt_common.h" > > @@ -1882,7 +1883,7 @@ static OutputStream *new_video_stream(OptionsContext > *o, AVFormatContext *oc, in > video_enc->stats_in = logbuffer; > } > if (video_enc->flags & AV_CODEC_FLAG_PASS1) { > - f = av_fopen_utf8(logfilename, "wb"); > + f = fopen_utf8(logfilename, "wb"); > if (!f) { > av_log(NULL, AV_LOG_FATAL, > "Cannot write log file '%s' for pass-1 > encoding: %s\n", > diff --git a/fftools/fopen_utf8.h b/fftools/fopen_utf8.h > new file mode 100644 > index 0000000000..db57fcaec4 > --- /dev/null > +++ b/fftools/fopen_utf8.h > @@ -0,0 +1,71 @@ > +/* > + * This file is part of FFmpeg. > + * > + * FFmpeg is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * FFmpeg is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with FFmpeg; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110- > 1301 USA > + */ > + > +#ifndef FFTOOLS_FOPEN_UTF8_H > +#define FFTOOLS_FOPEN_UTF8_H > + > +#include <stdio.h> > + > +/* The fopen_utf8 function here is essentially equivalent to > av_fopen_utf8, > + * except that it doesn't set O_CLOEXEC, and that it isn't exported > + * from a different library. (On Windows, each DLL might use a different > + * CRT, and FILE* handles can't be shared across them.) */ > + > +#ifdef _WIN32 > +#include "libavutil/wchar_filename.h" > + > +static inline FILE *fopen_utf8(const char *path_utf8, const char *mode) > +{ > + wchar_t *path_w, *mode_w; > + FILE *f; > + > + /* convert UTF-8 to wide chars */ > + if (utf8towchar(path_utf8, &path_w)) /* This sets errno on error. */ > + return NULL; > + if (!path_w) > + goto fallback; > + > + if (utf8towchar(mode, &mode_w)) > + return NULL; > + if (!mode_w) { > + /* If failing to interpret the mode string as utf8, it is an > invalid > + * parameter. */ > + av_freep(&path_w); > + errno = EINVAL; > + return NULL; > + } > + > + f = _wfopen(path_w, mode_w); > + av_freep(&path_w); > + av_freep(&mode_w); > + > + return f; > +fallback: > + /* path may be in CP_ACP */ > + return fopen(path_utf8, mode); > +} > + > +#else > + > +static inline FILE *fopen_utf8(const char *path, const char *mode) > +{ > + return fopen(path, mode); > +} > +#endif > + > +#endif /* FFTOOLS_FOPEN_UTF8_H */ > -- LGTM. (all three) Tested with VS project build (full static linkage, though). Thank you, sw
On Sat, 21 May 2022, Soft Works wrote: >> -----Original Message----- >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Martin >> Storsjö >> Sent: Friday, May 20, 2022 11:13 PM >> To: ffmpeg-devel@ffmpeg.org >> Subject: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 >> >> Provide a header based inline reimplementation of it. >> >> Using av_fopen_utf8 doesn't work outside of the libraries when built >> with MSVC as shared libraries (in the default configuration, where >> each DLL gets a separate statically linked CRT). >> --- >> fftools/ffmpeg_opt.c | 3 +- >> fftools/fopen_utf8.h | 71 ++++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 73 insertions(+), 1 deletion(-) >> create mode 100644 fftools/fopen_utf8.h >> >> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c >> index 47e8b9b7bd..a5cd989d35 100644 >> --- a/fftools/ffmpeg_opt.c >> +++ b/fftools/ffmpeg_opt.c >> @@ -28,6 +28,7 @@ >> #endif >> >> #include "ffmpeg.h" >> +#include "fopen_utf8.h" >> #include "cmdutils.h" >> #include "opt_common.h" >> >> @@ -1882,7 +1883,7 @@ static OutputStream *new_video_stream(OptionsContext >> *o, AVFormatContext *oc, in >> video_enc->stats_in = logbuffer; >> } >> if (video_enc->flags & AV_CODEC_FLAG_PASS1) { >> - f = av_fopen_utf8(logfilename, "wb"); >> + f = fopen_utf8(logfilename, "wb"); >> if (!f) { >> av_log(NULL, AV_LOG_FATAL, >> "Cannot write log file '%s' for pass-1 >> encoding: %s\n", >> diff --git a/fftools/fopen_utf8.h b/fftools/fopen_utf8.h >> new file mode 100644 >> index 0000000000..db57fcaec4 >> --- /dev/null >> +++ b/fftools/fopen_utf8.h >> @@ -0,0 +1,71 @@ >> +/* >> + * This file is part of FFmpeg. >> + * >> + * FFmpeg is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU Lesser General Public >> + * License as published by the Free Software Foundation; either >> + * version 2.1 of the License, or (at your option) any later version. >> + * >> + * FFmpeg is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> + * Lesser General Public License for more details. >> + * >> + * You should have received a copy of the GNU Lesser General Public >> + * License along with FFmpeg; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110- >> 1301 USA >> + */ >> + >> +#ifndef FFTOOLS_FOPEN_UTF8_H >> +#define FFTOOLS_FOPEN_UTF8_H >> + >> +#include <stdio.h> >> + >> +/* The fopen_utf8 function here is essentially equivalent to >> av_fopen_utf8, >> + * except that it doesn't set O_CLOEXEC, and that it isn't exported >> + * from a different library. (On Windows, each DLL might use a different >> + * CRT, and FILE* handles can't be shared across them.) */ >> + >> +#ifdef _WIN32 >> +#include "libavutil/wchar_filename.h" >> + >> +static inline FILE *fopen_utf8(const char *path_utf8, const char *mode) >> +{ >> + wchar_t *path_w, *mode_w; >> + FILE *f; >> + >> + /* convert UTF-8 to wide chars */ >> + if (utf8towchar(path_utf8, &path_w)) /* This sets errno on error. */ >> + return NULL; >> + if (!path_w) >> + goto fallback; >> + >> + if (utf8towchar(mode, &mode_w)) >> + return NULL; >> + if (!mode_w) { >> + /* If failing to interpret the mode string as utf8, it is an >> invalid >> + * parameter. */ >> + av_freep(&path_w); >> + errno = EINVAL; >> + return NULL; >> + } >> + >> + f = _wfopen(path_w, mode_w); >> + av_freep(&path_w); >> + av_freep(&mode_w); >> + >> + return f; >> +fallback: >> + /* path may be in CP_ACP */ >> + return fopen(path_utf8, mode); >> +} >> + >> +#else >> + >> +static inline FILE *fopen_utf8(const char *path, const char *mode) >> +{ >> + return fopen(path, mode); >> +} >> +#endif >> + >> +#endif /* FFTOOLS_FOPEN_UTF8_H */ >> -- > > LGTM. (all three) > > Tested with VS project build (full static linkage, though). I discussed this with Anton on irc, and he was ok with the patchset too, so I pushed it now. // Martin
> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Martin > Storsjö > Sent: Monday, May 23, 2022 12:53 PM > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 > > On Sat, 21 May 2022, Soft Works wrote: > > >> -----Original Message----- > >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > Martin > >> Storsjö > >> Sent: Friday, May 20, 2022 11:13 PM > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 > >> > >> Provide a header based inline reimplementation of it. > >> > >> Using av_fopen_utf8 doesn't work outside of the libraries when built > >> with MSVC as shared libraries (in the default configuration, where > >> each DLL gets a separate statically linked CRT). > >> --- > >> fftools/ffmpeg_opt.c | 3 +- > >> fftools/fopen_utf8.h | 71 ++++++++++++++++++++++++++++++++++++++++++++ > >> 2 files changed, 73 insertions(+), 1 deletion(-) > >> create mode 100644 fftools/fopen_utf8.h > >> > >> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c > >> index 47e8b9b7bd..a5cd989d35 100644 > >> --- a/fftools/ffmpeg_opt.c > >> +++ b/fftools/ffmpeg_opt.c > >> @@ -28,6 +28,7 @@ > >> #endif > >> > >> #include "ffmpeg.h" > >> +#include "fopen_utf8.h" > >> #include "cmdutils.h" > >> #include "opt_common.h" > >> > >> @@ -1882,7 +1883,7 @@ static OutputStream > *new_video_stream(OptionsContext > >> *o, AVFormatContext *oc, in > >> video_enc->stats_in = logbuffer; > >> } > >> if (video_enc->flags & AV_CODEC_FLAG_PASS1) { > >> - f = av_fopen_utf8(logfilename, "wb"); > >> + f = fopen_utf8(logfilename, "wb"); > >> if (!f) { > >> av_log(NULL, AV_LOG_FATAL, > >> "Cannot write log file '%s' for pass-1 > >> encoding: %s\n", > >> diff --git a/fftools/fopen_utf8.h b/fftools/fopen_utf8.h > >> new file mode 100644 > >> index 0000000000..db57fcaec4 > >> --- /dev/null > >> +++ b/fftools/fopen_utf8.h > >> @@ -0,0 +1,71 @@ > >> +/* > >> + * This file is part of FFmpeg. > >> + * > >> + * FFmpeg is free software; you can redistribute it and/or > >> + * modify it under the terms of the GNU Lesser General Public > >> + * License as published by the Free Software Foundation; either > >> + * version 2.1 of the License, or (at your option) any later version. > >> + * > >> + * FFmpeg is distributed in the hope that it will be useful, > >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of > >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > >> + * Lesser General Public License for more details. > >> + * > >> + * You should have received a copy of the GNU Lesser General Public > >> + * License along with FFmpeg; if not, write to the Free Software > >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > 02110- > >> 1301 USA > >> + */ > >> + > >> +#ifndef FFTOOLS_FOPEN_UTF8_H > >> +#define FFTOOLS_FOPEN_UTF8_H > >> + > >> +#include <stdio.h> > >> + > >> +/* The fopen_utf8 function here is essentially equivalent to > >> av_fopen_utf8, > >> + * except that it doesn't set O_CLOEXEC, and that it isn't exported > >> + * from a different library. (On Windows, each DLL might use a > different > >> + * CRT, and FILE* handles can't be shared across them.) */ > >> + > >> +#ifdef _WIN32 > >> +#include "libavutil/wchar_filename.h" > >> + > >> +static inline FILE *fopen_utf8(const char *path_utf8, const char > *mode) > >> +{ > >> + wchar_t *path_w, *mode_w; > >> + FILE *f; > >> + > >> + /* convert UTF-8 to wide chars */ > >> + if (utf8towchar(path_utf8, &path_w)) /* This sets errno on error. > */ > >> + return NULL; > >> + if (!path_w) > >> + goto fallback; > >> + > >> + if (utf8towchar(mode, &mode_w)) > >> + return NULL; > >> + if (!mode_w) { > >> + /* If failing to interpret the mode string as utf8, it is an > >> invalid > >> + * parameter. */ > >> + av_freep(&path_w); > >> + errno = EINVAL; > >> + return NULL; > >> + } > >> + > >> + f = _wfopen(path_w, mode_w); > >> + av_freep(&path_w); > >> + av_freep(&mode_w); > >> + > >> + return f; > >> +fallback: > >> + /* path may be in CP_ACP */ > >> + return fopen(path_utf8, mode); > >> +} > >> + > >> +#else > >> + > >> +static inline FILE *fopen_utf8(const char *path, const char *mode) > >> +{ > >> + return fopen(path, mode); > >> +} > >> +#endif > >> + > >> +#endif /* FFTOOLS_FOPEN_UTF8_H */ > >> -- > > > > LGTM. (all three) > > > > Tested with VS project build (full static linkage, though). > > I discussed this with Anton on irc, and he was ok with the patchset too, > so I pushed it now. > > // Martin Great, thanks. Shall I update mine now to cover the remaining fopen() calls? sw
On Mon, 23 May 2022, Soft Works wrote: > > >> -----Original Message----- >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Martin >> Storsjö >> Sent: Monday, May 23, 2022 12:53 PM >> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> >> Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 >> >> On Sat, 21 May 2022, Soft Works wrote: >> >>> LGTM. (all three) >>> >>> Tested with VS project build (full static linkage, though). >> >> I discussed this with Anton on irc, and he was ok with the patchset too, >> so I pushed it now. >> >> // Martin > > Great, thanks. > > Shall I update mine now to cover the remaining fopen() calls? Yep, that sounds good to me. It should be easier to move forward with the uncontroversial parts of the patchsets now. // Martin
> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Martin > Storsjö > Sent: Monday, May 23, 2022 12:58 PM > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 > > On Mon, 23 May 2022, Soft Works wrote: > > > > > > >> -----Original Message----- > >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > Martin > >> Storsjö > >> Sent: Monday, May 23, 2022 12:53 PM > >> To: FFmpeg development discussions and patches <ffmpeg- > devel@ffmpeg.org> > >> Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using > av_fopen_utf8 > >> > >> On Sat, 21 May 2022, Soft Works wrote: > >> > >>> LGTM. (all three) > >>> > >>> Tested with VS project build (full static linkage, though). > >> > >> I discussed this with Anton on irc, and he was ok with the patchset > too, > >> so I pushed it now. > >> > >> // Martin > > > > Great, thanks. > > > > Shall I update mine now to cover the remaining fopen() calls? > > Yep, that sounds good to me. It should be easier to move forward with the > uncontroversial parts of the patchsets now. > > // Martin Sure, will do. I think I have addressed all concerns from the side of nil-admirari; the last point was the mapping of the stat() function, which - even though it works - could use a few more eyes taking a look at. Any other specific concerns from your side? Thanks, sw
On Mon, 23 May 2022, Soft Works wrote: >> -----Original Message----- >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Martin >> Storsjö >> Sent: Monday, May 23, 2022 12:58 PM >> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> >> Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 >> >> On Mon, 23 May 2022, Soft Works wrote: >> >>> >>> >>>> -----Original Message----- >>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of >> Martin >>>> Storsjö >>>> Sent: Monday, May 23, 2022 12:53 PM >>>> To: FFmpeg development discussions and patches <ffmpeg- >> devel@ffmpeg.org> >>>> Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using >> av_fopen_utf8 >>>> >>>> On Sat, 21 May 2022, Soft Works wrote: >>>> >>>>> LGTM. (all three) >>>>> >>>>> Tested with VS project build (full static linkage, though). >>>> >>>> I discussed this with Anton on irc, and he was ok with the patchset >> too, >>>> so I pushed it now. >>>> >>>> // Martin >>> >>> Great, thanks. >>> >>> Shall I update mine now to cover the remaining fopen() calls? >> >> Yep, that sounds good to me. It should be easier to move forward with the >> uncontroversial parts of the patchsets now. >> >> // Martin > > Sure, will do. > > I think I have addressed all concerns from the side of nil-admirari; > the last point was the mapping of the stat() function, which - > even though it works - could use a few more eyes taking a look at. > > Any other specific concerns from your side? I haven't followed your discussion closely (I was waiting for it to converge, which it apparently mostly has) so I haven't got anything to add offhand right now. I can try to read through the latest iteration (or the next one if rebased and reposted) and give a more qualified opinion in a day or two. // Martin
> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Martin > Storsjö > Sent: Monday, May 23, 2022 1:12 PM > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 > > On Mon, 23 May 2022, Soft Works wrote: > > >> -----Original Message----- > >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > Martin > >> Storsjö > >> Sent: Monday, May 23, 2022 12:58 PM > >> To: FFmpeg development discussions and patches <ffmpeg- > devel@ffmpeg.org> > >> Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using > av_fopen_utf8 > >> > >> On Mon, 23 May 2022, Soft Works wrote: > >> > >>> > >>> > >>>> -----Original Message----- > >>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > >> Martin > >>>> Storsjö > >>>> Sent: Monday, May 23, 2022 12:53 PM > >>>> To: FFmpeg development discussions and patches <ffmpeg- > >> devel@ffmpeg.org> > >>>> Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using > >> av_fopen_utf8 > >>>> > >>>> On Sat, 21 May 2022, Soft Works wrote: > >>>> > >>>>> LGTM. (all three) > >>>>> > >>>>> Tested with VS project build (full static linkage, though). > >>>> > >>>> I discussed this with Anton on irc, and he was ok with the patchset > >> too, > >>>> so I pushed it now. > >>>> > >>>> // Martin > >>> > >>> Great, thanks. > >>> > >>> Shall I update mine now to cover the remaining fopen() calls? > >> > >> Yep, that sounds good to me. It should be easier to move forward with > the > >> uncontroversial parts of the patchsets now. > >> > >> // Martin > > > > Sure, will do. > > > > I think I have addressed all concerns from the side of nil-admirari; > > the last point was the mapping of the stat() function, which - > > even though it works - could use a few more eyes taking a look at. > > > > Any other specific concerns from your side? > > I haven't followed your discussion closely (I was waiting for it to > converge, which it apparently mostly has) so I haven't got anything to add > offhand right now. I can try to read through the latest iteration (or the > next one if rebased and reposted) and give a more qualified opinion in a > day or two. Great. I rebased and resubmitted both patchsets. The primary long-path patchset didn't need any change. Considerations for the latter were: - Should the file wchar_filename.h be renamed as it is now containing the path prefixing code? - I have kept the path functions in the same way like .NET does it, just for easy reference and following. Compilers will inline them anyway (my pov). Maybe others don't like that. I can change if it's got to be. - The one ugliness is the copied struct for the mapping of the stat function. Maybe there's some tricky way to get around doing so, I just couldn't find any. I'm very confident about the core functionality, though (due to it origin). Thanks again, sw
On Mon, 23 May 2022, Soft Works wrote: > Great. I rebased and resubmitted both patchsets. The primary long-path > patchset didn't need any change. > > Considerations for the latter were: > > - Should the file wchar_filename.h be renamed as it is now containing > the path prefixing code? I guess we could do that later at some point, but I don't see it as urgent. > - I have kept the path functions in the same way like .NET does it, > just for easy reference and following. Compilers will inline > them anyway (my pov). Maybe others don't like that. I can change > if it's got to be. Having the individual functions inline compared to merging it all in one big function doesn't matter to me. But the amount of code in this inline header is growing a bit big, to the point that I think it is measurable when multiple files within the same library use these functions. Longer term, it would probably make sense to make them more shared in some way. If C would have the C++ style deduplication feature for non-static inline functions, this wouldn't be an issue. One could consider making them ff_ functions and carry a copy in each library too, maybe. (But that also makes it trickier to use in fftools.) Not entirely urgent yet anyway. // Martin
> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Martin > Storsjö > Sent: Tuesday, May 24, 2022 11:29 AM > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 > > On Mon, 23 May 2022, Soft Works wrote: > > > Great. I rebased and resubmitted both patchsets. The primary long-path > > patchset didn't need any change. > > > > Considerations for the latter were: > > > > - Should the file wchar_filename.h be renamed as it is now containing > > the path prefixing code? > > I guess we could do that later at some point, but I don't see it as > urgent. > > > - I have kept the path functions in the same way like .NET does it, > > just for easy reference and following. Compilers will inline > > them anyway (my pov). Maybe others don't like that. I can change > > if it's got to be. > > Having the individual functions inline compared to merging it all in one > big function doesn't matter to me. But the amount of code in this inline > header is growing a bit big, to the point that I think it is measurable > when multiple files within the same library use these functions. Longer > term, it would probably make sense to make them more shared in some way. > If C would have the C++ style deduplication feature for non-static inline > functions, this wouldn't be an issue. One could consider making them ff_ > functions and carry a copy in each library too, maybe. (But that also > makes it trickier to use in fftools.) A copy in each library - isn't that exactly what's already happening? The get_extended_win32_path() is used from 2 places: 1. file_open.c For this, we already have copies in each library. file_open.c includes wchar_filename.h and the new functions are inlined into file_open.obj. So, there's only one copy in each library 2. os_support.h This is used in libavformat exclusively. But in this case, the code gets duplicated actually for each consumption of one of those file functions. There aren't many usages in total, though, and I don't see any trend on the horizon for sudden increase, so I agree that there's no urgency. BTW, thanks for your other comments, I have added the missing av_free() calls and included URLs to the .NET source. I chose to use permalinks. These are long and ugly, but they have changed their structure (and even repo) so often during the past years, that chances are low that the non-versioned links would still be valid in a few years (I wouldn't even bet on months :-) softworkz
On Tue, 24 May 2022, Soft Works wrote: >> -----Original Message----- >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Martin >> Storsjö >> Sent: Tuesday, May 24, 2022 11:29 AM >> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> >> Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 >> >> On Mon, 23 May 2022, Soft Works wrote: >> >>> Great. I rebased and resubmitted both patchsets. The primary long-path >>> patchset didn't need any change. >>> >>> Considerations for the latter were: >>> >>> - Should the file wchar_filename.h be renamed as it is now containing >>> the path prefixing code? >> >> I guess we could do that later at some point, but I don't see it as >> urgent. >> >>> - I have kept the path functions in the same way like .NET does it, >>> just for easy reference and following. Compilers will inline >>> them anyway (my pov). Maybe others don't like that. I can change >>> if it's got to be. >> >> Having the individual functions inline compared to merging it all in one >> big function doesn't matter to me. But the amount of code in this inline >> header is growing a bit big, to the point that I think it is measurable >> when multiple files within the same library use these functions. Longer >> term, it would probably make sense to make them more shared in some way. > >> If C would have the C++ style deduplication feature for non-static inline >> functions, this wouldn't be an issue. One could consider making them ff_ >> functions and carry a copy in each library too, maybe. (But that also >> makes it trickier to use in fftools.) > > A copy in each library - isn't that exactly what's already happening? > > The get_extended_win32_path() is used from 2 places: > > 2. os_support.h > > This is used in libavformat exclusively. But in this case, the code gets > duplicated actually for each consumption of one of those file functions. > There aren't many usages in total, though, and I don't see any trend > on the horizon for sudden increase, so I agree that there's no urgency. Yes, this is what I was referring to. It's clearly more than one use. When counting files that use mkdir, unlink or "struct stat", I find around 9 individual .c files in libavformat, that would end up with static inline copies of all of this. Compared with the av_fopen_utf8 case, I first tested fixing it by making it a static inline function in a libavutil header, but that did increase the size of a built DLL by a couple KB. I guess this increases it by a bit more than that. It's still not a lot, and this isn't a blocker (and I probably prefer that we don't try to redesign this issue here now, in order not to drag out the review further), but compared to how C++ inline methods are deduplicated by the linker, it's a slightly annoying inefficiency. // Martin
> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Martin > Storsjö > Sent: Tuesday, May 24, 2022 10:22 PM > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 > > On Tue, 24 May 2022, Soft Works wrote: > > >> -----Original Message----- > >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > Martin > >> Storsjö > >> Sent: Tuesday, May 24, 2022 11:29 AM > >> To: FFmpeg development discussions and patches <ffmpeg- > devel@ffmpeg.org> > >> Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using > av_fopen_utf8 > >> > >> On Mon, 23 May 2022, Soft Works wrote: > >> > >>> Great. I rebased and resubmitted both patchsets. The primary long-path > >>> patchset didn't need any change. > >>> > >>> Considerations for the latter were: > >>> > >>> - Should the file wchar_filename.h be renamed as it is now containing > >>> the path prefixing code? > >> > >> I guess we could do that later at some point, but I don't see it as > >> urgent. > >> > >>> - I have kept the path functions in the same way like .NET does it, > >>> just for easy reference and following. Compilers will inline > >>> them anyway (my pov). Maybe others don't like that. I can change > >>> if it's got to be. > >> > >> Having the individual functions inline compared to merging it all in > one > >> big function doesn't matter to me. But the amount of code in this > inline > >> header is growing a bit big, to the point that I think it is measurable > >> when multiple files within the same library use these functions. Longer > >> term, it would probably make sense to make them more shared in some > way. > > > >> If C would have the C++ style deduplication feature for non-static > inline > >> functions, this wouldn't be an issue. One could consider making them > ff_ > >> functions and carry a copy in each library too, maybe. (But that also > >> makes it trickier to use in fftools.) > > > > A copy in each library - isn't that exactly what's already happening? > > > > The get_extended_win32_path() is used from 2 places: > > > > 2. os_support.h > > > > This is used in libavformat exclusively. But in this case, the code gets > > duplicated actually for each consumption of one of those file functions. > > There aren't many usages in total, though, and I don't see any trend > > on the horizon for sudden increase, so I agree that there's no urgency. > > Yes, this is what I was referring to. It's clearly more than one use. When > counting files that use mkdir, unlink or "struct stat", I find around 9 > individual .c files in libavformat, that would end up with static inline > copies of all of this. > > Compared with the av_fopen_utf8 case, I first tested fixing it by making > it a static inline function in a libavutil header, but that did increase > the size of a built DLL by a couple KB. I guess this increases it by a > bit more than that. > > It's still not a lot, and this isn't a blocker (and I probably prefer that > we don't try to redesign this issue here now, in order not to drag out the > review further) I'm glad you're saying that ;-) It probably won't be difficult to improve this in a future change, making it a wchar_filename.c plus wchar_filename.h file in libavutil. If I'm not mistaken, there shouldn't be an issue with multiple CRTs as memory is managed by av_ functions? Thanks, sw
On Tue, 24 May 2022, Soft Works wrote: >> -----Original Message----- >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Martin >> Storsjö >> Sent: Tuesday, May 24, 2022 10:22 PM >> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> >> Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 >> >> On Tue, 24 May 2022, Soft Works wrote: >> >>>> -----Original Message----- >>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of >> Martin >>>> Storsjö >>>> Sent: Tuesday, May 24, 2022 11:29 AM >>>> To: FFmpeg development discussions and patches <ffmpeg- >> devel@ffmpeg.org> >>>> Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using >> av_fopen_utf8 >>>> >>>> On Mon, 23 May 2022, Soft Works wrote: >>>> >>>>> Great. I rebased and resubmitted both patchsets. The primary long-path >>>>> patchset didn't need any change. >>>>> >>>>> Considerations for the latter were: >>>>> >>>>> - Should the file wchar_filename.h be renamed as it is now containing >>>>> the path prefixing code? >>>> >>>> I guess we could do that later at some point, but I don't see it as >>>> urgent. >>>> >>>>> - I have kept the path functions in the same way like .NET does it, >>>>> just for easy reference and following. Compilers will inline >>>>> them anyway (my pov). Maybe others don't like that. I can change >>>>> if it's got to be. >>>> >>>> Having the individual functions inline compared to merging it all in >> one >>>> big function doesn't matter to me. But the amount of code in this >> inline >>>> header is growing a bit big, to the point that I think it is measurable >>>> when multiple files within the same library use these functions. Longer >>>> term, it would probably make sense to make them more shared in some >> way. >>> >>>> If C would have the C++ style deduplication feature for non-static >> inline >>>> functions, this wouldn't be an issue. One could consider making them >> ff_ >>>> functions and carry a copy in each library too, maybe. (But that also >>>> makes it trickier to use in fftools.) >>> >>> A copy in each library - isn't that exactly what's already happening? >>> >>> The get_extended_win32_path() is used from 2 places: >>> >>> 2. os_support.h >>> >>> This is used in libavformat exclusively. But in this case, the code gets >>> duplicated actually for each consumption of one of those file functions. >>> There aren't many usages in total, though, and I don't see any trend >>> on the horizon for sudden increase, so I agree that there's no urgency. >> >> Yes, this is what I was referring to. It's clearly more than one use. When >> counting files that use mkdir, unlink or "struct stat", I find around 9 >> individual .c files in libavformat, that would end up with static inline >> copies of all of this. >> >> Compared with the av_fopen_utf8 case, I first tested fixing it by making >> it a static inline function in a libavutil header, but that did increase >> the size of a built DLL by a couple KB. I guess this increases it by a >> bit more than that. >> >> It's still not a lot, and this isn't a blocker (and I probably prefer that >> we don't try to redesign this issue here now, in order not to drag out the >> review further) > > I'm glad you're saying that ;-) > > It probably won't be difficult to improve this in a future change, making it > a wchar_filename.c plus wchar_filename.h file in libavutil. If I'm not > mistaken, there shouldn't be an issue with multiple CRTs as memory is > managed by av_ functions? Indeed, that's not a problem for plain filename conversions. The main hesitation is that we'd generally want to avoid adding more avpriv_ APIs unless strictly necessary. // Martin
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c index 47e8b9b7bd..a5cd989d35 100644 --- a/fftools/ffmpeg_opt.c +++ b/fftools/ffmpeg_opt.c @@ -28,6 +28,7 @@ #endif #include "ffmpeg.h" +#include "fopen_utf8.h" #include "cmdutils.h" #include "opt_common.h" @@ -1882,7 +1883,7 @@ static OutputStream *new_video_stream(OptionsContext *o, AVFormatContext *oc, in video_enc->stats_in = logbuffer; } if (video_enc->flags & AV_CODEC_FLAG_PASS1) { - f = av_fopen_utf8(logfilename, "wb"); + f = fopen_utf8(logfilename, "wb"); if (!f) { av_log(NULL, AV_LOG_FATAL, "Cannot write log file '%s' for pass-1 encoding: %s\n", diff --git a/fftools/fopen_utf8.h b/fftools/fopen_utf8.h new file mode 100644 index 0000000000..db57fcaec4 --- /dev/null +++ b/fftools/fopen_utf8.h @@ -0,0 +1,71 @@ +/* + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef FFTOOLS_FOPEN_UTF8_H +#define FFTOOLS_FOPEN_UTF8_H + +#include <stdio.h> + +/* The fopen_utf8 function here is essentially equivalent to av_fopen_utf8, + * except that it doesn't set O_CLOEXEC, and that it isn't exported + * from a different library. (On Windows, each DLL might use a different + * CRT, and FILE* handles can't be shared across them.) */ + +#ifdef _WIN32 +#include "libavutil/wchar_filename.h" + +static inline FILE *fopen_utf8(const char *path_utf8, const char *mode) +{ + wchar_t *path_w, *mode_w; + FILE *f; + + /* convert UTF-8 to wide chars */ + if (utf8towchar(path_utf8, &path_w)) /* This sets errno on error. */ + return NULL; + if (!path_w) + goto fallback; + + if (utf8towchar(mode, &mode_w)) + return NULL; + if (!mode_w) { + /* If failing to interpret the mode string as utf8, it is an invalid + * parameter. */ + av_freep(&path_w); + errno = EINVAL; + return NULL; + } + + f = _wfopen(path_w, mode_w); + av_freep(&path_w); + av_freep(&mode_w); + + return f; +fallback: + /* path may be in CP_ACP */ + return fopen(path_utf8, mode); +} + +#else + +static inline FILE *fopen_utf8(const char *path, const char *mode) +{ + return fopen(path, mode); +} +#endif + +#endif /* FFTOOLS_FOPEN_UTF8_H */