https://bugs.winehq.org/show_bug.cgi?id=44325
Bug ID: 44325 Summary: Microsoft Powerpoint 2010: hangs up when seeking mp4 video Product: Wine Version: 3.0-rc4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: winegstreamer Assignee: wine-bugs@winehq.org Reporter: deto.haz@gmail.com Distribution: ---
Microsoft Powerpoint 2010 hangs up when seeking playing video.
I have tried to install MS Office 2010 on Wine 3.0-rc4, everything works like a charm. I was able to embed and play mp4 videos (only mp4) with Powerpoint; but when seeking, Powerpoint was suspended and could not return.
But when I completely remove the audio channel from the file by "ffmpeg -i videoAndAudio.mp4 -c copy -an onlyVideo.mp4" command (only keep the video channel) and insert again, this hangup error has disappearred.
So when I rebuilt from source to reproduce this error, I found that the bug occurs at dlls/winegstreamer/gst_cbs.c:call_cb function, where wait for condition pthread_cond_wait(&cbdata->cond, &cbdata->lock); and somewhere in dlls/winegstreamer/gstdemux.c:dispatch_thread. May be there is a deadlock with the synchronization of the audio and video channel.
OS: Kubuntu 17.04 zesty MSOffice 2010 with no service pack riched20 (natice, builtin) msxml6 from winetricks (native, builtin)
libgstreamer1.0-0 libgstreamer-pligins-{bad,base,good}1.0-0
Give me feedback if you need more information.
Thanks & best regards Ha Binh Xuyen
https://bugs.winehq.org/show_bug.cgi?id=44325
--- Comment #1 from Deto Haz deto.haz@gmail.com --- The bug also occurs with wine-staging:2.15, wine-stable:2.0.4, may be some others but I have not tried with the same environments above.
https://bugs.winehq.org/show_bug.cgi?id=44325
--- Comment #2 from Deto Haz deto.haz@gmail.com --- I just found a new problem, the function EnterCriticalSection at function MediaSDeeking_GetCurrentPosition timeout, it makes a 60-second loop when seeking video because it has been blocked by the main thread at GST_Seeking_SetPositions.
https://bugs.winehq.org/show_bug.cgi?id=44325
--- Comment #3 from Deto Haz deto.haz@gmail.com --- Created attachment 60204 --> https://bugs.winehq.org/attachment.cgi?id=60204 Backtrace log
https://bugs.winehq.org/show_bug.cgi?id=44325
--- Comment #4 from Deto Haz deto.haz@gmail.com --- Created attachment 60205 --> https://bugs.winehq.org/attachment.cgi?id=60205 Full backtrace log
https://bugs.winehq.org/show_bug.cgi?id=44325
--- Comment #5 from Deto Haz deto.haz@gmail.com --- Here're backtrace logs generated by wine-3.0-rc5 which I built from original source when deadlock occurs with libgstreamer1.0-0 symbol. The mutex at frame 2 of thread 1 is being blocked by thread 35. Hope this helps.
https://bugs.winehq.org/show_bug.cgi?id=44325
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl --- Created attachment 60511 --> https://bugs.winehq.org/attachment.cgi?id=60511 gstreamer,quartz log of a different app
This might seem random and perhaps it actually is, but I'm seeing something that seems caused by this problem. Namely, a key press is supposed to trigger skipping of an intro movie, yet what actually happens is that while a/v output is stopped, app is unresponsive for about the time it takes the intro to be played back. After that time passes, execution continues as usual.
https://bugs.winehq.org/show_bug.cgi?id=44325
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl --- Minor detail: checked the time - regardless of the moment intro is interrupted, the wait afterwards takes the length of the whole intro from the start.
-
wine-bugs＠winehq.org