https://bugs.winehq.org/show_bug.cgi?id=53903
--- Comment #17 from Opinsys Developers <bugzilla-wine(a)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
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.