https://bugs.winehq.org/show_bug.cgi?id=56491
Bug ID: 56491 Summary: Videos in BURIKO visual novel engine Product: Wine Version: 9.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: quartz Assignee: wine-bugs@winehq.org Reporter: blubban@gmail.com Distribution: ---
The BURIKO aka Ethornell visual novel engine (seen in, for example, https://store.steampowered.com/app/1200720/MakingLovers/) demands two changes to Wine before videos will work.
First, FilterGraph2_AddSourceFilter() must return the exact value VFW_E_NOT_FOUND if the input filename is an empty string. (Nonexistent files return HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND) in both Windows and Wine; BURIKO doesn't care.)
Second, it calls FilterGraph2_Render(), with the source pin offering a normal MPEG video; this chooses CLSID_decodebin_parser. BURIKO doesn't particularly care which filters are plugged, but it does demand that the autoplug process calls ReceiveConnection() at least once with .formattype = FORMAT_MPEGVideo or FORMAT_MPEG2Video; the app will reject that format, but it extracts and memorizes the .hdr.bmiHeader.biWidth/biHeight fields, and ignores the resolution in the subsequent FORMAT_VideoInfo.
BURIKO ignores every other field of the MPEG format type, so it's fine to pass (for example) majortype=GUID_NULL subtype=GUID_NULL formattype=FORMAT_MPEGVideo, or a normal RGB24 AM_MEDIA_TYPE except with formattype replaced (could even leave the cbSize a few bytes smaller than a MPEG1VIDEOINFO).
(Third, it looks like there's a memory leak at https://gitlab.winehq.org/wine/wine/-/blob/wine-9.5/dlls/quartz/filtergraph...., I think that path should call IBaseFilter_Release. This won't fix any existing programs, I just saw it while I was already in the area.)
I could submit an MR for those, but I can't think of a clean way to implement the second one, so I'd rather have some discussion on how to best solve this before I implement something that could be wrong.
https://bugs.winehq.org/show_bug.cgi?id=56491
--- Comment #1 from blubban@gmail.com --- After thinking about it some more, I guess the best solution is make CLSID_decodebin_parser offer the codec_format on its pins. In the unlikely case that the peer accepts that format, decodebin_parser will recreate its wg_parser with the read_compressed flag, like the WMSyncReader.
(And, like WMSyncReader, hope that nobody wants compressed audio and uncompressed video.)
I'll get to work on that.
https://bugs.winehq.org/show_bug.cgi?id=56491
Sagawa sagawa.aki+winebugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sagawa.aki+winebugs@gmail.c | |om
--- Comment #2 from Sagawa sagawa.aki+winebugs@gmail.com --- Hi. From my point of view, the second part seems to be what CLSID_MPEG1Splitter does. Thus, what do you think about prioritizing CLSID_MPEG1Splitter over CLSID_decodebin_parser for MPEG1 videos? Have you already tried this?
https://bugs.winehq.org/show_bug.cgi?id=56491
--- Comment #3 from blubban@gmail.com --- I've considered that, yes, but rejected it. It would require sending compressed MPEG frames from GStreamer to Wine, then sending them right back to GStreamer; these extra copies and thread synchronization operations may have a performance impact, including in programs that don't want MPEG data. Which is every single one, including BURIKO; it needs to see the MPEG media type, but it doesn't want any MPEG data.
Instead, I've told decodebin_parser to offer its codec_format, and if accepted, recreate the wg_parser with a different output format. Seems to work, but the gitlab bot seems to be on easter vacation and didn't assign a code reviewer. https://gitlab.winehq.org/wine/wine/-/merge_requests/5419
https://bugs.winehq.org/show_bug.cgi?id=56491
blubban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |6a3bec8e3f3feaf372ed5778daa | |67f374780b51a
--- Comment #4 from blubban@gmail.com --- Fix merged, I guess this issue isn't needed anymore
https://bugs.winehq.org/show_bug.cgi?id=56491
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.7.