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

Belphemur

23rd July 2015, 09:51

Yeah got that earlier today, didn't bother reporting it as they know what's up, figured I'd just wait it out.

Will do.

Sorry for this, it was my doing. I upgraded to the last version of Visual Studio and didn't pay attention that I was using the C# syntax (that isn't supported by MPDN). I commited my changes to correct this. Now the source version available on github works with MPDN.

ryrynz

23rd July 2015, 10:36

Sorry for this, it was my doing. I upgraded to the last version of Visual Studio and didn't pay attention that I was using the C# syntax (that isn't supported by MPDN). I commited my changes to correct this. Now the source version available on github works with MPDN.

Yeah, I've been following that :) I've encountered this a few times already during MPDN's development so no big deal.
I suppose though if the main branch is going to be considered kinda stable (I think that might be the case) it could be worth giving the code a quick test first before submitting for a merge.

Also Garteal got caught out not submitting the regex config fix both you and I gave him a heads up on before 1.10 got released, so it's probably good practice
to make sure the submission is stable. But hey, it's not like it's a drama if it isn't. Everyone seems to be pretty hot on the code here.. quite refreshing really.

Zach is it possible to give the master a version number so the updater doesn't prompt to update the extensions to the latest released possibly earlier code version? Perhaps all commits could add 0.0.1 or 0.0.0.1?
Whatever works..

Zachs

23rd July 2015, 13:18

Zach could you make the OSD only display when the player switches to fullscreen after loading a file when 'launch media in fullscreen mode' is active?
I got a nice big OSD flashing up for a moment before it changed to fullscreen.

It only shows the OSD after going to fullscreen mode. In fact, the code to switch to fullscreen comes before the OSD display code...

Zachs

23rd July 2015, 13:21

Zach is it possible to give the master a version number so the updater doesn't prompt to update the extensions to the latest released possibly earlier code version? Perhaps all commits could add 0.0.1 or 0.0.0.1?
Whatever works..

You mean when you're using the source code instead of the binaries? If so can you put a request on GitHub to get the update checker to auto disable when the source version is used?

Zachs

23rd July 2015, 13:46

Presentation API: Direct3D 10.1, image quality: render performance (on image quality play fine) , GF GT 320M , Win7x64

EDIT: Problem 2:
image quality: render performance, XySubfilter -> subtitles ok
image quality: image quality, XySubfilter -> black rectangle around subtitles.

The first issue you encountered has now been fixed.

Problem #2 I can't reproduce though...

ryrynz

23rd July 2015, 14:03

You mean when you're using the source code instead of the binaries? If so can you put a request on GitHub to get the update checker to auto disable when the source version is used?

Will do. Could be an idea just ignoring the latest binary releases I guess.

It only shows the OSD after going to fullscreen mode. In fact, the code to switch to fullscreen comes before the OSD display code...

There's something funky going on there.. maybe it had reached fullscreen mode at the time it displayed the OSD, the OSD did stretch though on resize.

aufkrawall

23rd July 2015, 18:00

Sinc-Blackman 8 taps w.o. AR seems to be a great chroma scaler.
MPDN S-B:
http://abload.de/thumb/mpdns-b8hju3h.png (http://abload.de/image.php?img=mpdns-b8hju3h.png)

madVR Jinc3AR:
http://abload.de/thumb/madvrjincartiupp.png (http://abload.de/image.php?img=madvrjincartiupp.png)

But enabling AR filter of MPDN is a bad idea for chroma, it becomes blurry by this.

Btw: Bicubic 50 in madVR is pretty much bicubic 100 in MPDN.

Volfield

23rd July 2015, 18:10

The first issue you encountered has now been fixed.

Problem #2 I can't reproduce though...

Is there any way for me to help you find solution?

P.S. screenshots include

aufkrawall

23rd July 2015, 18:40

I just discovered that the OpenCL implementation of NNEDI3 looks worse than the other.

OpenCL:
http://abload.de/thumb/mpdnopencl21sef.png (http://abload.de/image.php?img=mpdnopencl21sef.png)

PS5.0:
http://abload.de/thumb/mpdnjpsb7.png (http://abload.de/image.php?img=mpdnjpsb7.png)

(look at the doorframe, image is exactly doubled per axis)

Is it supposed to be that way? MPDN OpenCL and madVR OpenCL look the same. btw.

Anima123

23rd July 2015, 18:59

More aliasing in OpenCL version. BTW, does madVR have PS 5.0 implementation of NNEDI3?

aufkrawall

23rd July 2015, 19:11

More aliasing in OpenCL version.

Exactly.

BTW, does madVR have PS 5.0 implementation of NNEDI3?
No, but madshi is not against it (however, no etas as usual).

Btw: I'd really love to see options in the MPDN GUI/extensions for defining doubling/quadrupling settings like in madVR. :)

madshi

23rd July 2015, 22:12

I just discovered that the OpenCL implementation of NNEDI3 looks worse than the other.
It's always dangerous to base such conclusions on just one image... ;)

Without having looked into the matter, one wild guess would be that the OpenCL implementation might scale X first while PS5.0 might scale Y first, or vica versa. Doing that will change the angle of the lines, which can have a huge impact on the aliasing, especially when using a low neuron count.

You could try rotating the image 90° before scaling, as a double check. Does that make the two variants look identical?

aufkrawall

23rd July 2015, 22:51

lul what
Nice guess, sir! :eek:

OpenCL:
http://abload.de/thumb/openclj6beh.png (http://abload.de/image.php?img=openclj6beh.png)

PS5.0:
http://abload.de/thumb/ps56jymw.png (http://abload.de/image.php?img=ps56jymw.png)

Zachs

24th July 2015, 00:41

Is there any way for me to help you find solution?

P.S. screenshots include

The screenshots links are broken but do you get this problem with every file with subtitles or just specific ones?

Zachs

24th July 2015, 00:51

Btw: I'd really love to see options in the MPDN GUI/extensions for defining doubling/quadrupling settings like in madVR. :)

The "Conditional" script was created exactly for such a thing.

You can easily replicate madVR's simple behaviour with it but it's a lot more powerful - e.g. you can double with NNEDI3, then double again with NEDI or Super-xBR (or with NNEDI3 again, with the same or different number of neurons), only when it's required. Or you can have 3 in the chain to give you 8x, or 4 to get 16x etc.

Zachs

24th July 2015, 01:05

lul what
Nice guess, sir! :eek:

Yes, it depends on which direction it scales first (and OclNNEDI3 is the opposite of the SM5 version). The second pass will result in lower quality. It may be a good idea then to scale first pass with higher neurons.

Go ahead and create a request on GitHub for separate neuron settings for each pass. Either Shiandow or myself could add the feature when we get to it. Or anyone else who wants to have a play with the render script. It's a very small change so might be a good place to start if you want to learn.

Zachs

24th July 2015, 01:14

Volfield

24th July 2015, 04:47

The screenshots links are broken but do you get this problem with every file with subtitles or just specific ones?

http://imgur.com/LQKSGcr,sxEUjSs#0

Every file(ass,str,txt).

Zachs

24th July 2015, 05:04

That's strange. I just can't replicate the problem on any of my systems...
Do you have any render scripts running?
Could you send me your config folder so I could try and see if there's anything else that might be needed to trigger the problem?

Volfield

24th July 2015, 05:09

Anima123

24th July 2015, 05:30

When using nnedi3 as image doubler, the resulted image has a lot of little cubic as mosaic, look like the following
https://www.dropbox.com/s/mukmjum4o9dphld/MPDN_nnedi3_mosaic.png?dl=0

There's no similar problem with madVR.

nVidia 880M with 350.30 driver, windows 8.1 64-bit.

Zachs

24th July 2015, 05:38

Does this happen with all the files or just this?

Anima123

24th July 2015, 05:41

Just tested with lower resolution videos, no this effect.

The one that I found that has this problem is when upscaling 1024x576 -> 1920x1080. Not sure other resolutions been affected though.

Zachs

24th July 2015, 05:47

Just created an image with a resolution of 1024x576 to test. I'm not seeing the mosaic effect with either NNEDI3 implementation. LAV Video Decoder set to NV12 only to simulate the typical video file output format. I've also tried with the various settings of different scalers, with or without super res etc.

NVS 4200M with 353.30, Win8.1 64-bit too.

