MPC-HC tester builds for internal renderer fixes

[JanWillem32]

I'll take a look at it later on. I'm currently on vacation.

[dmiranda]

I'll take a look at it later on. I'm currently on vacation.

Enjoy you break, JanWillem. After a bit of tweaking, I am running your "mpc-hc SSE2 tester dfr7370rs6i", and it is an amazing experience - even on XP and two old quadro cards. You rock bro. Thanks.

[XRyche]

Hi JanWillem32, long time. I don't know if you remember or not, but I was having issues with your renderer playing DVDs. I was getting a repeat frame/tearing issue. Well it turns out, after updating to Windows 10 up from Windows 8.1 the issue is completely gone.

I must confess I've been using madVR these last few months because of Nnedi3 mostly. Since I've been having issues with being able to use Nnedi3 since updating to Windows 10 I'm back to using your player regularly unless the Nnedi3 issue with madVR can be remedied.

I just wanted to thank you for still having it available.

[Hera]

The seek bar is very small at 200% DPI. Anyone have a solution?
Specs in Sig

[XRyche]

Use 100% DPI lol. Seriously, I'd be surprised if anything could be done. I mean JanWillem32 has done some rather miraculous things with this renderer, but it's still EVR when you get right down to it.

[Hera]

Use 100% DPI lol. Seriously, I'd be surprised if anything could be done. I mean JanWillem32 has done some rather miraculous things with this renderer, but it's still EVR when you get right down to it.

I have to get up close to the monitor and squint a bit to see things at 100%.
4K monitor @ 100% DPI = 4 times smaller and harder to read UI than an old school 1080p monitor of the same size

There are some problems with the renderer going black when going full screen as well, but that is less important.

[XRyche]

Is it just a momentary issue of going black or does it stay black screen? If it's just a momentary black screen before the image is shown, he actually cut the time it took to transition quite a bit.

[Hera]

Is it just a momentary issue of going black or does it stay black screen? If it's just a momentary black screen before the image is shown, he actually cut the time it took to transition quite a bit.

When it happens I have to restart.

[XRyche]

When it happens I have to restart.

That actually used to happen to me occasionally. It hasn't happened since I upgraded from Windows 8.1 to Windows 10 though. I have consistently been using JanWillem32's renderer since I upgraded, so about 2 weeks now, without any black screen issues. Switching to Windows 10 actually cleared up another issue that I already previously posted about.

[JanWillem32]

I replaced the builds to include the latest small fixes. No major changes were made.
I changed the OSD hiding timer, the fullscreen non-exclusive mode handling and fixed the name truncation issue for dim color LUT files. You can delete old dim profiles in the "C:\ProgramData\Media Player Classic" folder.
-

For the reported problems:
Does the lav filter P010 output mode still not work lately? It's possible it's purely a driver issue: I can disable the 10-bit types in such a case.
The black screen issue is partially solved. It does still go black if the window is maximized and goes fullscreen, but it shouldn't happen anymore when switching from the non-fullscreen mode. I'll have to try some other stuff to fix the issue. (I'm not even sure it's the renderer itself causing the issue, it could be a fault in the main window.)
For the DPI issues, I don't have a real solution. I'm not much of a GUI programmer (I only edited the forms for the new options and changed the GUI in the OSD a bit).

[JanWillem32]

I replaced the builds to include a fix for the fullscreen non-exclusive mode handling when the window is maximized and added AVX builds on request.
x64 AVX: http://www.mediafire.com/download/edof94d5x79xf2b/mpc-hc64_AVX_tester_dfr7370rs7i.7z
x64: http://www.mediafire.com/download/hh463nihd52s55z/mpc-hc64_tester_dfr7370rs7i.7z
x86 AVX: http://www.mediafire.com/download/h5s0ubpxqnb3fma/mpc-hc_AVX_tester_dfr7370rs7i.7z
x86 SSE2: http://www.mediafire.com/download/0x9x4e38ce0you4/mpc-hc_SSE2_tester_dfr7370rs7i.7z
x86 SSE: http://www.mediafire.com/download/fwfbpif9q5z9ooy/mpc-hc_SSE_tester_dfr7370rs7i.7z

