Stuttering and temporary video corruption during playback

[eMidir]

Hello, I've been using Screenbox this last couple weeks and with every mkv file I've tried, the same problem happens. (I tested the same mkv's with MPC-HE, with no issues whatsoever.)

I'm no expert on the topic, so I asked Chatgpt about a description for the problem: "brief stutter followed by “frozen” or corrupted pixel zones, with color distortion (chromatic aberration–like artifacts) that self-corrects"

https://imgur.com/a/faUqLuC

• OS: Windows 11
• Device: Ryzen 9950x3d, 64gb ram, rtx 5080
• App Version 0.16.0

I already tried pretty much all solutions provided on similar issues with no luck... --Configuration.EnableHardwareDecoding=true --gl=wgl --glconv=direct3d9 --file-caching=2000 Let me clarify, I've tried with this lines one by one as well as everything together. (I'm no expert)

[dosubot[bot]]

Hi @eMidir! I'm Dosu and I’m helping the Screenbox team.

This issue has been reported by several users on Windows 11 with modern hardware, especially with MKV files, and seems specific to Screenbox's playback pipeline or its LibVLC integration—other players like MPC-HE and VLC do not show the same problem. Disabling auto-resize in Screenbox settings can prevent some crashes but doesn't resolve all playback corruption or stuttering cases. Hardware decoding and caching settings (like EnableHardwareDecoding and FileCaching) have been suggested, but users report limited improvement. Some playback issues are linked to problematic video metadata, but that's not always the cause.

Screenbox uses Direct3D11 for video output, and its pipeline and frame timing can behave differently from MPC-HE, especially with features like Variable Refresh Rate (VRR), which can cause flicker and uneven frame times in Screenbox. Enabling verbose LibVLC logs (using the --verbose=2 or --verbose=3 option) may help diagnose whether the stuttering is due to decoding, rendering, or resource issues. You can also try adjusting the --avcodec-hw option (e.g., --avcodec-hw=d3d11va or --avcodec-hw=none) and experiment with different caching values (--file-caching=2000).

There is no definitive fix documented yet, and debugging has been difficult due to the randomness of the issue. If you haven't already, try disabling VRR, updating your graphics drivers, and enabling verbose logging to gather more details. For more context, see issue #613, issue #636, and issue #688.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[huynhsontung]

I would hazard a guess that this is caused by poor I/O performance when the app reads the media file from the disk. This poor IO performance can be caused by several reasons: other processes may be consuming all disk bandwidth, the file may be stored on a network drive, UWP (the platform Screenbox is built on) has limited IO performance, or a combination of these. There is no near-term solution for this at the moment. We have to move away from WinRT storage API for better IO performance.

[United600]

I would hazard a guess that this is caused by poor I/O performance when the app reads the media file from the disk.

Really? I'd expect issues during seeking, but not necessarily during playback especially with a system equipped with those components. Even in the Xbox One S 5400RPM hard drive, I've never experienced any playback hiccups.

Honestly, I suspect it might be some Nvidia drivers shenanigans, I keep hearing that their support for MPO and modern swapchains leaves a lot to be desired. Lots of users then use unsupported hacks, which often lead to unintended issues.

[huynhsontung]

These issues don't usually show up in the Win32 VLC and they also use Direct3D11 with what I assume is a swap chain. So I can't really suspect issues from graphic drivers for this.

[United600]

A good test would be to play those files with VLC UWP, and Media Player or Movies & TV.