On Tue Oct 31 20:35:46 2023 +0000, Zebediah Figura wrote:
Bug 9127 is a bit of an odd case. Many applications want to decode MPEG-1 video but use high-level autoplugging to do it. Historically, we had an MPEG-1 parser in tree that only supported audio (and printed a FIXME for video), and did not rely on GStreamer, as well as the generic decodebin-based parser. This meant that anyone without a functional GStreamer installation would see that message, assume that our MPEG-1 parser needed to support video, and the bug would get resolved as a duplicate. Vanishingly few applications actually manually instantiate the MPEG-1 parser, so once we removed the in-tree MPEG-1 parser (well, rewrote it to use GStreamer) and started telling people to fix their GStreamer installations, those reports stopped contaminating bug 9127. To add to the lack of interest, `winetricks quartz` will work around that issue anyway.
So most of the 9127 watchers aren't actually looking for an MPEG splitter? That does indeed explain the lack of developer attention.
But Kirikiri does specifically instantiate that thing, and several applications named in that bug (including the Sayou one named in its URL field) are, in fact, Kirikiri. (My guess is that it's trying to ensure that it doesn't load third-party codecs like Combined Community Codec Pack; banning non-preinstalled codecs reduces the risk of worksforme bugs. That's the only explanation I can see for hardcoding a list of which media types it wants to see in WMV files. https://github.com/krkrz/krkr2/blob/dec49af97e174d31059c3ccd7efc700ba3c6b788...)
And since I want to run Kirikiri in Wine, my only choice is to tackle 9127 head-on.
I tried loading native quartz.dll into Wine in an attempt to investigate BUG-55649, but its VMR9 refuses to connect, because wined3d doesn't implement IDirect3DVideoDevice9. (I didn't check alternate backends, like DXVK.) For that reason, Kirikiri won't run under such a configuration either.