EDIT: Are you by any chance using Bicubic 100 AR chroma upscaling? I think I found a problem with it but I don't understand why... It seems setting sharpness to 99 fixes it, if that's the same problem.

EDIT2: Nevermind. Found the cause. Will be fixed in the next release. As a temporary workaround, don't use the same settings for upscaler and downscaler. For example, if you use bicubic 100 for upscaler, and you want to use the same for downscaler, select 99 for sharpness instead. It's to do with how MPDN caches weights for render scripts.

Zachs

24th July 2015, 05:52

https://mega.nz/#!pZ0QXbDA!Dg2YFWkspvLcjTkkflARqmC-ClQdipsmc7y9y3UQHeU

I just tested your config file with Image Quality set as trade-off mode and it works fine... Not sure why you're seeing the problem. That's especially strange since both Image Quality and Render Performance modes use the UNORM textures thus share the exact same code.

Belphemur

24th July 2015, 09:40

Is there any way for me to help you find solution?

P.S. screenshots include

Which version of XySubFilter are you using ?

aufkrawall

24th July 2015, 17:24

Shiandow, do you want to take a look at this sample?
It has severe banding which gives your deband filter a real struggle.
http://www18.zippyshare.com/v/0Jil84gy/file.html

Shiandow

24th July 2015, 17:37

Shiandow, do you want to take a look at this sample?
It has severe banding which gives your deband filter a real struggle.
http://www18.zippyshare.com/v/0Jil84gy/file.html

You need something more than a debanding filter to get rid of banding that bad. Heck even I am not sure if some of it may not have been intentional (the circular band accros Turkey and Syria sure seems to be). It might be better to use a denoising filter for this.

aufkrawall

24th July 2015, 18:01

Volfield

24th July 2015, 19:27

Which version of XySubFilter are you using ?

XysubFiler 3.1.0.705

Shiandow

24th July 2015, 23:14

madVR deband with most aggressive settings takes mostly care of it. :)
I think the banding accross Turkey and Syria is because of some kind of vignette effect. Yes, it's terrible content, but I think it's still "unwanted" banding.

Well I agree that it's unwanted, I'm just not sure how to classify it, it really seems to be closer to 'noise' than simple banding. If it had occurred in a reliable source I'd have concluded that it was meant to be there. It's also interesting to note that MadVR set to high starts to remove the 'intentional' band across Turkey and Syria, and even MadVR doesn't successfully remove all the banding.

By the way, if you haven't tried it already, there's been a very recent update to the debanding filter which might help a little (although fixing this image is till beyond it). It should be available in the next release of the extensions, or you can just download the source.

Anyway, thanks for the feedback!

Marnes

24th July 2015, 23:15

Yes this is the right place to report bugs.

I have tested this several times (over 10 times) and couldn't replicate it. If only a reboot can make it go away, that suggests it's something persistent that would go beyond the life-time of a user-mode application. As such it's unlikely to be an MPDN bug.

Guess it must be a video driver problem or something then...

On a different note, will there be improvements to startup speed and such soon? I've been a big fan of mpdn for a while now because the image quality is so good, resource usage is low and the fluid motion filtering is just perfect, but I didn't realize until I installed potplayer that mpdn easily takes 5x as long to open and start playing. Even with my fast ssd, mpdn takes kinda annoyingly long to open when you're trying to go through many files. I tried to look for a replacement for fluid motion (the main reason I don't want to use other players anymore) but all that's available is interframe (haloing artifacts and different end goal) and other avisynth stuff (tedious to set up).

burfadel

24th July 2015, 23:53

Not sure what version of NET Framework it is compiled in. Not sure if compiling with NET Framework 4.6 (Windows 10) would change performance any.

aufkrawall

25th July 2015, 00:20

Well I agree that it's unwanted, I'm just not sure how to classify it, it really seems to be closer to 'noise' than simple banding. If it had occurred in a reliable source I'd have concluded that it was meant to be there. It's also interesting to note that MadVR set to high starts to remove the 'intentional' band across Turkey and Syria, and even MadVR doesn't successfully remove all the banding.

Yes, still some banding can be perceived. However, I think the high setting is a good compromise between sustaining detail and fighting banding.
My interpretation of this map would be that it's not supposed to contain any banding. There are many gradients, which I think should be smooth and are just meant as eye candy.

