[FFmpeg-devel] [FFmpeg-cvslog] w32pthreads: always use Vista+ API, drop XP support

[Hendrik Leppkes]

On Tue, Jan 2, 2018 at 2:05 PM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> On Tue, Jan 02, 2018 at 10:36:44AM +0100, Hendrik Leppkes wrote:
>> On Tue, Jan 2, 2018 at 4:28 AM, Michael Niedermayer
>> <michael at niedermayer.cc> wrote:
>> > On Tue, Jan 02, 2018 at 03:58:14AM +0100, Michael Niedermayer wrote:
>> >> On Tue, Jan 02, 2018 at 03:55:18AM +0100, Michael Niedermayer wrote:
>> >> > On Tue, Dec 26, 2017 at 01:50:08AM +0000, wm4 wrote:
>> >> > > ffmpeg | branch: master | wm4 <nfxjfg at googlemail.com> | Thu Dec 21 20:23:14 2017 +0100| [9b121dfc32810250938021952aab4172a988cb56] | committer: wm4
>> >> > >
>> >> > > w32pthreads: always use Vista+ API, drop XP support
>> >> > >
>> >> > > This removes the XP compatibility code, and switches entirely to SWR
>> >> > > locks, which are available starting at Windows Vista.
>> >> > >
>> >> > > This removes CRITICAL_SECTION use, which allows us to add
>> >> > > PTHREAD_MUTEX_INITIALIZER, which will be useful later.
>> >> > >
>> >> > > Windows XP is hereby not a supported build target anymore. It was
>> >> > > decided in a project vote that this is OK.
>> >> > >
>> >> > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=9b121dfc32810250938021952aab4172a988cb56
>> >> > > ---
>> >> > >
>> >> > >  Changelog                  |   2 +
>> >> > >  compat/w32pthreads.h       | 266 ++-------------------------------------------
>> >> > >  configure                  |  13 ++-
>> >> > >  libavcodec/pthread_frame.c |   4 -
>> >> > >  libavcodec/pthread_slice.c |   4 -
>> >> > >  libavfilter/pthread.c      |   4 -
>> >> > >  libavutil/slicethread.c    |   4 -
>> >> > >  7 files changed, 19 insertions(+), 278 deletions(-)
>> >> >
>> >> > This breaks mingw32 / wine support on ubuntu 14.04
>> >> > the code simply crashes at runtime
>> >>
>> >> Heres what wine provides as debug info:
>> >>
>> >> Unhandled exception: unimplemented function KERNEL32.dll.InitializeConditionVariable called in 32-bit code (0x7bc4e590).
>> >
>> > and thats mingw64:
>> > Unhandled exception: unimplemented function KERNEL32.dll.InitializeConditionVariable called in 64-bit code (0x00002ae6eb445e38).
>> > Register dump:
>> >  rip:00002ae6eb445e38 rsp:000000000032e150 rbp:0000000000099840 eflags:00000206 (   - --  I   - -P- )
>> >  rax:00002ae6eb445df0 rbx:000000000032e170 rcx:000000000032e170 rdx:0000000140c31e80
>> >  rsi:000000014199182c rdi:0000000141992788  r8:000000000000000f  r9:0000000000000000 r10:00002ae6eb6dfd6f
>> >  r11:00002ae6eb1ae510 r12:0000000000000000 r13:00000000000b4580 r14:000000007b8883b0 r15:0000000000330000
>> > Stack dump:
>> > 0x000000000032e150:  000000000032e170 000000007b888429
>> > 0x000000000032e160:  416e6f6974706972 4474654770616300
>> > 0x000000000032e170:  0000000180000100 0000000000000000
>> > 0x000000000032e180:  00002ae6eb445e38 0000000000000002
>> > 0x000000000032e190:  0000000141992788 000000014199182c
>> > 0x000000000032e1a0:  0000000000000000 0000000000000000
>> > 0x000000000032e1b0:  0000000000000000 0000000000000000
>> > 0x000000000032e1c0:  0000000000000000 ffffffffffff0000
>> > 0x000000000032e1d0:  0000000000000000 0000000000000000
>> > 0x000000000032e1e0:  0000000000000000 0000000000000000
>> > 0x000000000032e1f0:  0000000000000000 0000000000000000
>> > 0x000000000032e200:  00000000000b44c0 00000000000b44c0
>> > Backtrace:
>> > =>0 0x00002ae6eb445e38 in ntdll (+0x35e38) (0x0000000000099840)
>> >   1 0x0000000140c31e80 in ffmpeg (+0xc31e7f) (0x0000000000099840)
>> >   2 0x000000014003e6dd in ffmpeg (+0x3e6dc) (0x0000000000099840)
>> >   3 0x00000001400364ba in ffmpeg (+0x364b9) (0x0000000000099840)
>> >   4 0x000000014002f8b3 in ffmpeg (+0x2f8b2) (0x0000000000099840)
>> >   5 0x0000000140030355 in ffmpeg (+0x30354) (0x000000000032e4b0)
>> >   6 0x000000014000d478 in ffmpeg (+0xd477) (0x0000000000000001)
>> >
>>
>> Yeah the compilation environment doesn't matter if Wine doesn't
>> implement the function, so both mingw32 and mingw64 behave the same.
>> I don't think (old) Wine is something we should worry too much about,
>> considering you can just use native Linux builds, I doubt any real
>> usage occurs for FFmpeg through Wine.
>
> Almost all windows testing i did over the years is through mingw + wine.
> If that doesnt work anymore, then i cannot (easily) test windows anymore.
>
> Someone else should in this case do that testing in the future.
> That means in practice, testing as many patches as possible and HEAD
> bisecting found issues and reporting them to the developers whos commits
> where the first to show an issue.
>

Upgrading Wine is not an option? The wine project itself provides
Ubuntu packages for 14.04 as well, and even their "stable" version is
2.0, much newer then the 1.6 that ships with 14.04 by default.

- Hendrik