Media Player .NET (MPDN) - D3D HQ GPU Video Renderer [v2.49.0/v1.31.0 27 Dec 2018]

[romulous]

Ok, fair enough then. FWIW, it's only in fullscreen. In windowed, there is a jump to about 15 glitches at the start of playback, but then it stays there (ie it doesn't increase, even with I zoom to 200%). It also seems to be worse on my second display than on my first. FSE is off (it's annoying you can't do anything on screen #1 without MPDN constantly flickering between FSE and non-FSE, so I have it disabled), but have tried various combinations of D3D9, 10 and 11, with and without the alternate render path option enabled (haven't found a good combination as yet).

[aufkrawall]

Thanks for implementing smooth motion, Zachs. :)
Is there a chance that you'll do the same with a debanding feature?
Or is there a render script available?
Thanks.

[Zachs]

No plans for debanding. I find that it is quite easily done on the CPU via ffdshow post processor.

That said, I think it could be done via RenderScript.

[Zachs]

Full screen non exclusive mode still relies on Windows to do the final composition. That's where DWM comes in. It could also be that MPDN is using too much GPU and left nothing to Windows, therefore causing glitches, but unlikely that it will be a constant one per second.

Edit: and the fact that it doesn't seem like it's related to GPU load at all since you're getting higher rates without RenderScript.

[nekromantik]

Zachs did you try selecting bitstream and try playing files?

[Zachs]

Not yet I'll try replicating when I have some time.

[nekromantik]

Not yet I'll try replicating when I have some time.

Thanks

[Zachs]

Zachs did you try selecting bitstream and try playing files?

What does MPC-HC show in the filter list when you do bitstream with LAV Audio?

I don't have a setup that allows me to bitstream anything unfortunately. As I understand it, you need to select an Audio Renderer that will accept the bitstream - did you do that?

MPDN's audio graph construction is entirely based on DirectShow's intelligent connect starting from LAV Audio Decoder. My understanding is that if you give it an Audio Renderer that accepts passthrough, it will work.

[Zachs]

All presentation APIs work when using the Intel GPU.
Surprisingly all presentation APIs used to work and still works with old MediaPlayerDotNet v2_12_3_2807. Didn't try 64-bit versions.

Well, there's certainly a bug in NVIDIA's Optimus drivers if Intel GPU has no problem with all the presentation APIs :)

However, it would appear that v2.12.3 lucked in somehow with regards to getting it to work with Optimus, so I have reverted the necessary bits back to that version to see if it helps with v2.16.9. If it does, hopefully the other Optimus users would be able to finally use Dx11 as well.

Do report back as well with regards to the bug Anima123 reported - specifically, Optimus' render times gradually increasing until at one point it is unusable.

[Zachs]

Zachs you are making great progress with this player. I love the NEDI/SuperRes options... So first of all :thanks:

Now onto a hopefully quick question I had for you. Are you at all working on implementing a refresh rate change similar to what MadVR does? (It's one of the main reasons why I am continuing to mainly use MPC+MadVR as my setup of choice)

Like where you can enter the following: 1080p23,1080p24,1080p50,1080p60
Then video renderer can determine the type of refresh rate which the video is and then changes to the appropriate refresh. This is big for me since my plasma TV has a 96hz mode which plays back 23.976 videos perfectly in sync with no flicker and this bypasses the need for any video smoothing features.

I have pretty much hacked up a very basic display refresh rate changer as Player Extension. Hopefully someone will polish it up.

[nekromantik]

What does MPC-HC show in the filter list when you do bitstream with LAV Audio?

I don't have a setup that allows me to bitstream anything unfortunately. As I understand it, you need to select an Audio Renderer that will accept the bitstream - did you do that?

MPDN's audio graph construction is entirely based on DirectShow's intelligent connect starting from LAV Audio Decoder. My understanding is that if you give it an Audio Renderer that accepts passthrough, it will work.

In MPC HC if I select bitstream in LAV then it loads Microsoft's DTV Audio DVD Decoder for some reason instead of LAV but it works.

In MPCDN it gives the cannot render error.

You dont need to have hardware to test, if you tick the bitstream options in LAV and try to load a AC3 file see if it works or not.

[ryrynz]

In MPC HC if I select bitstream in LAV then it loads Microsoft's DTV Audio DVD Decoder for some reason instead of LAV but it works.


We discussed this issue earlier Zach, which lead me to post this (http://forum.doom9.org/showthread.php?p=1703377#post1703377) in LAV's thread.

The issue I was with LAV not supporting automatic fallback for down mixing and MPDN not accepting anything other than LAV I also got the rendering error.

Maybe you could allow Microsoft's DTV-DVD decoder in the chain?

Also nekromantik if the Microsoft DTV-DVD decoder is active then you are not actually bitstreaming at all.

[Zachs]

Let me find out why the decoder isn't automatically added by DirectShow. GraphStudio is behaving the same way as MPDN. There must be something extra you have to do to allow it in the graph... If anyone knows this, please let me know.

[nekromantik]

We discussed this issue earlier Zach, which lead me to post this (http://forum.doom9.org/showthread.php?p=1703377#post1703377) in LAV's thread.

The issue I was with LAV not supporting automatic fallback for down mixing and MPDN not accepting anything other than LAV I also got the rendering error.

Maybe you could allow Microsoft's DTV-DVD decoder in the chain?

Also nekromantik if the Microsoft DTV-DVD decoder is active then you are not actually bitstreaming at all.

Ah thanks.
That's strange issue.
Hope LAV fix it as I want to use lav and bitstream.

[Zachs]

Ah thanks.
That's strange issue.
Hope LAV fix it as I want to use lav and bitstream.
Fix what? Is there a problem with LAV bitstream?

[nekromantik]

Fix what? Is there a problem with LAV bitstream?

Yes.
If you enable bit stream you get cannot render error like above posts talk about.
Also I'm having issues with lav not being used in mpc hc when bit stream selected. Instead it loads Microsoft decoder.

[Zachs]

Ah ic. You should report that bug in the LAV thread then.

[romulous]

If you are talking about LAV not automatically falling back to non-bitstream when it can't actually bitsream for whatever reason, that isn't a bug. It is simply a feature that nev has not implemented.

[nekromantik]

Ok will see if I can request that feature.

[ryrynz]

Ok will see if I can request that feature.

Nev has that on his list and at a reasonably high priority already


Also I'm having issues with lav not being used in mpc hc when bit stream selected. Instead it loads Microsoft decoder.

That's not LAV's fault, you have an issue with your receiver not accepting the stream or something is not set up right.

[Zachs]

We discussed this issue earlier Zach, which lead me to post this (http://forum.doom9.org/showthread.php?p=1703377#post1703377) in LAV's thread.

The issue I was with LAV not supporting automatic fallback for down mixing and MPDN not accepting anything other than LAV I also got the rendering error.

Maybe you could allow Microsoft's DTV-DVD decoder in the chain?

Also nekromantik if the Microsoft DTV-DVD decoder is active then you are not actually bitstreaming at all.

I've implemented fallback using DirectShow's default intelligent connect mechanism when LAV Audio fails to connect and will be in the next release. This should allow any compatible filters to take its place when it fails.

[Zachs]

If you are talking about LAV not automatically falling back to non-bitstream when it can't actually bitsream for whatever reason, that isn't a bug. It is simply a feature that nev has not implemented.

I was talking about LAV not able to bitstream properly to his receiver when he believes it should. In fact, this was the problem he had with MPDN. MPDN only uses LAV audio decoder and does not have a fallback mechanism, so all his problems with MPDN not being able to open his files basically goes back to this one problem where he's either failed to set up bitstream properly or it could really be a bug in LAV Audio Decoder. It is this bug that I asked him to report.

[romulous]

Ah. An odd issue - if you have MPDN set to on top, click away from MPDN (so it is no longer active), and then click on the MPDN window - on one of the menus - then the menu does not activate as I expect it would. It takes another click to make the menu activate.

[Zachs]

Ah. An odd issue - if you have MPDN set to on top, click away from MPDN (so it is no longer active), and then click on the MPDN window - on one of the menus - then the menu does not activate as I expect it would. It takes another click to make the menu activate.

That's how .NET's menu behaves, regardless of whether it is set to always on top.

EDIT: Anyway, I've implemented a workaround to make it do what you want.

[Blackfyre]

Zachs, the latest version broke Fluid Motion with SVP again... back to the delayed frames issue from before... I reverted back to a backup I had saved of the last version.

[nekromantik]

Nev has that on his list and at a reasonably high priority already



That's not LAV's fault, you have an issue with your receiver not accepting the stream or something is not set up right.

its not my AV as same laptop can bitstream from PowerDVD fine.
So I must need to change something which I cant see what or there is bug with LAV.

[nekromantik]

Quick question, what's the recommended script chain to upscale 720p to 2160p?

[Shiandow]

If your GPU can handle it I'd recommend SuperChromaRes, followed by SuperRes with NEDI enabled. I think using NEDI is necessary in this case; the current version of SuperRes doesn't perform too well when it needs to scale more than 2x without using NEDI. If SuperRes is too slow you can try using NEDI on its own, or just regular Lanczos (6 taps) with anti-ringing, maybe add some sharpening using -Vit-'s finesharp shaders (http://forum.doom9.org/showthread.php?t=171346). For MadVR I'd recommend Jinc but I'm not too fond of MPDN's implementation of Jinc, I find it too blurry, but maybe you like it (it does hide aliasing better).

[Anima123]

I have tested the latest version of MPDN, and found SuperRes with NEDI enabled still suffers rendering time increasing issue, which makes it impractical for normal playback to me. I do wish Shiandow can resolve this specific issue in the near future, I would like do any help I can to resolve this issue.

The DX 11 presentation API works great though.

[nekromantik]

If your GPU can handle it I'd recommend SuperChromaRes, followed by SuperRes with NEDI enabled. I think using NEDI is necessary in this case; the current version of SuperRes doesn't perform too well when it needs to scale more than 2x without using NEDI. If SuperRes is too slow you can try using NEDI on its own, or just regular Lanczos (6 taps) with anti-ringing, maybe add some sharpening using -Vit-'s finesharp shaders (http://forum.doom9.org/showthread.php?t=171346). For MadVR I'd recommend Jinc but I'm not too fond of MPDN's implementation of Jinc, I find it too blurry, but maybe you like it (it does hide aliasing better).

Thanks :)

[Anima123]

I have tested the latest version of MPDN, and found SuperRes with NEDI enabled still suffers rendering time increasing issue, which makes it impractical for normal playback to me. I do wish Shiandow can resolve this specific issue in the near future, I would like do any help I can to resolve this issue.

Since I have a nVidia 880M which means I can do more testing on MPDN and the rendering scripts.

Now I found that when using SuperChromaRes + SuperRes (NEDI off) as a chain, it will suffer from similar rendering time increasing issue that I've been reported, while use SuperRes (NEDI off) alone be okay.

If I remember correctly, SuperChromaRes also uses a kind of variant NEDI algorithms, which makes me wondering if the issue reside in the implementation of NEDI itself somehow.

[Shiandow]

SuperChromaRes doesn't use NEDI in any way. But it does use a few additional textures, so it might be that that's triggering the problem. You could try forcing MPDN to use more textures by resizing to various different sizes and see if that causes the same problem.

[nekromantik]

Since I have a nVidia 880M which means I can do more testing on MPDN and the rendering scripts.

Now I found that when using SuperChromaRes + SuperRes (NEDI off) as a chain, it will suffer from similar rendering time increasing issue that I've been reported, while use SuperRes (NEDI off) alone be okay.

If I remember correctly, SuperChromaRes also uses a kind of variant NEDI algorithms, which makes me wondering if the issue reside in the implementation of NEDI itself somehow.

After how long does the rendering time increase?
I will test over weekend on my 860m.

[Zachs]

Zachs, the latest version broke Fluid Motion with SVP again... back to the delayed frames issue from before... I reverted back to a backup I had saved of the last version.

I just tested this myself with the latest version and found it working just fine. However, I have a feeling what might've caused this - the changes I made to try and make Optimus work better. This may have turned out be to the detriment of regular users.

I will revert the changes.

EDIT: Can you test v2.17.1? If you still get the error, change the back buffer count for both windowed and exclusive to 16. That brings it back to the earlier version, which causes problems for Optimus (whereas 12 seems to work fine).

[Zachs]

After how long does the rendering time increase?
I will test over weekend on my 860m.

IIRC, you have to let it run for around half an hour to get to double the original render time.

[nekromantik]

Maybe have two versions one for optimus and one for non?

[Zachs]

Maybe have two versions one for optimus and one for non?

With v2.17.1, you can change back buffer count and 12 should work for all. It's only when you find that it's causing delays / drop frames that you should increase to 16. In which case, Optimus users may find it to be unusable (NVidia could fix it tomorrow for all we know, then the Optimus build will be completely useless).

[Anime Viewer]

Maybe have two versions one for optimus and one for non?
Simpler than that would be a check box for Optimus systems. Putting a check in a box that says something like: Optimus equipped system would not require Zachs to put out an extra version which is simply one more version to become buggy, and require extra troubleshooting and configuration files.

With v2.17.1, you can change back buffer count and 12 should work for all. It's only when you find that it's causing delays / drop frames that you should increase to 16. In which case, Optimus users may find it to be unusable (NVidia could fix it tomorrow for all we know, then the Optimus build will be completely useless).
Would a check box somewhere in the settings area similar to mentioned above be feasible? I doubt many Optimus users are going to know they should change their buffers from 12 to 16 especially if they didn't/don't read the post on the forum explaining it.
Did someone with an Optimus system already confirm that 16 buffers did indeed improve playback?

[Zachs]

Simpler than that would be a check box for Optimus systems. Putting a check in a box that says something like: Optimus equipped system would not require Zachs to put out an extra version which is simply one more version to become buggy, and require extra troubleshooting and configuration files.


Would a check box somewhere in the settings area similar to mentioned above be feasible? I doubt many Optimus users are going to know they should change their buffers from 12 to 16 especially if they didn't/don't read the post on the forum explaining it.
Did someone with an Optimus system already confirm that 16 buffers did indeed improve playback?

I would think 16 buffers made Optimus systems worse. I'm not sure, but the default 12 should work best for everyone. Blackfyre isn't using an Optimus system - so for some users (some drivers), they may find it better with 16. The thing is, there isn't one consistent report of weird behavior coming out of Optimus users - it's all over the place. The reason I added the option to change back buffer sizes is because I could see the difference with NVIDIA's v340 on my GTX560. So there's actually no Optimus specific settings. In fact, I think it is so highly reliant on the driver (or its specific bugs) that it is impossible to create "an Optimus setting".

EDIT:
What I am trying to achieve is to allow all the parameters that could affect the performance / stability / behavior of a GPU / driver combo to be tunable (i.e. these settings trigger difference code paths in the driver). Then, if someone finds a setting + driver combo that works best, others would benefit too.

[Blackfyre]

I just tested this myself with the latest version and found it working just fine. However, I have a feeling what might've caused this - the changes I made to try and make Optimus work better. This may have turned out be to the detriment of regular users.

I will revert the changes.

EDIT: Can you test v2.17.1? If you still get the error, change the back buffer count for both windowed and exclusive to 16. That brings it back to the earlier version, which causes problems for Optimus (whereas 12 seems to work fine).

Yep you're right Zachs, that fixed it. Also great job adding control over the buffer counters... I wonder if we can increase it to 24 or 32 for those who can handle it.

:thanks:

By the way I done some testing with two different PC's (both my friends) and it seems my SVP settings are too strong for low-end, and medium-end PC's to handle. But I'll post them up for people anyway.

[Zachs]

Yep you're right Zachs, that fixed it. Also great job adding control over the buffer counters... I wonder if we can increase it to 24 or 32 for those who can handle it.

:thanks:

By the way I done some testing with two different PC's (both my friends) and it seems my SVP settings are too strong for low-end, and medium-end PC's to handle. But I'll post them up for people anyway.

16 is the max Direct3D supports, unfortunately.

As long as you state what PC you used, people can decide and try it on their own PC.

[Blackfyre]

16 is the max Direct3D supports, unfortunately.

As long as you state what PC you used, people can decide and try it on their own PC.

Yeah I'll write the full-specs... BTW there's still one thing which the older version was doing "better"...

You know how my refresh rate is 65... The older version with Fluid Motion + SVP Enabled used to fluctuate between 64.500 fps to 64.990 fps, while the new version fluctuates between 63 fps to 65 fps (not 100% sure of the numbers but you get the idea).

The older version was trying to push itself more and more to get as close as possible to the refresh rate (I want that; in fact if I can lock it at the refresh-rate that would be great) aka without any fluctuation. But yeah that's it, that's the only difference now.

[Zachs]

Yeah I'll write the full-specs... BTW there's still one thing which the older version was doing "better"...

You know how my refresh rate is 65... The older version with Fluid Motion + SVP Enabled used to fluctuate between 64.500 fps to 64.990 fps, while the new version fluctuates between 63 fps to 65 fps (not 100% sure of the numbers but you get the idea).

The older version was trying to push itself more and more to get as close as possible to the refresh rate (I want that; in fact if I can lock it at the refresh-rate that would be great) aka without any fluctuation. But yeah that's it, that's the only difference now.

I don't think I have changed anything that would affect it - try the following settings (which would give you exactly what the older version did):

Back Buffer (both): 16
Render Queue: 12
Decoder Queue: 16

[Anime Viewer]

EDIT: Can you test v2.17.1? If you still get the error, change the back buffer count for both windowed and exclusive to 16. That brings it back to the earlier version, which causes problems for Optimus (whereas 12 seems to work fine).

With v2.17.1, you can change back buffer count and 12 should work for all. It's only when you find that it's causing delays / drop frames that you should increase to 16. In which case, Optimus users may find it to be unusable (NVidia could fix it tomorrow for all we know, then the Optimus build will be completely useless).



I would think 16 buffers made Optimus systems worse. I'm not sure, but the default 12 should work best for everyone.

EDIT:
What I am trying to achieve is to allow all the parameters that could affect the performance / stability / behavior of a GPU / driver combo to be tunable (i.e. these settings trigger difference code paths in the driver). Then, if someone finds a setting + driver combo that works best, others would benefit too.

16 is the max Direct3D supports, unfortunately.


I don't think I have changed anything that would affect it - try the following settings (which would give you exactly what the older version did):

Back Buffer (both): 16
Render Queue: 12
Decoder Queue: 16

On the subject of queue sizes and finding optimal settings. Might changing any of those reduce (or even effect) the XySubFitler problem (the one you and I encountered on the short test video clip end credits), or is there a buffer control setting that might be able to be implemented for subtitle filters themselves? (In MPC-HC there is also a Sub pictures to buffer setting. Since mpc-hc/madVR running the same video with XySubFilter as the selected Sub filter doesn't have a problem with that ending credits scene (the buffers still fluctuate, but never drop to zero) perhaps subtitle buffering is making a difference.)

[Zachs]

On the subject of queue sizes and finding optimal settings. Might changing any of those reduce (or even effect) the XySubFitler problem (the one you and I encountered on the short test video clip end credits), or is there a buffer control setting that might be able to be implemented for subtitle filters themselves? (In MPC-HC there is also a Sub pictures to buffer setting. Since mpc-hc/madVR running the same video with XySubFilter as the selected Sub filter doesn't have a problem with that ending credits scene (the buffers still fluctuate, but never drop to zero) perhaps subtitle buffering is making a difference.)

There's just the one decoder queue that holds both the subpic and the video image. Increase the decoder queue count and you should get the same behavior as MPC-HC / madVR.

[Anime Viewer]

There's just the one decoder queue that holds both the subpic and the video image. Increase the decoder queue count and you should get the same behavior as MPC-HC / madVR.

In my testing (so far) increasing the decoder queue doesn't appear to have reduced or stopped the problem of the XySubfilter draining the queue(s) during the credits of that video in MPDN.

[Zachs]

In my testing (so far) increasing the decoder queue doesn't appear to have reduced or stopped the problem of the XySubfilter draining the queue(s) during the credits of that video in MPDN.

Even at maximum size? On my system it is enough to get through that bit where it drains the queue. MadVR does implement multi-subpic support which would explain the difference. MPDN (currently) asks XySubFilter to combine the subpic into one image, so that might be the reason why it's slower. Enhancing XySubFilter support is on my todo list but that todo list seems to be getting longer and longer :)

[Zachs]

I've updated the DisplayChanger player extension on GitHub.

You can now specify restrictions to the video you want to have it automatically change display frequency.
For example,

w1920p24 matches videos @ width 1920, progressive 24fps
p30 matches all pregressive videos @ 24fps
h800 matches videos @ height 800
w800h600p24 matches videos @ 800x600, progressive 24fps

Alternatively you could specify multiple OR'd restrictions (delimited by space):
p59 p60 w1920p24 h576p25

Note that if you have LAV Video Decoder set to deinterlace the video, then you will only get 'p' (progressive) inputs where MPDN is concerned. Display changer currently does not support interlaced modes yet - but it's an easy change. It could be useful for playing interlaced materials on interlaced screens, I suppose.

Oh, and DisplayChanger will always choose the highest multiples available - e.g. for a 30fps video, it'll pick 120hz if 30, 60 and 120 are available.

[Zachs]

Since I have a nVidia 880M which means I can do more testing on MPDN and the rendering scripts.

Now I found that when using SuperChromaRes + SuperRes (NEDI off) as a chain, it will suffer from similar rendering time increasing issue that I've been reported, while use SuperRes (NEDI off) alone be okay.

If I remember correctly, SuperChromaRes also uses a kind of variant NEDI algorithms, which makes me wondering if the issue reside in the implementation of NEDI itself somehow.

With the latest MPDN, could you also try changing the number of backbuffers and render queue size (e.g. reduce to 4) to see if any of the settings makes any difference?

[ryrynz]

I'd recommend Jinc but I'm not too fond of MPDN's implementation of Jinc, I find it too blurry, but maybe you like it (it does hide aliasing better).

Jinc is a popular resizer with MadVR users, perhaps Nicolas Robidoux could assist with settings that be be used to improve it. Could be worth having two versions of it, the current implementation and a sharper one more in line with MadVR's version.