[XRyche]

There is a slight 2 to 4 second pause when trying to close the player with the new x64 AVX build. There was no pause whatsoever with the previous x64 build.

[Hera]

There is a slight 2 to 4 second pause when trying to close the player with the new x64 AVX build. There was no pause whatsoever with the previous x64 build.

WFM - Specs in the sig

[JanWillem32]

It's the OSD I think. Disabling it should solve the problem. I also think I already solved the issue in the next build. (It will just not display "Stop" on closing the player anymore.)

[XRyche]

(It will just not display "Stop" on closing the player anymore.)

Well I guess that will fix it :D .

[JanWillem32]

I made the player close faster when the OSD is enabled.
I fixed the audio switcher and enhanced its capabilities to down-sample audio to 44100 Hz.
I fixed a frame rate detection issue for 60 and 60/1.001 fps sources.
x64 AVX: http://www.mediafire.com/download/te5h1ewvl3149k0/mpc-hc64_AVX_tester_dfr7370rs8i.7z
x64: http://www.mediafire.com/download/wd4g14gopjco1sk/mpc-hc64_tester_dfr7370rs8i.7z
x86 AVX: http://www.mediafire.com/download/2biyz3ofqonc0lq/mpc-hc_AVX_tester_dfr7370rs8i.7z
x86 SSE2: http://www.mediafire.com/download/n543546o36cd6j4/mpc-hc_SSE2_tester_dfr7370rs8i.7z
x86 SSE: http://www.mediafire.com/download/dt9qcx8htfhfdd8/mpc-hc_SSE_tester_dfr7370rs8i.7z

[CruNcher]

@Jan

The maximized/fullscreen blackscreen playback problem seems fixed though im testing on Nvidia 355.84 now

The switch responsiveness of the GUI (Renderer) is still so so it takes pretty long to react (delay, latency) when switchting render modes (window,maximized,fullscreen redraw) compared to MPC-HC/BE.

Strange

mpc-hc64 tester dfr7370rs8i.7z

no executable here therfore the .pdb ;) ?

