View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000217 | madVR | bug | public | 2014-06-13 02:32 | 2015-05-02 11:30 |
| Reporter | kael | Assigned To | madshi | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | unable to reproduce | ||
| Platform | x86-64 | OS | Windows | OS Version | 7 |
| Summary | 0000217: DWM frame / backbuffer queue empties out in response to CPU load and never re-fills | ||||
| Description | For a while now I've been noticing that in certain scenarios, madVR's presentation queue (DWM frames if I have 'present multiple frames in advance' enabled, backbuffers if not - I've tried both) empties out, and once this has happened it never fills back up. During this period I see glitchy frame presentation - video plays back stuttery, and randomly a very old frame will appear. It's quite strange. I can reliably reproduce this by opening a 60fps h264 video in mpc-hc, fullscreen on my secondary monitor. madVR shows 'fullscreen windowed mode' in the overlay in this state. Normally playback is great, with the average/max frame timings usually sitting at around 4-5ms. To enter the bad state, I need merely load the machine - the trick I'm using right now is launching Visual Studio 2010 and making it load a large project file. I'm not sure if the high CPU usage causes this to happen or if it's because Visual Studio uses the GPU for rendering - maybe both. Anyway, once I get into this bad state, the max timing stats show spikes up to 40 or even 80ms for a given frame, while the averages stay low. The decoder/upload/render queues stay full (though I do occasionally see the render queue start dropping), and the backbuffer/frame queue sits at 0 the entire time. If I'm presenting multiple frames in advance, literally every frame causes a 'presentation glitch' to be reported in the overlay; if not I see a huge number of dropped and repeated frames instead. Once rendering gets into this bad state, it usually doesn't recover. If I pause playback for a moment and then resume, the queues fill back up and everything is fine. I've fiddled with settings for a while to try and identify a cause and I don't think it's anything to do with my configuration. Things I've tried: LAV Filters (Software Decoding | CUVID Decoding | DXVA Decoding) Present Multiple Frames In Advance (Yes | No) Varying CPU, GPU and frame queue sizes (4, 6, 8, 10, 16) and various combinations (deep cpu queue + shallow gpu queue, deep cpu + gpu queue with small frame queue, etc) Varying display refresh rates (tried setting my refresh rate up to 96hz in case this was vsync related; same problem.) Pretty much every possible combination of 'flush / flush and wait' options for various stages One scenario where this doesn't happen is 24hz footage. No amount of load seems to cause the backbuffer queue to empty out for that kind of footage, though perhaps I'm just not causing enough load. Normal windowed mode (i.e. with titlebar visible, etc) DOES show presentation glitches in this scenario, but the queue never empties out and the max rendering/present times don't spike nearly as high. So the root cause may be present, but I definitely don't hit the bad state in windowed mode. Fullscreen exclusive mode also works just fine - if anything, fullscreen exclusive mode works better than normal windowed mode; I see less variances in frame times and less glitches when I follow my repro steps. I don't remember seeing this issue in the past, but I updated to madVR 0.87.10 a while ago (after having run a very old build of madVR happily for about a year), and I recently installed the latest GeForce drivers - 337.88 - and I've seen some complaints that recent NVIDIA driver updates have caused video playback issues. Sadly I'm not sure which one of these it might be. I can try rolling back to old nvidia drivers and re-testing once I get some time to do all those installs and reboots :) Note that this is 'fullscreen windowed mode'. Luckily I tried out fullscreen exclusive mode while writing up this report, and it works good so I'll probably stick with that configuration for now even if the screen flicker when mode-switching is annoying :) | ||||
| Steps To Reproduce | Open a 60fps h264 video clip; play in fullscreen mode on secondary monitor Launch an intensive application on primary monitor, fullscreen (I launch VS2010 with a big project) | ||||
| Tags | No tags attached. | ||||
| madVR Version | 0.87.10 | ||||
| Media Player (with version info) | MPC-HC 1.7.5 | ||||
| Splitter (with version info) | LAV Filters 0.61.2.0 | ||||
| Decoder (with version info) | LAV Filters 0.61.2.0 | ||||
| Decoding | CUDA | ||||
| Deinterlacing | auto mode | ||||
| DXVA2 Scaling Active | no | ||||
| Aero / Desktop Composition | On | ||||
| Problem occurs with mode | windowed mode | ||||
| GPU Manufacturer | NVidia | ||||
| GPU Model | GeForce GTX 670 | ||||
| GPU Driver Version | 337.88 | ||||
|
|
Can you still reproduce this problem? My best guess would be that it's some sort of driver problem. You could try updating to the latest drivers. Or downdating to some older drivers. Or, if you say you didn't have this problem with older madVR builds, you could also try to isolate the exact madVR version which introduced this problem. You can find all the old madVR builds here: http://www.videohelp.com/tools/madVR/old-versions#download |
|
|
Closed due to lack of response/feedback. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-06-13 02:32 | kael | New Issue | |
| 2015-03-14 16:09 | madshi | Note Added: 0000754 | |
| 2015-03-14 16:09 | madshi | Assigned To | => madshi |
| 2015-03-14 16:09 | madshi | Status | new => feedback |
| 2015-05-02 11:29 | madshi | Note Added: 0000975 | |
| 2015-05-02 11:29 | madshi | Status | feedback => closed |
| 2015-05-02 11:29 | madshi | Resolution | open => fixed |
| 2015-05-02 11:30 | madshi | Resolution | fixed => unable to reproduce |
