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.