View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000648 | madVR | bug | public | 2020-07-14 01:54 | 2022-07-01 17:16 |
| Reporter | kathampy | Assigned To | |||
| Priority | high | Severity | crash | Reproducibility | always |
| Status | new | Resolution | open | ||
| OS | Windows 10 | OS Version | 2004 (19041.329) | ||
| Summary | 0000648: display modes - freeze & crash when media player goes fullscreen | ||||
| Description | I'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. | ||||
| Tags | No tags attached. | ||||
| madVR Version | 0.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 | ||||
| Decoding | DXVA2 Native | ||||
| Deinterlacing | none (progressive) | ||||
| DXVA2 Scaling Active | no | ||||
| Aero / Desktop Composition | On | ||||
| Problem occurs with mode | windowed mode | ||||
| GPU Manufacturer | NVidia | ||||
| GPU Model | RTX 2080 Ti | ||||
| GPU Driver Version | 451.67 | ||||
|
|
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. |
|
|
Try decreasing the size of the GPU and/or CPU queue, maybe? |
|
|
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. |
|
|
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. |
|
|
madshi I don't know if it will be useful, but I did freeze report |
|
|
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. |
|
|
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 |
|
|
And log. Hope some of this helps. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
See my reply above, those tests are still useful. |
|
|
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? |
|
|
Well, I did make a number of other suggestions... ;-) |
|
|
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. |
|
|
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). |
|
|
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. |
|
|
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. |
| 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 |
