Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows

2022-06-13 Thread nil-admirari
> ... > > - defining NO_DSHOW_STRSAFE in libavcodec/mf_utils.h > ... > Or if we'd add the define projectwide in e.g. configure it probably > wouldn't be that bad? Kinda like how we already add > "-D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS" in MSVC builds. > Then we wouldn't need to wor

Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows

2022-06-09 Thread Soft Works
> -Original Message- > From: ffmpeg-devel On Behalf Of Soft Works > Sent: Thursday, June 9, 2022 10:16 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows > > > > > -

Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows

2022-06-09 Thread Soft Works
> -Original Message- > From: ffmpeg-devel On Behalf Of nil- > admir...@mailo.com > Sent: Thursday, June 9, 2022 10:58 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows > > > This error isn&#

Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows

2022-06-09 Thread Martin Storsjö
On Thu, 9 Jun 2022, nil-admir...@mailo.com wrote: This error isn't reproducible in git master - it's triggered by your yet-unmerged patches (that include wchar_filename.h in w32dlfcn.h). Ok. It can be fixed by either - defining NO_DSHOW_STRSAFE in libavcodec/mf_utils.h - or by migrating os_sup

Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows

2022-06-09 Thread nil-admirari
> This error isn't reproducible in git master - it's triggered by your > yet-unmerged patches (that include wchar_filename.h in w32dlfcn.h). Ok. It can be fixed by either - defining NO_DSHOW_STRSAFE in libavcodec/mf_utils.h - or by migrating os_support.h to StrSafe.h functions. Which way is pref

Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows

2022-06-09 Thread nil-admirari
> wcscpy is defined in corecrt_wstring.h, included in string.h, > included in winnt.h included in windef.h, included in windows.h Not so easy, it's the same as https://trac.ffmpeg.org/ticket/999: > In file included from /opt/ct-ng/i686-w64- > mingw32/sysroot/mingw/include/dshow.h:33 NO_DSHOW_ST

Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows

2022-06-09 Thread Martin Storsjö
On Thu, 9 Jun 2022, nil-admir...@mailo.com wrote: This looks fine to me, and the discussion seems to have converged, so I'll go ahead and push this. Build is now failing: https://github.com/yt-dlp/FFmpeg-Builds/runs/6819319105?check_suite_focus=true. In file included from /opt/ct-ng/i686-w6

Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows

2022-06-09 Thread Soft Works
> -Original Message- > From: ffmpeg-devel On Behalf Of nil- > admir...@mailo.com > Sent: Thursday, June 9, 2022 9:37 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows > > > This looks fine to m

Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows

2022-06-09 Thread nil-admirari
> This looks fine to me, and the discussion seems to have converged, so I'll > go ahead and push this. Build is now failing: https://github.com/yt-dlp/FFmpeg-Builds/runs/6819319105?check_suite_focus=true. In file included from /opt/ct-ng/i686-w64-mingw32/sysroot/mingw/include/dshow.h:33,

Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows

2022-06-09 Thread Martin Storsjö
On Thu, 26 May 2022, ffmpegagent wrote: This patchset adds support for long file and directory paths on Windows. The implementation follows the same logic that .NET is using internally, with the only exception that it doesn't expand short path components in 8.3 format. .NET does this as the same

Re: [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows

2022-05-26 Thread Martin Storsjö
On Thu, 26 May 2022, ffmpegagent wrote: This patchset adds support for long file and directory paths on Windows. The implementation follows the same logic that .NET is using internally, with the only exception that it doesn't expand short path components in 8.3 format. .NET does this as the same