View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000495 | madVR | bug | public | 2017-08-08 11:50 | 2018-01-14 12:17 |
| Reporter | Yves W | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | W10 Pro MPC-BE | OS | W10 Prox64 Build 15063.502 | OS Version | Version 1703 |
| Summary | 0000495: Video stutter in windowed mode (144Hz screen) when gaming on a 60 Hz screen | ||||
| Description | Video stutters severely when playing a video in windowed, non-exclusive mode on a 144Hz monitor while playing a game on a 60Hz monitor. CPU & GPU can probs handle a lot higher load. Gets fixed by putting the video once in exclusive mode. | ||||
| Steps To Reproduce | 1) Open for example Black Desert Online or Orion Prelude on a 60Hz monitor (specifically https://iiyama.com/gl_en/products/prolite-e2273hds-1/) 2) Open MPC-BE with madVR on an ASUS VG248QE (144 Hz, https://www.asus.com/Monitors/VG248QE/) 3) Play a video on the 144Hz monitor 4) Video stutters severely when NOT in exclusive mode No stutter when: A) You drag the video to another 60Hz monitor (same model as the one at the 1st step) B) You drag the game to the 144Hz monitor C) You put the video in exclusive mode on the 144Hz monitor D) Putting it in exclusive mode and then back in windowed mode seems to fix the stutter for windowed mode as well | ||||
| Additional Information | Happens with both MKV and MP3 files. Running a 1080Ti Asus Strix, 32Gb RAM, I7-7700K. https://i.imgur.com/sQ62qNx.png => before putting it in exclusive mode, with stuttering | ||||
| Tags | No tags attached. | ||||
| madVR Version | 0.91.11 | ||||
| Media Player (with version info) | MPC-BE 1.5.1.2755.x64 and x86 | ||||
| Splitter (with version info) | LAV Splitter 0.70.2 | ||||
| Decoder (with version info) | LAV 0.70.2 | ||||
| Decoding | CUDA | ||||
| Deinterlacing | auto mode | ||||
| DXVA2 Scaling Active | no | ||||
| Aero / Desktop Composition | On | ||||
| Problem occurs with mode | windowed mode | ||||
| GPU Manufacturer | NVidia | ||||
| GPU Model | GTX 1080Ti Asus Strix | ||||
| GPU Driver Version | 384.94 | ||||
|
|
According to the screenshot the rendering queue doesn't fill, which seems to suggest that either the GPU can't keep up, or maybe doesn't get enough resources assigned to it. Are you gaming on the same GPU? |
|
|
Yeah, I have Black Desert Online open on one of my 60Hz screens which also uses my 1080Ti, but I thougth it'd be weird for the GPU to be the bottleneck, since I can put the video on my other 60 Hz monitor (also the 1080Ti) and it plays just fine + it plays fine after switching to exclusive mode once. Also having BDO & the video open on my 144Hz monitor fixes it, which I thougth would be the same load. The vid might idd not be getting enough resources before swapping to exclusive mode once? Here are some results of GPU-Z: https://imgur.com/a/Ilt0N Screenshot made after swapping to exclusive mode once, then back to windowed: https://imgur.com/a/aNeh3 |
|
|
I hope you don't have GPU-Z running all the time? It's known to cause issues. Anyway, this is not really a problem I can do anything about. madVR doesn't even know that a game is running on some other monitor. So if playback works well without the game, or with the game on the same monitor, then this looks more like a GPU driver issue than a madVR issue. Generally, high refresh rates are somewhat problematic in windowed mode. FSE mode is simply more reliable. |
|
|
Nah, just ran it now to check the load. Thanks for looking at it! Was just wondering if it was a madVR bug and/or could be fixed. I'll use FSE from now on when I have a game on one of my other screens. |
|
|
Quick reopen to add a fix for users in the future. Messed around a bit in the settings. Either setting the frames to be presented in advance to 16 (instead of 8) in windowed mode, or changing either flush after copy to backbuffer or after D3D presentation to any option except "don't flush" fixes it. Not sure which of these is the best idea, but it fixes the problem. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-08-08 11:50 | Yves W | New Issue | |
| 2017-08-08 11:57 | madshi | Note Added: 0001757 | |
| 2017-08-08 12:48 | Yves W | Note Added: 0001758 | |
| 2017-08-08 12:52 | madshi | Note Added: 0001759 | |
| 2017-08-08 13:04 | Yves W | Note Added: 0001760 | |
| 2017-08-08 13:05 | Yves W | Status | new => closed |
| 2017-08-08 13:05 | Yves W | Resolution | open => not fixable |
| 2017-08-08 13:16 | Yves W | Note Added: 0001761 | |
| 2017-08-08 13:16 | Yves W | Status | closed => feedback |
| 2017-08-08 13:16 | Yves W | Resolution | not fixable => reopened |
| 2017-08-08 13:19 | Yves W | Note Edited: 0001761 | |
| 2017-08-08 13:20 | Yves W | Note Edited: 0001761 | |
| 2017-08-08 13:21 | Yves W | Note Edited: 0001761 | |
| 2017-08-08 23:30 | Yves W | Status | feedback => resolved |
| 2017-08-08 23:30 | Yves W | Resolution | reopened => no change required |
| 2017-08-08 23:30 | Yves W | Assigned To | => Yves W |
| 2018-01-14 12:17 | madshi | Status | resolved => closed |
| 2018-01-14 12:17 | madshi | Assigned To | Yves W => |
