madshi bug tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000217madVRbugpublic2014-06-13 02:322015-05-02 11:30
Reporterkael 
Assigned Tomadshi 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionunable to reproduce 
Platformx86-64OSWindowsOS Version7
Summary0000217: DWM frame / backbuffer queue empties out in response to CPU load and never re-fills
DescriptionFor 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 ReproduceOpen 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)
TagsNo tags attached.
madVR Version0.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
DecodingCUDA
Deinterlacingauto mode
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modewindowed mode
GPU ManufacturerNVidia
GPU ModelGeForce GTX 670
GPU Driver Version337.88
Attached Files

- Relationships

-  Notes
(0000754)
madshi (administrator)
2015-03-14 16:09

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 [^]
(0000975)
madshi (administrator)
2015-05-02 11:29

Closed due to lack of response/feedback.

- Issue History
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


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker