[Bug]: VP9 Profile 1 dynamic background causes ~400 MiB/s repeated disk reads with Media Foundation

[shoucandanghehe]

Affected Version

Collapse 1.84.6

System Information

Redacted DxDiag.txt

Bug Behavior

When the Windows Media Foundation backend is used (GlobalIsUseFFmpeg=False), the current Honkai: Star Rail CN dynamic background causes CollapseLauncher.exe to continuously read approximately 382–419 MiB/s from disk.

All observed reads target only this cached background file:

%USERPROFILE%\AppData\LocalLow\CollapseLauncher\GameFolder\_img\e03cdbee1cd9f23890a912539cdbd24b_8411913511023477738.webm

The file is only 16,004,616 bytes and 5.35 seconds long. Collapse repeatedly rereads the entire file instead of playing it at the expected media bitrate. Pausing the dynamic background immediately stops the reads and switches to the static background.

The affected media is:

Codec: VP9 Profile 1
Pixel format: gbrp
Color/chroma: GBR 4:4:4, full range
Resolution: 1920x1080
Frame rate: 60 fps
Streams: video only
Frames: 321
Duration: 5.35 seconds

Its 321 presentation timestamps are valid and monotonically increase from 0 to 5.333 seconds. There are no duplicate or backwards timestamps.

Expected Behavior

Collapse should play the dynamic background with disk usage close to the encoded-media bitrate.

If the selected media backend cannot produce frames, Collapse should stop playback, log an actionable error, and fall back to the static background. It should not continuously reopen and reread the file.

Steps to reproduce

1. Run Collapse 1.84.6 on Windows 11.
2. Select the Honkai: Star Rail CN region using the affected dynamic background.
3. Let Collapse download/cache the background listed above.
4. Disable the FFmpeg video-background backend (GlobalIsUseFFmpeg=False).
5. Enable background autoplay.
6. Open the launcher home page.
7. Observe CollapseLauncher.exe disk reads in Resource Monitor, Process Explorer, or an ETW FileIO trace.
8. Pause the dynamic background and observe that the reads stop.

Observed in two independent process-counter samples:

Read throughput: 417–419 MiB/s
Read operations: approximately 1,670/s
Write throughput: 0

A two-second WPR FileIO trace recorded:

Physical DiskRead events from Collapse: 5,594
Bytes read: 764.75 MiB
Average throughput: 382.375 MiB/s
DiskWrite events: 0
Target files: only the affected WebM file

Related Issues

#885, #452, #572

These issues concern background loading, stuttering, or media-format compatibility, but none describe this repeated high-throughput disk-read loop.

Screenshot(s)

The behavior is an I/O loop rather than a visual-layout problem. The process-counter and ETW measurements are included above.

Additional Information

Isolated MediaPlayer reproduction

The behavior was reproduced outside Collapse with a minimal native C++/WinRT probe containing only:

• Windows.Media.Playback.MediaPlayer
• IsVideoFrameServerEnabled=true
• IsLoopingEnabled=true
• A BGRA Direct3D surface
• CopyFrameToVideoSurface from VideoFrameAvailable

With the original Profile 1 GBR 4:4:4 file:

Test duration: 6.00048 seconds
Bytes read: 2,331.25 MiB
Average throughput: 388.511 MiB/s
VideoFrameAvailable callbacks: 0
CopyFrameToVideoSurface errors: 0
MediaFailed events: 0
Playback position: always 0

This reproduces Collapse's disk behavior without any other Collapse code.

With IsLoopingEnabled=false, MediaPlayer produces no frames or errors, immediately reaches the 5.35-second end position, and then stops reading. The observed loop is therefore:

Media Foundation cannot produce a Direct3D frame
→ no VideoFrameAvailable and no MediaFailed
→ MediaPlayer treats the stream as having reached EOF
→ IsLoopingEnabled immediately reopens the media
→ the complete file is read again

The approximately 16 MB file is reopened around 25 times per second, producing the observed ~400 MiB/s reads.

Profile 0 control test

The same source was transcoded to VP9 Profile 0 yuv420p while retaining 1920x1080, 60 fps, and the same duration.

With IsLoopingEnabled=true, the converted file behaved normally:

Read throughput: approximately 1 MiB/s
VideoFrameAvailable callbacks: 473 over approximately 8 seconds
Playback position: progresses normally
MediaFailed events: 0

Other cached Collapse dynamic backgrounds inspected locally are also VP9 Profile 0 yuv420p or VP8 yuv420p.

This isolates the external trigger to:

VP9 Profile 1 GBR 4:4:4
+ Windows MediaPlayer frame-server mode
+ IsLoopingEnabled

Collapse currently enables both frame-server mode and looping here:

https://github.com/CollapseLauncher/Collapse/blob/24a2a1ba7084d9ced966dd07c6d07edcfcf46237/CollapseLauncher/XAMLs/Theme/CustomControls/LayeredBackgroundImage.Events.FrameInitializer.cs

The component also does not appear to handle MediaFailed. In this reproduction MediaPlayer does not raise that event anyway, so an additional no-frame/no-progress guard would be required.

Possible mitigations:

1. Re-encode the affected official background as VP9 Profile 0 yuv420p.
2. Do not enable looping until at least one frame has been produced.
3. If playback reaches the end without producing a frame or advancing normally, stop looping and fall back to the static background.
4. Handle MediaFailed for explicit decoder failures.
5. Validate background codec profile and pixel format before selecting the Media Foundation path.

The Collapse FFmpeg backend was not switched or evaluated during this investigation, so this report does not claim that enabling it fixes the issue.

Relevant Microsoft documentation:

• https://learn.microsoft.com/en-us/windows/apps/develop/media-playback/play-audio-and-video-with-mediaplayer
• https://learn.microsoft.com/en-us/uwp/api/windows.media.mediaproperties.vp9profileids