> ...
> > - 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
> -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
>
>
>
> > -
> -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&#
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
> 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
> 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
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
> -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
> 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,
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
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
11 matches
Mail list logo