and the tendency to brake out and endup in a jitter explosion is still high in fullscreen even with pretty warmed up caches :(

Im not sure maybe it's the OSD And Graph Rendering threads that are mainly responsible

http://i2.sendpic.org/t/2A/2AbSp1wtjZCYTFjxFmSbEsSkcun.jpg (http://sendpic.org/view/2/i/gtVFtsvhxmcyqu31qviatS6Buxj.png)

MPC-HC BE very stable OSD/Graph and Overlay System with no detectable interfernces in the main render thread

http://i1.sendpic.org/t/c6/c6u1Lrz1kIZIqDlkLdQOy1rKj6w.jpg (http://sendpic.org/view/1/i/tv8rrKX4Tba3P8elwhYPmriy2SI.png)

[JanWillem32]

Thank you for noticing these issues.
I replaced the x64 package (link remains unchanged).
My renderer is indeed slow to respond to changes in fullscreen/windowed resizing. It's just how it's built.
Have you tried the alternative scheduler option to solve the jitter issue? (View->Renderer Settings->Presentation). (Constant frame interpolation could work as well, by the way.) I'm thinking of making that option the default.
Does this issue remain in the D3D fullscreen exclusive mode? Is this issue only present in my more recent builds?
Also, I see that the OSD in my version of the renderer doesn't show the monitor's name. Do my previous builds do the same?

[JanWillem32]

I improved performance under high CPU usages by better multi-threading in EVR CP.
I fixed some minor performance issues with the alternative scheduler.
I changed the monitor EDID detection method. It might work now in cases where it didn't before.
I added the monitor brand to the OSD. (In some cases the type string didn't contain it.)
x64 AVX: http://www.mediafire.com/download/60lk5jal8njsprc/mpc-hc64_AVX_tester_dfr7370rs9i.7z
x64: http://www.mediafire.com/download/i066bop14te0110/mpc-hc64_tester_dfr7370rs9i.7z
x86 AVX: http://www.mediafire.com/download/w1crgoci5dh9big/mpc-hc_AVX_tester_dfr7370rs9i.7z
x86 SSE2: http://www.mediafire.com/download/jq6hlif0xg5h9ye/mpc-hc_SSE2_tester_dfr7370rs9i.7z
x86 SSE: http://www.mediafire.com/download/z0dvndi7aaffoy0/mpc-hc_SSE_tester_dfr7370rs9i.7z

[CruNcher]

It looks better and i tested further though sometimes the behaviour of the options logic is behind me sometimes i see A.Schdl in the OSD sometimes i dont but its active in the Dialog options

Though when A.Schdl was active (OSD visible) the results where pretty catastrophicall totally unstable playback results it stuttered it froze it jittered

Another thing is how the renderer reacts when Aero is turned off in non exclusive Fullscreen this happens i tried alternative V-sync still the same without Aero totally unplayable, not as bad as the A.Schdl results but still playback gets locked to a 18 fps sync.

http://i2.sendpic.org/t/dE/dEhRpQyxZf7UdJMrQDSsgtk9hIy.jpg (http://sendpic.org/view/2/i/tcvsrxIT0Z8x9BgALWwY8iDkh9d.png)


Though Nvidia changed so many Stuff in their Drivers when it comes to V-sync because of Adaptive Sync and most and for all G-sync of course and now comes VR additionally


One example where the A.Schdl OSD display is disturbing when Aero is off in the options and A.Schdl enabled it doesn't show it in the OSD so i guess A.Schdl works only with Aero enabled and if why are the options on click then not correctly grayed out in their relation to each other ?


MPC-BE

Aero ON
http://i1.sendpic.org/t/ig/igxpHmQxbHe7KoTIlxEmPqN8DBO.jpg (http://sendpic.org/view/1/i/vckDgql6i1tgKjpWq2LrRciaJxW.png)

Aero OFF
http://i2.sendpic.org/t/nX/nXPvGCUKNFDQYT2Q5mt1tjCIl9B.jpg (http://sendpic.org/view/2/i/tYlk6ZGD4YcEZrssByziLck8Gup.png)


Is it maybe the overhead of your renderer that it brakes totally apart here in such a utilization scenario ?

[JanWillem32]

How's the performance without the alternative scheduler enabled in the latest build? It should be much improved. On hardware like yours it should easily run such media even with high settings and a few heavy shaders enabled.
The alternative scheduler indeed uses the Desktop Composer to schedule frames. (It's more accurate and allows extra queuing of rendering images from the subtitle renderer, but costs some resources.)
Does the stats screen still not show the monitor EDID info in the latest version?

[CruNcher]

it's much better the spike that exploded before is still happening but much lower though alternative scheduling is no option here it's to unstable and yes still no Edid info shown

[XRyche]

I always figured the spike and the time it took to recover was just "par for the course" or just one of the downsides of using D3D FS. It was always there as long as I have used the experimental builds. Speed has drastically improved for me. It takes very little time, one or two seconds, if that for the frame-rate to recover even when using frame interpolation and the alternative scheduler. I suppose it is an Nvidia problem because when I had my old 9800GT I remember that the scheduler was unstable for me as well. I just figured my card was too old and slow. The Alternative scheduler on my R7 265 works perfectly fine though. I am getting EDID info on the stat screen and the branding of my monitor as well.

[JanWillem32]

Does the OSD work with this build? I tried some case-insensitive searches this time, maybe that will help.

[CruNcher]

As soon as i enable the Display Stats with this build the video surface gets lost in black and i see only the osd and hear the audio

http://i1.sendpic.org/t/ZD/ZDgkovUahpNCYGqhpP4clz16wi.jpg (http://sendpic.org/view/1/i/1CYmrWd0ueQJPViEKFKScERWYIT.png)

[JanWillem32]

Let's try a debug build, then. If it breaks at any point note down the line and press continue. Debug printouts can be received by DebugView: https://technet.microsoft.com/en-us/library/bb896647.aspx?f=255&MSPPError=-2147217396. (Just run it in capture mode at the same time as a debug build and you will get messages.)

[CruNcher]

It brakes immediately @ 6538 dx9allocatorpresenter.cpp then Warning Dialog "could not open D3D9.dll,OK" and continues playback after finding the right graph though i can't trigger the OSD it wont appear it seems it can't load EVR because it expects d3d9.dll in the main dir, then lets give it that ;)

Funny i can't debug it it wont open d3d9.dll that Debug Version want's to fool around with me :D

Sorry i have no idea might be the Visual Studio version used that has Security issues in the NT6 UAC Model even in Elevated mode it wont load the d3d9.dll not even from the main dir

tried to elevate debugview and mpc-hc no success, no idea how to get d3d9.dll working from the outside it seems to totally reject it with that Debug Version.

Hmm last logical guess it will only accept the Debug Version of the d3d9.dll (DirectX SDK)

[JanWillem32]

How silly of me. It's actually expecting the debug dll of d3d9.dll: d3d9d.dll. I'm Sorry for the inconvenience. Here's another debug build:

[CruNcher]

0 At line 22226 of dx9allocatorpresenter.cpp

[4792] FGM: Connecting 'Enhanced Video Renderer (custom presenter)'
[4792] --> CFGFilterVideoRenderer::Create on thread: 1772


Performance is obviously bad really bad in Debug Mode (this is how enabling A.Schdl feels in non dbg) ;)


[4792] EVR: SyncOffset: -0.212434 SampleFrame: 1178.000000 ClockFrame: 1183.310847
[4792] EVR: Normal frame
[4792] EVR: sync offset deviated much too low
[4792] EVR: SyncOffset: -0.201694 SampleFrame: 1179.000000 ClockFrame: 1184.042351
[4792] EVR: Normal frame
[4792] Video renderer is eight frame times behind, expect heavy frame dropping
[4792] EVR: Dropped frame
[4792] EVR: SyncOffset: -0.211727 SampleFrame: 1180.000000 ClockFrame: 1185.293164
[4792] EVR: Normal frame
[4792] EVR: sync offset deviated much too low
[4792] EVR: SyncOffset: -0.241138 SampleFrame: 1181.000000 ClockFrame: 1187.028453
[4792] EVR: Normal frame
[4792] Video renderer is eight frame times behind, expect heavy frame dropping
[4792] EVR: Dropped frame
[4792] EVR: SyncOffset: -0.254138 SampleFrame: 1182.000000 ClockFrame: 1188.353439
[4792] EVR: Normal frame
[4792] EVR: sync offset deviated much too low
[4792] EVR: SyncOffset: -0.243349 SampleFrame: 1183.000000 ClockFrame: 1189.083731
[4792] EVR: Normal frame
[4792] Video renderer is eight frame times behind, expect heavy frame dropping
[4792] EVR: Dropped frame
[4792] EVR: SyncOffset: -0.251400 SampleFrame: 1184.000000 ClockFrame: 1190.284997
[4792] EVR: Normal frame
[4792] Video renderer is eight frame times behind, expect heavy frame dropping
[4792] EVR: Dropped frame
[4792] EVR: SyncOffset: -0.263428 SampleFrame: 1185.000000 ClockFrame: 1191.585700
[4792] EVR: Normal frame
[4792] EVR: OnClockPause() hnsSystemTime = 1596860107917
[4792] EVR: sync offset deviated much too low
[4792] EVR: MFVP_MESSAGE_FLUSH
[4792] EVR: Flush done!
[4792] CAudioSwitcherFilter::DeliverEndFlush
[4792] EVR: OnClockRestart() hnsSystemTime = 1596861297917
[4792] EVR: OnClockPause() hnsSystemTime = 1596861297917
[4792] EVR: OnClockStop() hnsSystemTime = 1596861647917
[4792] EVR: MFVP_MESSAGE_ENDSTREAMING
[4792] EVR: MFVP_MESSAGE_FLUSH
[4792] EVR: Flush done!
[4792] CAudioSwitcherFilter::DeliverNewSegment
[4792] EVR: MFVP_MESSAGE_FLUSH
[4792] EVR: Flush done!
[4792] CAudioSwitcherFilter::DeliverEndFlush
[4792] OSD DisplayMessage: Stop, duration: 3000
[4792] OSD Draw Message: Stop
[4792] Video renderer is eight frame times behind, expect heavy frame dropping
[4792] OSD ClearMessageInternal


OSD though shows up Video also

[JanWillem32]

I replaced the build, and the download link remains the same. It should work this time around.

[CruNcher]

if you mean the edid recognition that is still not working like it does in MPC-BE or do i need to enable it in some option first in the GUI that this shows up in the OSD ?
btw i prefer to test the 64 bit builds exclusively because of the hevc decoding speedup.

Pretty crazy to see Cyberlink getting totally beaten by MPC-BE x64 in playback Performance on the Hard 10 Bit 4K Bitstreams @ the Multithreading CPU Edge


Tough with the test renderer no chance yet to reach that playback stability + OSD outside of d3d fullscreen and even then it still shows issues

and no OSD render stalls like with the normal MPC-HE

http://forum.doom9.org/showpost.php?p=1741297&postcount=2211

They did a really great job on MPC-BE

[JanWillem32]

Does it still break at the same line? There is no option to enable this feature.
Note that debug builds are not there to have any decent performance. As such, debug builds are unsuitable for regular usage.
x64 build with extra verbosity (ReadRegistryDisplayEDID() entries): http://www.mediafire.com/download/b7jho02qcqlxkii/mpc-hc64_debug_tester_dfr7370rs9i.7z

[CruNcher]

Works now :)

