One other thing: The quality of the madVR freeze reports would increase if madVR could get access to the MPC-HC debug information. Could you maybe limit this code to situations when it's really needed? It seems to me its needed only when using the MPC-HC internal DXVA decoders? Currently the new code in "MainFrm.cpp" seems to be always executed, regardless of which renderer and which decoder is active. I understand why you're doing what you're doing there, but it does cause the freeze. It appears that the freeze occurs inside of Direct3D in this situation (let's just blame MS).įrom what I can see, the problem was introduced in MPC-HC revision 3619 by aleksoid's changes in "MainFrm.cpp". It appears that when the freeze occurs, MPC-HC is trying to create its own Direct3D object, in the context of the main thread, as a reaction to the display mode change, while madVR is still busy releasing its Direct3D object. This results in madVR trying to release its Direct3D object from within the secondary rendering thread. In that moment a display mode change is sometimes triggered.
The freeze reports indicate that the freeze occurs when madVR leaves exclusive mode. After having added the new freeze reporting feature in madVR v0.81, I've now received 2 freeze reports from 2 different users. I've recently been receiving complaints about madVR freezes when using MPC-HC.
0 kommentar(er)
