http://bugs.winehq.org/show_bug.cgi?id=23175
Summary: Zak McKracken - Between Time and Space fails to play back intro video Product: Wine Version: 1.2-rc3 Platform: x86 URL: http://www.mckracken.net/cms/die-fortsetzung/download. html OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: arethusa26@gmail.com
Created an attachment (id=28827) --> (http://bugs.winehq.org/attachment.cgi?id=28827) Zak McKracken - Between Time and Space output
After starting Zak McKracken - Between Time and Space and waiting for the loading animation to complete, an intro video is supposed to be played, but only the audio portion of the video is played back correctly, and the video is simply rendered as black for the duration.
http://bugs.winehq.org/show_bug.cgi?id=23175
--- Comment #1 from Andrew Nguyen arethusa26@gmail.com 2010-09-26 19:10:15 CDT --- As a workaround, Jörg Höhle suggests that installing ffdshow from winetricks and using native avifil32 makes the intro video for the game work, which I can confirm.
http://bugs.winehq.org/show_bug.cgi?id=23175
--- Comment #2 from Andrew Nguyen arethusa26@gmail.com 2010-09-26 19:12:22 CDT --- (In reply to comment #1)
As a workaround, Jörg Höhle suggests that installing ffdshow from winetricks and using native avifil32 makes the intro video for the game work, which I can confirm.
Actually, I think the avifil32 native override might not be necessary; just the ffdshow seems to please the game.
http://bugs.winehq.org/show_bug.cgi?id=23175
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=23175
--- Comment #3 from Bruno Jesus 00cpxxx@gmail.com 2013-06-27 13:09:41 CDT --- Still in wine 1.6-rc3.
https://bugs.winehq.org/show_bug.cgi?id=23175
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
https://bugs.winehq.org/show_bug.cgi?id=23175
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Zak McKracken - Between |Zak McKracken - Between |Time and Space fails to |Time and Space fails to |play back intro video |play back intro video | |(ICM_DECOMPRESS_GET_FORMAT | |problems with Xvid) Component|-unknown |msvfw32
--- Comment #4 from Bruno Jesus 00cpxxx@gmail.com --- I remember this problem from years ago, I tried contacting Xvid developers to no response.
In the process of reproducing video Wine issues a ICM_DECOMPRESS_GET_FORMAT message so that the codec can fill the output structure with the correct output video frame information, but unfortunately Xvid (unlike every other codec) checks the output data before filling it (!?) with the requested information.
That is why the log varies depending on the attempt to run, different garbage is present in lpbiOut when the message is sent to the codec.
So probably wine implements this in a little bit different way since it works in Windows.
There are 2 separate problems. The problem starts in msvfw32/msvideo_main.c:ICGetDisplayFormat because:
738 ICSendMessage(tmphic, ICM_DECOMPRESS_GET_FORMAT, (DWORD_PTR)lpbiIn, (DWORD_PTR)lpbiOut); 739 740 if (lpbiOut->biCompression != 0) { 741 FIXME("Ooch, how come decompressor outputs compressed data (%d)? ?\n", 742 lpbiOut->biCompression); 743 }
The return of ICSendMessage is not checked, so the rest of IF conditions are tested over garbage when ICSendMessage returns error (in this case ICERR_BADFORMAT).
Anyway, the main problem is in how to request for the output format in a way Xvid does not complain.
https://bugs.winehq.org/show_bug.cgi?id=23175
--- Comment #5 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 54099 --> https://bugs.winehq.org/attachment.cgi?id=54099 patch
Patch to fix this, probably not 100% correct.
https://bugs.winehq.org/show_bug.cgi?id=23175
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |dmitry@baikal.ru, | |erich.e.hoover@wine-staging | |.com, michael@fds-team.de, | |sebastian@fds-team.de Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/msvfw32-ICGetD | |isplayFormat
https://bugs.winehq.org/show_bug.cgi?id=23175
--- Comment #6 from Bruno Jesus 00cpxxx@gmail.com --- The staged patch does not fix this issue, at least for me. It looks like it tries to find a suitable format manually instead of asking for the driver and then ends up finding something somehow.
trace:msvideo:ICLocate => 0x1 trace:msvideo:ICGetDisplayFormat (0x1,0x1e0838,0x1d7d98,0,-1,-1)! trace:msvideo:MSVIDEO_SendMessage (0x19cfc0,ICM_DECOMPRESS_QUERY,0x001e0838,0x00000000) trace:msvideo:MSVIDEO_SendMessage -> ICERR_OK trace:msvideo:MSVIDEO_SendMessage (0x19cfc0,ICM_DECOMPRESS_GET_FORMAT,0x001e0838,0x001d7d98) trace:msvideo:MSVIDEO_SendMessage -> ICERR_BADFORMAT trace:msvideo:MSVIDEO_SendMessage (0x19cfc0,ICM_DECOMPRESS_QUERY,0x001e0838,0x001d7d98) trace:msvideo:MSVIDEO_SendMessage -> ICERR_BADFORMAT trace:msvideo:MSVIDEO_SendMessage (0x19cfc0,ICM_DECOMPRESS_GET_FORMAT,0x001e0838,0x001d7d98) trace:msvideo:MSVIDEO_SendMessage -> ICERR_BADFORMAT trace:msvideo:ICGetDisplayFormat => 0
But all decompress operations fail:
trace:msvideo:ICDecompress (0x1,0,0x1e0838,0x1e0860,0x1d7d98,0x1d7dc0) trace:msvideo:MSVIDEO_SendMessage (0x19cfc0,ICM_DECOMPRESS,0x0032ccd4,0x00000018) trace:msvideo:MSVIDEO_SendMessage -> ICERR_OK trace:msvideo:ICDecompress -> ICERR_OK trace:msvideo:DrawDibDraw (0x1,0x30003d,0,0,512,342,0x1d7d98,0x1d7d98,0,0,0,0,0x00000004) trace:msvideo:ICDecompress (0x1,0,0x1e0838,0x1e0860,0x1d7d98,0x1d7dc0) trace:msvideo:MSVIDEO_SendMessage (0x19cfc0,ICM_DECOMPRESS,0x0d7ce6b4,0x00000018) trace:msvideo:MSVIDEO_SendMessage -> ICERR_BADFORMAT trace:msvideo:ICDecompress -> ICERR_BADFORMAT trace:msvideo:ICDecompress (0x1,0,0x1e0838,0x1e0860,0x1d7d98,0x1d7dc0) trace:msvideo:MSVIDEO_SendMessage (0x19cfc0,ICM_DECOMPRESS,0x0d7ce6b4,0x00000018) trace:msvideo:MSVIDEO_SendMessage -> ICERR_BADFORMAT ...
https://bugs.winehq.org/show_bug.cgi?id=23175
--- Comment #7 from Bruno Jesus 00cpxxx@gmail.com --- I actually mean "ends up NOT finding a suitable format".
Just to make it clear, with or without the patch the problem is the same, decompression error due to bad response in the GET_FORMAT message. Xvid will check for 4 items in the output to fill the format:
biBitCount biWidth biHeight biCompression
They must be the same as input, except biCompression which must be BI_RGB.
https://bugs.winehq.org/show_bug.cgi?id=23175
--- Comment #8 from super_man@post.com --- libpng warning: iCCP: known incorrect sRGB profile Input #0, matroska,webm, from 'video.vv059': Metadata: encoder : libebml v0.7.7 + libmatroska v0.8.1 creation_time : 2014-08-19 09:47:52 Duration: 00:00:04.04, start: 0.000000, bitrate: 1685 kb/s Stream #0:0: Video: vp8, yuv420p, 1920x1080, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn, 1k tbc (default) Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp (default) [swscaler @ 1123A380] No accelerated colorspace conversion found from yuv420p to rgb24. libpng warning: iCCP: known incorrect sRGB profile Input #0, matroska,webm, from 'video.vv069': Metadata: encoder : libebml v0.7.7 + libmatroska v0.8.1 creation_time : 2014-11-19 17:57:43 Duration: 00:00:05.00, start: 0.000000, bitrate: 2460 kb/s Stream #0:0: Video: vp8, yuv420p, 1024x576, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn, 1k tbc (default) Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp (default) [swscaler @ 11339FC0] No accelerated colorspace conversion found from yuv420p to rgb24.
Without any patches.
https://bugs.winehq.org/show_bug.cgi?id=23175
--- Comment #9 from Michael Müller michael@fds-team.de --- I have updated the patchset, could you try the new version? I think the problem should be fixed now. The version of the game provided in the URL field does no longer use VFW so I couldn't test it.
The reason why the the first patch failed was that the game passes -1 as dx and dy. Unlike the MSDN states, dx and dy are not scaling factors but absolute values (shown by my tests), so my patch would request an image with the size -1 x -1. This doesn't cause a problem on Windows as the function just ignores negative values, although it might make sense to request a negative dy to flip the image. I updated the patch accordingly.
https://bugs.winehq.org/show_bug.cgi?id=23175
--- Comment #10 from Bruno Jesus 00cpxxx@gmail.com --- The patch set works. I'm still concerned that the driver call is not checked (which seems to always succeed for every codec that is not Xvid).
And that the tests have a fixed good output values before calling get format. It is always 320x240x16, in the case of this specific bug for example the output is always garbage since the caller is not expected to fill the output.
https://bugs.winehq.org/show_bug.cgi?id=23175
--- Comment #11 from Bruno Jesus 00cpxxx@gmail.com --- Unrelated note:
I don't remember if ASD-Lifeforce (bug 14695) also uses ICM_DECOMPRESS_GET_FORMAT but if it does maybe your patch would find a suitable format for it now. I tried testing but it is not launching in the computer I'm using.
https://bugs.winehq.org/show_bug.cgi?id=23175
--- Comment #12 from super_man@post.com --- (In reply to Bruno Jesus from comment #11)
Unrelated note:
I don't remember if ASD-Lifeforce (bug 14695) also uses ICM_DECOMPRESS_GET_FORMAT but if it does maybe your patch would find a suitable format for it now. I tried testing but it is not launching in the computer I'm using.
I just tested, doesn't help.
https://bugs.winehq.org/show_bug.cgi?id=23175
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/msvfw32-ICGetD |er/patches/msvfw32-ICGetDis |isplayFormat |playFormat
https://bugs.winehq.org/show_bug.cgi?id=23175
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |fb7f937305f9242c675d4ff9a79 | |76cf121710159 Status|STAGED |RESOLVED
--- Comment #13 from Gijs Vermeulen gijsvrm@gmail.com --- The patchset, which was verified to fix the problem in Comment #10, was upstreamed, marking FIXED.
https://bugs.winehq.org/show_bug.cgi?id=23175
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #14 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.4.
-
wine-bugs＠winehq.org