https://bugs.winehq.org/show_bug.cgi?id=25180
--- Comment #16 from Michael Müller michael@fds-team.de --- (In reply to Bruno Jesus from comment #15)
It is interesting that forcing 32 bpp would make the video work. The input video is supposed to be 24 so I expected the output to be 24 too.
I don't force anything. My tests show that the ICGetDisplayFormat implementation behaves in the same way as on Windows. If you think that the video output should be 24 bit, then the problem is located in a different part of Wine. I would also prefer to see tests backing up your statements instead of wild guesses.
Writing tests could be a bit difficult though since the whole playback is done by wine code. The application uses MCI to playback the video:
---- trace:mci:mciSendStringW verb=L"open" on dev=L"c:\prog~fbu\clon~jdk\splash.c4v"; offset=8 trace:mci:MCI_ParseOptArgs args=L"type avivideo alias cp_splash_avi" trace:mci:MCI_ParseOptArgs flag=00002000 string=L"avivideo" trace:mci:MCI_ParseOptArgs args=L"alias cp_splash_avi" trace:mci:MCI_ParseOptArgs flag=00000400 string=L"cp_splash_avi" trace:mci:mciSendStringW (L"window cp_splash_avi handle 65626", (nil), 0, (nil)) trace:mci:mciSendStringW (L"put cp_splash_avi destination", (nil), 0, (nil)) trace:mci:mciSendStringW (L"play cp_splash_avi wait", (nil), 0, (nil)) ----
Nevertheless, I updated the patchset to fix the original bug with the 24 bit playback. The wrong rendering was caused by the call to StretchDIBits in MCIAVI_PaintFrame. The windows / wine GDI API expects a row stride which is dividable by 4 bytes and iccvid just sets stride = width. The stride requirements also apply for VFW and are explained in the MSDN, see "Calculating Surface Stride" at https://msdn.microsoft.com/de-de/library/windows/desktop/dd318229(v=vs.85).a.... The patchset fixes the problem in iccvid and msvidc32.