View Issue Details

IDProjectCategoryView StatusLast Update
0000648madVRbugpublic2022-07-01 17:16
Reporterkathampy Assigned To 
PriorityhighSeveritycrashReproducibilityalways
Status newResolutionopen 
OSWindows 10OS Version2004 (19041.329) 
Summary0000648: display modes - freeze & crash when media player goes fullscreen
DescriptionI've configured "switch to matching display mode ... when media player goes fullscreen" and "restore original display mode ... when media player leaves fullscreen". I use fullscreen windowed mode and not exclusive mode.

When switching to fullscreen, the refresh rate changes as expected, but most of the time the video freezes while audio continues to play. If I leave the video frozen, eventually the audio will slow down and stutter.

I can leave fullscreen mode, but the refresh rate doesn't change back. If I terminate the media player, sometimes the refresh rate changes back.

The problem does not occur if I configure "switch to matching display mode ... when playback starts".

The problem does not usually occur when using the MPC-BE's built-in fullscreen resolution change. This also freezes once in a while, but usually only when leaving fullscreen mode.
TagsNo tags attached.
madVR Version0.92.17
Media Player (with version info)MPC-BE x64 1.5.5.5274
Splitter (with version info)LAV 0.74.1
Decoder (with version info)LAV 0.74.1
DecodingDXVA2 Native
Deinterlacingnone (progressive)
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modewindowed mode
GPU ManufacturerNVidia
GPU ModelRTX 2080 Ti
GPU Driver Version451.67

Activities

thighhighs

2022-04-27 17:26

reporter   ~0002884

Similar symptoms, but in my case everything freezes completely. And this only happens when Native D3D11 decoder is used. GTX 1660 Ti, Windows 10/11
Madshi look at this please. The test build still has this problem.

madshi

2022-04-27 18:01

administrator   ~0002885

Try decreasing the size of the GPU and/or CPU queue, maybe?

thighhighs

2022-04-27 18:54

reporter   ~0002886

madshi
I've tried various madVR settings, checked system settings, etc. It had no effect. Tried to change players (MPC, PotPlayer), decoders (LAV, Pot built-in). The symptoms described above are still there. In my case this only happens if native d3d11 decoder is used. Native d3d9 decoder (DXVA2) works fine. Also d3d11 c-b work fine. I also tested native d3d11 decoder with the Pot built-in VR, it works fine. Looks like a bug in the madVR.

madshi

2022-04-27 19:10

administrator   ~0002887

Last edited: 2022-04-27 19:11

Well, it works fine for me, and seems to work fine for most other users. Fixing problems one can't reproduce are always a nightmare for every software developer.

thighhighs

2022-04-27 22:24

reporter   ~0002888

madshi
I don't know if it will be useful, but I did freeze report

madshi

2022-04-27 22:45

administrator   ~0002889

Does not seem to be stuck inside of madVR. I might be able to say more if you had PDB files for the native DXVA decoder.

thighhighs

2022-04-27 23:26

reporter   ~0002890

madshi
Hm... I googled and found where clsid2 say how to create dump. It can help?
madHcCtrl.DMP - https://www83.zippyshare.com/v/ht86nmwA/file.html
PotPlayerMini64.DMP - https://www2.zippyshare.com/v/rQ7zVXMk/file.html

thighhighs

2022-04-28 01:20

reporter   ~0002891

And log. Hope some of this helps.
madVR - log.zip (2,584,729 bytes)

madshi

2022-04-28 10:31

administrator   ~0002892

Looks like there's a decoder reconnect, and afterwards the media player gets stuck in paused mode.

You could try using LAV Video Decoder instead of the internal decoder.

Or try disabling the "delay playback start until render queue is full" option.

thighhighs

2022-04-28 15:20

reporter   ~0002893

It seems that the decoders work identically. The option has an effect. There is no more stability. If I go to full screen without pausing playback, there may be a complete freeze of the PC (hard reset). When I do this, the audio can play, but the video freezes for a few seconds (0000001:0000010). If I use the seeking keys when it is frozen, there may be a complete freeze of the pc.

New logs. To test, I chose this scenario: open a file, pause, go to full screen, resume playback, pause again, exit full screen, play again, then close the player. LAV filters are used. Also did a test with native d3d9 which works fine, hope you can see the difference.
madVR - logd3d11.zip (7,619,462 bytes)
madVR - logd3d9.zip (7,493,528 bytes)

madshi

2022-04-30 10:26

administrator   ~0002896

Instability like this can have multiple causes. One common cause could be running out of GPU RAM. Also, some decoders don't like having too many "active" frames at the same time. For both reasons, I'd recommend trying with much smaller CPU and GPU queues, to check if that helps. Try the smallest queue sizes possible. Also, keep "delay playback start" disabled for now. Finally, try with smooth motion disabled, as a test. I don't know if any of that helps, but since most other users (including myself) don't seem to have this problem, I'm not sure what else I can say.