By the way, if you haven't tried it already, there's been a very recent update to the debanding filter which might help a little (although fixing this image is till beyond it). It should be available in the next release of the extensions, or you can just download the source.

Anyway, thanks for the feedback!
Will try the next extensions, I'm really bad with anything text/script-related.
I hope my feedback can be helpful in some way.

Marnes

25th July 2015, 01:19

Would it be possible to invert the color scheme on the status bar when the black theme is enabled btw? The black-on-white bar is a bit of an eye sore right now while everything else is dark.

I feel I should point out that I do appreciate Zach's and everyone else's (if anyone, I've no clue about the project's scale) work on mpdn :) It's a great player

aufkrawall

25th July 2015, 01:26

BTW, while we're on the subject, has anyone noticed the SM5 NNEDI3 is now around 10% faster with the same neurons vs OpenCL with the recent Nvidia drivers? At least on my Fermi cards, it was neck and neck (with SM5 just a touch faster) when we first implemented it. We haven't updated the NNEDI3 code and the only thing that's changed would've been the drivers. Just wondering if anyone's noticed the speed improvements.
With Maxwell 2.0, OpenCL is still a bit faster, but they are almost equal. In my memory, the gap was wider, maybe SM5 has really improved by driver.
My benchmark results (720p -> WQHD 64 neurons, chroma bicubic, max quality mode, everything else turned off, GTX 980 OC 353.49 driver on Windows 10):

OpenCL:
~20,5ms
~47% GPU usage
1126mhz

SM5:
prefer vector:
~22,7ms
~50% GPU usage
1126mhz

prefer scalar:
~24ms
~54% GPU usage
1278mhz

madVR result is interesting too, it's quite faster:
~13,9ms (maybe can't be compared directly)
~34% GPU usage
1126mhz

Both renderers used D3D11 and the same settings/queue lengths, as far as this can be possible.

Zachs

25th July 2015, 04:14

You'll need to cripple MPDN a bit for a fair comparison. MadVR doesn't have a max quality mode.

aufkrawall

25th July 2015, 13:20

Is MPDN's processing queue using more than 16 bit in max quality mode?

huhn

25th July 2015, 13:29

http://forum.doom9.org/showpost.php?p=1692075&postcount=3

looks like max quality is still using 32 bit float.

foxyshadis

25th July 2015, 13:38

Yes, still some banding can be perceived. However, I think the high setting is a good compromise between sustaining detail and fighting banding.
My interpretation of this map would be that it's not supposed to contain any banding. There are many gradients, which I think should be smooth and are just meant as eye candy.

Will try the next extensions, I'm really bad with anything text/script-related.
I hope my feedback can be helpful in some way.

My interpretation is that it's not possible to correct all encoding defects. I actually don't see any problem with the green nations, perhaps because mine is set a little higher than yours, but the blue water is horrifying. That looks like round-off, encoding, further processing, then round-off and re-encoding. What it does dither well (the green area) still improves the quality, even if it doesn't improve it maximally.

aufkrawall

25th July 2015, 15:08

Go ahead and create a request on GitHub for separate neuron settings for each pass.
*sigh*, not something a person not used to GitHub could do in three seconds, it seems?

ryrynz

26th July 2015, 04:12

*sigh*, not something a person not used to GitHub could do in three seconds, it seems?
Either he or Shiandow will get around to it, just create the request and wait. You likely won't be waiting terribly long.

Zachs

26th July 2015, 05:52

*sigh*, not something a person not used to GitHub could do in three seconds, it seems?

Well, GitHub isn't any more complicated than your typical issue tracking system.

Anyway the link is here: https://github.com/zachsaw/MPDN_Extensions/issues

Zachs

26th July 2015, 05:56

On a different note, will there be improvements to startup speed and such soon? I've been a big fan of mpdn for a while now because the image quality is so good, resource usage is low and the fluid motion filtering is just perfect, but I didn't realize until I installed potplayer that mpdn easily takes 5x as long to open and start playing. Even with my fast ssd, mpdn takes kinda annoyingly long to open when you're trying to go through many files. I tried to look for a replacement for fluid motion (the main reason I don't want to use other players anymore) but all that's available is interframe (haloing artifacts and different end goal) and other avisynth stuff (tedious to set up).

On x86, startup time is nearly instant on my system. For some reason, the .NET framework takes longer to start the x64 edition. The rest of the time it's to do with loading and initialising render scripts etc. Unless PotPlayer has something as sophisticated and as advanced as MPDN's features, you really can't compare the two.

aufkrawall

26th July 2015, 19:21

Well, GitHub isn't any more complicated than your typical issue tracking system.

Anyway the link is here: https://github.com/zachsaw/MPDN_Extensions/issues
Oops, sorry. I confused it with "pull request".
Have written an issue. :)

Regarding doubling/quadrupling: Yes, such scripts are very powerful, but you have to spend quite some time to get along with it. Thus a simple GUI option would be nice.

With my NNEDI3 tests, I recognized that under heavy load, the render queues sometimes don't fill up completely unless video is paused and then resumed.
Therefore, an option to fill up the queues before playing would be nice.

With default quality mode, MPDN OpenCL is even a little faster than madVR:
~13,34ms
~30% GPU usage
1126mhz

Is that "image quality" preset full 16bit like madVR?

madshi

26th July 2015, 19:26

FWIW, it's hard to make this a perfect apples to apples comparison. E.g. which algorithm is used by either madVR or MPDN to upscale chroma, when luma is doubled with NNEDI3? Which algorithm is used to fix the NNEDI3 pixel shift (if fixing is needed) etc. In order to get a 100% comparable situation all algorithms need to be 100% identical. Which is difficult because e.g. anti-ring filter implementations are different etc.

aufkrawall

26th July 2015, 19:41

Zachs

27th July 2015, 01:28

I used bicubic resizing otherwise which looks "almost" completely identical and else turned everything off that can be turned off (AR filter, dithering etc.), same queue lengths etc.
But no guarantee for pixel shift correction. Anyway, the difference in GPU load is neglectable.
That reported load is not very accurate:
When I set OpenCL NNEDI3 in madVR to 128 neurons, I don't have anymore than 90% load reported, but power consumption is very high despite of this.

General question: Next year's GPUs will have much faster FP16 processing due to "mixed precision". Will this be helpful for video renderers?

Well MPDN no longer uses FP16 - it uses 16-bit integer - for its default mode (Image Quality mode). I believe madVR also introduced it shortly after MPDN did. But I suppose if you use Render Performance / Max Render Performance modes, it might be faster... unless they also have a UNORM16 processing mode... who knows.

aufkrawall

27th July 2015, 01:38

Ok, I managed to make conditional render scripts do what I want them to do.
The result is NNEDI3 64 quadrupling via SM5.0 + AdaptiveSharpen after each doubling. Thanks a lot, Zachs and Shiandow! :)
My new favorite chroma scaler for this player is Jinc16 AR (of MPDN itself) + SuperChromaRes (1 pass, 2 strength, 0 softness).
It looks very much like Jinc AR of madVR.
So, if debanding would look better with stuff like bad news broadcasts I'd be almost totally happy with image quality.
Almost, because see the following.

Some strange observations:
MPDN D3D9 and 11 don't give equal results, with bilinear TMU scaling pixels differ (each red pixel has a different color between d3d9 and 11):
http://abload.de/thumb/d3d11vs9mpdnm7u01.png (http://abload.de/image.php?img=d3d11vs9mpdnm7u01.png)
This is not the case with madVR, with it D3D9 and 11 look the same.

I also notice that MPDN is a bit darker than madVR. You can see it best at the wall behind the stairs:
MPDN D3D9:
http://abload.de/thumb/mpdnd3d9m3b9v.png (http://abload.de/image.php?img=mpdnd3d9m3b9v.png)

madVR D3D9:
http://abload.de/thumb/madvrd3d9fibxb.png (http://abload.de/image.php?img=madvrd3d9fibxb.png)

Settings were as much identical as they can be (dithering off, bilinear TMU etc.).

Zachs

27th July 2015, 02:22

That looks like a serious bug to me as I haven't encountered any difference in D3D9 / 11.
Is this with bilinear / dithering off / fluid motion off / improve chroma reconstruction off etc.? Does this happen without NNEDI3?

Could you enable dithering to see if there's any discernible colour difference? I suspect that's just a difference how the rounding is done.