Bur see what suddenly happened when changing window modes back and forth with this build

http://i1.sendpic.org/t/nY/nYi67f8R1YwFFNKYWWf6tlH7gKa.jpg (http://sendpic.org/view/1/i/kffxgRhHwNuMM4T6CrmQo5pbYoD.png)

[JanWillem32]

OK, I'll remove that debug assertion. It doesn't mean much. Glad to hear that the OSD functionalty is fixed. I'll keep the function as it is now.

[CruNcher]

Some further tests im doing currently on the playback efficiency side

http://forum.doom9.org/showpost.php?p=1741843&postcount=830

[XRyche]

JanWillem32, the newest regular AVX 64 build drops audio out when you switch from D3DFS to FS or visa versa randomly when using Frame interpolation. It doesn't happen every time, it just happens randomly for no apparent reason. Switching between D3D FS and windowed mode doesn't seem to have this issue.

[JanWillem32]

XRyche, that's probably because I fixed the starvation clock. The starvation clock sends a message to the main thread to seek ahead if the renderer is more than a second behind. In your case the reset is taking longer than a second and that is probably making the audio switcher/renderer upset. Manually pausing before a reset should fix this issue.
I can experiment with automatic pausing and resuming after the reset for such a case.

[JanWillem32]

Here are some intermediate builds with such an auto-pause feature. I'm not sure that people will actually like this feature though.

