https://bugs.winehq.org/show_bug.cgi?id=54935
Bug ID: 54935 Summary: Rewrite (VN): black screen videos with WMP backend and gstreamer Product: Wine Version: 7.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winegstreamer Assignee: wine-bugs@winehq.org Reporter: timoninvlad@yandex.ru Distribution: ---
Created attachment 74457 --> https://bugs.winehq.org/attachment.cgi?id=74457 Wine logs with WINEDEBUG=quartz
Game has 2 options for video playback, MCI and Windows Media Player (WMP).
When using gstreamer, MCI backend works fine, but WMP floods the terminal with `err:quartz:send_buffer Failed to get a sample, hr 0x80040211.` while showing a black screen, then audio starts playing.
Curiously, if you install `lavfilters` from `winetricks` so that gstreamer isn't used, then WMP plays the video back properly.
The black screen started to show up since ed2c300d02acefa2aedd4333ff4a982137c1d4fe (after 7.6).
Wine logs with `WINEDEBUG=quartz` are attached in the archive. Before the regression (6f1b3cf9), with first bad commit (ed2c300d) and current master (8.8, 5662d85e).
Trial version of the game can be downloaded from Download section here: https://key.visualarts.gr.jp/rewrite/index2.html
Game can be extracted directly from `RewriteTE_Ver200/StartData/GameData` in the archive.
To set it up you'll need: - `LANG=ja_JP.UTF8` and `TZ=Japan` environment variables, game refuses to start otherwise - `winetricks wmp9` for WMP backend to work, game crashes otherwise when it's used, installer might say "It was not possible to complete Setup" which is fine - MPEG-1 codec from `lib32-gst-plugins-bad` for the opening video
When starting up the game, hold Ctrl to get to the main menu faster.
Video backend can be configured in Config - ムービー設定 (https://user-images.githubusercontent.com/20689137/126137253-0fe05ddc-2187-4...), should be WMP by default.
To exit Config, right click or click on 戻る in bottom-right corner.
Click Start on the main menu, then hold Ctrl to skip until the opening video.
https://bugs.winehq.org/show_bug.cgi?id=54935
Vladislav Timonin timoninvlad@yandex.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |ed2c300d02acefa2aedd4333ff4 | |a982137c1d4fe Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=54935
Vladislav Timonin timoninvlad@yandex.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |timoninvlad@yandex.ru
--- Comment #1 from Vladislav Timonin timoninvlad@yandex.ru --- Created attachment 74659 --> https://bugs.winehq.org/attachment.cgi?id=74659 Workaround hack
Tried bisecting further, reverting parts of ed2c300d02acefa2aedd4333ff4a982137c1d4fe, ce9a42e8bda50fd5eb91c8dee78f310881d2c7e5 and 6c11a4af5885c6485a908ea5c547e072fe71aa23 works around the issue on current master (c47c4d54bdf9a0f2100045fb6bc163291960fa05).
Should've also mentioned that if game doesn't gracefully end video playback (i.e. due to a crash), next time it will ask to either skip the video (再生しない) or pick a backend and play the video (決定（再生する）).
https://bugs.winehq.org/show_bug.cgi?id=54935
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl --- The hack is somewhat strange. Reminds me a bit of mr2815, yet that one was about compressed content...
https://bugs.winehq.org/show_bug.cgi?id=54935
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #3 from Zeb Figura z.figura12@gmail.com --- Sorry for the late response. I can't seem to launch the game event with TZ=Japan LC_ALL=ja_JP.UTF-8; it pops up a message box saying "This Game is Japan Only"?
https://bugs.winehq.org/show_bug.cgi?id=54935
--- Comment #4 from Vladislav Timonin timoninvlad@yandex.ru --- That's the refusing to start bit. Looks like if `ja_JP.UTF-8 UTF-8` isn't enabled in `/etc/locale.gen`, then `LANG=ja_JP.UTF8` won't take effect and game won't start. Maybe that's the issue.
https://bugs.winehq.org/show_bug.cgi?id=54935
--- Comment #5 from Zeb Figura z.figura12@gmail.com --- (In reply to Vladislav Timonin from comment #4)
That's the refusing to start bit. Looks like if `ja_JP.UTF-8 UTF-8` isn't enabled in `/etc/locale.gen`, then `LANG=ja_JP.UTF8` won't take effect and game won't start. Maybe that's the issue.
I think the locale part is working fine though, since it definitely wasn't rendering the text correctly until I changed LC_ALL.
I do notice you used only LANG though; maybe that makes a difference...
https://bugs.winehq.org/show_bug.cgi?id=54935
--- Comment #6 from Zeb Figura z.figura12@gmail.com --- Ok, TZ=Asia/Tokyo works instead. Thanks Jinoh Kang for the tip.
https://bugs.winehq.org/show_bug.cgi?id=54935
--- Comment #7 from Zeb Figura z.figura12@gmail.com --- This application is creative. It uses RenderFile(), but also sets up an IAMGraphBuilderCallback that apparently checks for IVMRSurfaceAllocatorNotify and rejects the filter if found, so we end up using the GDI video renderer instead. Then it disconnects the filter from the renderer and interposes its own (it does this with the audio side too, but this is unimportant).
That filter connects successfully to both ends, but the upstream connection is YV12 and the downstream is BGRx, and it doesn't seem to like that. [Annoyingly, it fails in a rather odd way—it connects successfully, but provides its own allocator which later fails in GetBuffer(). This made the bug annoyingly hard to debug.] Not sure if it doesn't like YUV or if it doesn't like the mismatch, or what.
Why did this work before? Well, quartz proposes the GStreamer preferred format first. wg_parser_stream_get_preferred_format() was *intended* to return the preferred format but actually ends up reporting the *current* format, sort of. The effect is that if we call wg_parser_stream_enable() that changes the first format that the DirectShow filter exposes. In this case it means that the second connection, to the application's filter, would use the previously selected BGRx format. The important part of ed2c300d02 is that it deferred setting the wg_parser format until *play* time.
Arguably wg_parser_stream_get_preferred_format() should be fixed, and this is probably true, but fixing it won't fix this bug.
Normally I'd figure that we should be connecting with an RGB format, but tests show that's not the case. The native MPEG-1 video decoder doesn't expose YV12, but it does expose YUY2 (before any RGB formats), which fails in the exact same way.
So I'm kind of struggling to see how this is supposed to work on Windows.
https://bugs.winehq.org/show_bug.cgi?id=54935
--- Comment #8 from Zeb Figura z.figura12@gmail.com --- Ugh, I managed to miss one critical line in the log. It's not failing the callback because it doesn't want the VMR. It's failing apparently because it's trying to configure the VMR from within the callback and it's too much of a stub. This'll need some work.
https://bugs.winehq.org/show_bug.cgi?id=54935
blubban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |blubban@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=54935
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |2b6035fcff40fa9ccc1f74e9afa | |2fac42b80ab4a Resolution|--- |FIXED Component|winegstreamer |quartz
--- Comment #9 from Zeb Figura z.figura12@gmail.com --- It seems to work completely for me after https://source.winehq.org/git/wine.git/commitdiff/2b6035fcff40fa9ccc1f74e9afa2fac42b80ab4a.
https://bugs.winehq.org/show_bug.cgi?id=54935
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.12.
-
WineHQ Bugzilla