https://bugs.winehq.org/show_bug.cgi?id=53903
--- Comment #17 from Opinsys Developers bugzilla-wine@opinsys.fi --- Hi,
The bug still exist in 9.2. The original video file referred in this bug report does not work in LoggerPro 3.16.2, but an error dialog displaying code 0xc00d5212 (seems to translate to MF_E_TOPO_CODEC_NOT_FOUND) is shown instead. When 9.2 is patched with attachment 76088, the video is loaded correctly and works as expected.
So, allowing BGRx output from the media source seems to fix the root problem.
However, with "large" video files, over 480p according to my tests, problems arise: the memory consumption skyrockets and eventually causes virtual memory allocations to fail. With 10sec 30FPS 1080p h264 video (attachment 76091), LoggerPro consumes ~1.5G memory (USS, observed with ps -eo uss) and video is not loaded correctly. From user's point of view, video loading eventually stops and a video window/widget appears, but all frames are black/grey. The video playback widget shows correct framecount, duration and all playback controls and the video can be played, but all frames are black.
Smaller video, 10sec 30FPS 320p h264 video (attachment 76090), is loaded correctly and works well.
This is also the case with Wine 8.7 and the RGB32 patch.
In Windows 11, LoggerPro 3.16.2 loads 1080p video (attachment 76091) without any problems. The memory consumption of LoggerPro, as observed with resource manager, is ~150MB.
So, in summary:
- Win 11, 1080p video: success - Wine 9.2, 1080p video: fail, 0xc00d5212 - Wine 9.2, 320p video: fail, 0xc00d5212 - Wine 9.2 BGRx patched, 1080p video: fail, memory allocation - Wine 9.2 BGRx patched, 320p video: success
I wonder if it's possible that the patch, while making BGRx output from the media source work, introduces uncontrollable memory consumption as a side effect?
--TuomasR