[XRyche]

The auto-pause feature works quite well and isn't as disruptive as I thought it would be. For some reason I thought it was going to pause playback automatically but you would have to unpause it manually. The pause isn't that long at all so it isn't that intrusive, at least to me it isn't. Thank you.

[JanWillem32]

I received a feature request to add system and video resources to the stats screen. This wasn't that easy, but I think it works fine now. Note that the CPU and GPU percentages are estimates. e.g. both statistics can surpass 100% load when doing heavy tasks.
Note that I'm interested if the GPU resource function works on Windows Vista. If not, I'll edit the code to only allow this feature on Windows 7 and onward.

[ts1]

Only CPU usage on Vista.
And it takes long till start of playback on last builds.

[JanWillem32]

I'll do some testing in Vista emulation mode later on. Does the stats screen show error values for GPU usage or no line for GPU usage at all?
Does the player start any faster if you deselect the "Automatic Refresh Rate Detection" option in View->Options->Output? I know that some monitors don't report their refresh rate very well with this function (and then (re-)initialization becomes very slow).
It could also be the automatic pausing functionality. Are you using a non-default zooming option or something similar?

[XRyche]

I received a feature request to add system and video resources to the stats screen. This wasn't that easy, but I think it works fine now. Note that the CPU and GPU percentages are estimates. e.g. both statistics can surpass 100% load when doing heavy tasks.
Note that I'm interested if the GPU resource function works on Windows Vista. If not, I'll edit the code to only allow this feature on Windows 7 and onward.
x64 AVX: http://www.mediafire.com/download/wwkalp293q99thd/mpc-hc64_AVX_tester_im.7z
x64: http://www.mediafire.com/download/ka9773wwgiei3v9/mpc-hc64_tester_im.7z
x86 AVX: http://www.mediafire.com/download/fcdfqjdcd941cr5/mpc-hc_AVX_tester_im.7z
x86 SSE2: http://www.mediafire.com/download/hbxae9muw0312p4/mpc-hc_SSE2_tester_im.7z