thighhighs

2022-04-30 17:21

reporter   ~0002897

madshi
As the user above said, the key is in the "switch to matching display mode... when playback starts" option. But this does not allow me to use madVR comfortably. BTW, I'm pretty sure the user above is actually using native d3d11, but was unable to select that on the form, as someone wrote in posts here. It looks like the advantage of native d3d11 is not the "better stability".
Maybe someday the users or developers of LAV and MPC will provide more useful information and you can fix it.

pcp7

2022-07-01 02:28

reporter   ~0002912

I've the exact same problem, switching the display rate works fine, but only if stay in windowed mode. Switch to full screen and the video freezes, and won't play. Turning off the switch display rate makes everything work fine. I'm using RTX3080 and MPC

madshi

2022-07-01 11:00

administrator   ~0002913

See my reply above, those tests are still useful.

thighhighs

2022-07-01 13:39

reporter   ~0002914

madshi
I said above that the "...when playback starts" seems like a workaround. But at some point I noticed that the video memory usage increases with each new file opened, 2.3 -> 3.5 and more (memory leak?). This happens after using D3D11 Native (C-B work fine), and stops after restarting the player.
I also noticed that PotPlayer, MPC, KMP - the result is the same. MPC-BE - works differently. D3D11 Native still doesn't work correctly, but the symptoms are different. In all scenarios it only happens to madVR. But does it make sense to consider the problem from the side of the player?

madshi

2022-07-01 13:49

administrator   ~0002915

Well, I did make a number of other suggestions... ;-)

thighhighs

2022-07-01 15:03

reporter   ~0002916

madshi
For me there is no solution in settings. I have tried different combinations. Two options affect symptoms: "switch to matching display mode..." and "delay playback start". But it was not possible to set up to play without problems.
In the google, I met a discussion of similar symptoms with the MPC player. Now I can't find it... There the user did a debug. As a result, the developer who gave the debug versions said he couldn't fix it. It would not be difficult for me to contact the developers of MPC-BE (no language barrier), but with a high probability the result will be the same.

madshi

2022-07-01 15:08

administrator   ~0002917

Well, delay playback start is a tricky option, it can cause instability. So if it helps, you should be able to disable this option without losing much.

Is there a reason you can't simply use copyback? It has several advantages over native, e.g. black bar detection. The only true reason to use native is if copyback is too slow (stuttering).

thighhighs

2022-07-01 16:45

reporter   ~0002918

madshi
D3D9 CB or D3D11 CB is enough for me. But I consider quality/gpu load for my normal settings and maybe D3D11 Native would help to upgrade to heavier settings for free in some cases. It's hard to appreciate its benefits when it's not working properly. But in general, at the momment there is nothing critical in using a different decoding method in my case.

madshi

2022-07-01 17:16

administrator   ~0002919

I don't think Native decoding would give you much extra GPU power. The cost of copyback is simply the travel back of the video frames from GPU RAM to system RAM. That's usually not something which slows down GPU rendering. The RAM transfer is done in a different thread, and I think it's done in hardware by DMA, or something like that.

Issue History

Date Modified Username Field Change
2020-07-14 01:54 kathampy New Issue
2022-04-27 17:26 thighhighs Note Added: 0002884
2022-04-27 18:01 madshi Note Added: 0002885
2022-04-27 18:54 thighhighs Note Added: 0002886
2022-04-27 19:10 madshi Note Added: 0002887
2022-04-27 19:11 madshi Note Edited: 0002887
2022-04-27 22:24 thighhighs Note Added: 0002888
2022-04-27 22:24 thighhighs File Added: madVR - freeze report (1).zip
2022-04-27 22:45 madshi Note Added: 0002889
2022-04-27 23:26 thighhighs Note Added: 0002890
2022-04-28 01:20 thighhighs Note Added: 0002891
2022-04-28 01:20 thighhighs File Added: madVR - log.zip
2022-04-28 10:31 madshi Note Added: 0002892
2022-04-28 15:20 thighhighs Note Added: 0002893
2022-04-28 15:20 thighhighs File Added: madVR - logd3d11.zip
2022-04-28 15:20 thighhighs File Added: madVR - logd3d9.zip
2022-04-30 10:26 madshi Note Added: 0002896
2022-04-30 17:21 thighhighs Note Added: 0002897
2022-07-01 02:28 pcp7 Note Added: 0002912
2022-07-01 11:00 madshi Note Added: 0002913
2022-07-01 13:39 thighhighs Note Added: 0002914
2022-07-01 13:49 madshi Note Added: 0002915
2022-07-01 15:03 thighhighs Note Added: 0002916
2022-07-01 15:08 madshi Note Added: 0002917
2022-07-01 16:45 thighhighs Note Added: 0002918
2022-07-01 17:16 madshi Note Added: 0002919