I know I'm not on XP but everything works like it should on my end. Frame Interpolation really makes those shadercores spike though. I checked the stats via MSI Afterburner which displays most the stats, including individual cpu core and shared cpu stats as well. MSI Afterburner lets me look at the stats up to 4 mins after MPC was closed. Your stats and MSI Afterburner stats are pretty close as far as i can tell. Not an exact match but you did say your stats are estimates.

[ts1]

No line for GPU usage at all.
Without "Automatic Refresh Rate Detection" almost instantly on Win 10. But still 2-3 seconds on Vista (was ~5). Need debug build.

[JanWillem32]

Then this call just doesn't work on Vista. I can live with that.
Here's an x86 SSE2 debug build: ...
If it breaks at any point note down the line and press continue. Debug printouts can be received by DebugView: https://technet.microsoft.com/en-us/library/bb896647.aspx?f=255&MSPPError=-2147217396. (Just run it in capture mode at the same time as a debug build and you will get messages.)
I still wonder why these last few builds are slow to start on your system. I didn't change much in the initialization sequences. Does the same slow startup happen when trying VMR-9?

[ts1]

For EVR:

00000230 0.47601447 [3492] EVR: Trying mixer input type: NV12
00000231 2.32427502 [3492] FGM: Inserting 0 0 0000002000000000 '{00A95963-3BE5-48C0-AD9F-3356D67EA09D}' -->
00000232 2.32430625 [3492] Success


For VMR9:

00000202 0.17028834 [3808] Video renderer device created or reset, window size: 310?200
00000203 2.13441420 [3808] FGM: Inserting 0 0 0000002000000000 '{00A95963-3BE5-48C0-AD9F-3356D67EA09D}' -->
00000204 2.13444591 [3808] Success


This is on 1080p video. For 480p video delay is ~0.5 sec here. On Win 10 it's ~0.15 for 1080p and ~0.05 for 480p.

And on VMR9 10bit 4:4:4 video works only with Display stats enabled on both OS's. Without:
http://i1.sendpic.org/t/gC/gC3A0KWOsuaDjGR4HGk7lXPPw10.jpg (http://sendpic.org/view/1/i/7qe2cTqxz6tF19je5cAyPP9kcxv.jpg)

[JanWillem32]

Are you using any automatic resizing options? (The most common one is under View->Options->Playback->Auto Zoom.) These features reset the renderer before playback.
It's odd that initializing the mixer parts would take that long. I haven't edited much mixer code in a long time. Are you sure it's only in the last few builds?
I can replicate the issue with the 10bit 4:4:4 video. I'm not sure what is happening there. I'll do some testing next week.

[ts1]

Yes, it is Auto Zoom. It's fast without it.

[ts1]

Seems like Auto Zoom + Lanczos3/4 = delay
On Win 10 as well.

[JanWillem32]

That does explain things a bit. The Lanczos shaders are somewhat slow to compile. If automatic re-sizing is enabled the resizing shaders have to be compiled twice. (It's once for the initial small window, and then again for the larger window.)
Still, are you sure it's a problem of the last few builds?