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

[JPulowski]

Hi Zachs,

I am one of the shader developers for ReShade (http://reshade.me). I have a question regarding MPDN's "Deband" render script. In the code it uses s1 sampler to get an average.

Deband.hlsl (https://github.com/zachsaw/MPDN_Extensions/blob/master/Extensions/RenderScripts/Deband/Deband.hlsl):
sampler s1 : register(s1);
...
float4 avg = tex2D(s1, tex);

I took a look at the repository and could not find what is stored in s1. Would you mind enlightening me? :D Thanks. I am asking because some users liked its results and asked for a port, if you don't mind it that is. :)

[burfadel]

Did you extract all of the extensions and place them in the MPDN directory, or just the ones you intended to use?

All the extensions. It was working, then it wasn't!

The version of the playlist extension on Garteal's Github (https://github.com/Garteal/MPDN_Extensions) already does all of this except for that last default list option. It just hasn't been merged yet as it is still being worked on.

That's good, I think it would be an immensely useful feature!

[Zachs]

Trying flushing the extension cache. There's a command line option that allows you to do that --flushcache

[burfadel]

Tried the flushcache option, I still get:
TITLE: Error
------------------------------

An unexpected error 'Mpdn.CriticalException' has occurred.

------------------------------
ADDITIONAL INFORMATION:

One or more extensions failed to load

------------------------------

Cannot parse "//css_import..." (CSScriptLibrary)

------------------------------
BUTTONS:

&Abort
------------------------------

[Shiandow]

Hi Zachs,

I am one of the shader developers for ReShade (http://reshade.me). I have a question regarding MPDN's "Deband" render script. In the code it uses s1 sampler to get an average.

Deband.hlsl (https://github.com/zachsaw/MPDN_Extensions/blob/master/Extensions/RenderScripts/Deband/Deband.hlsl):
sampler s1 : register(s1);
...
float4 avg = tex2D(s1, tex);

I took a look at the repository and could not find what is stored in s1. Would you mind enlightening me? :D Thanks. I am asking because some users liked its results and asked for a port, if you don't mind it that is. :)

Well, I'm not Zachs, but I did design the debanding filter, so I could probably explain what you need to know. That said, I'm sort of wondering what you'd hope to gain by debanding (presumably) 8bit rgb. Were you planning to add dithering? Or is there some other processing you need more than 8bits of precision for?

Anyway, here is a short explanation of the algorithm:

The debanding shader compares a "blurred" image (which is what's stored in s1) to the original image and using the blurred version when the difference is small enough. This blurred version is obtained by downscaling the image by a factor of 2, debanding that (long live recursion!), and then scaling it back to the original size. To prevent infinite recursion you need to stop at some point, either when you can no longer downscale the image, or after some fixed number of steps.

By the way, for up- and down-scaling you might as well simply use hardware linear interpolation, since the debanding algorithm was designed to remove any detail smaller than a rounding error, and most (noticeable) banding occurs on large gradients, so linear interpolation will give more or less the same result as any other algorithm.

[vivan]

About debanding. I've compared it - and it's not as good as madVR's f3kdb (which is very fast - my implementation takes 4ms on 720p frame on adreno 330 - mobile gpu). It's less effective while nuking a bit more details, compared to "high" in madVR. Also it shifts colors for some reason (and mpdn itself shift colors too).

Samples (everything on default with latest versions from the first post):
https://dl.dropboxusercontent.com/u/16254258/android/viavr/rendering/debanding/akame.y4m
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/akame_madvr.png
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/akame_madvr_deb.png
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/akame_mpdn.png
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/akame_mpdn_deb.png

https://dl.dropboxusercontent.com/u/16254258/android/viavr/rendering/debanding/conan2.y4m
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/conan_madvr.png
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/conan_madvr_deb.png
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/conan_mpdn.png
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/conan_mpdn_deb.png

https://dl.dropboxusercontent.com/u/16254258/android/viavr/rendering/debanding/sherlock3.y4m
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/sherlock_madvr.png
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/sherlock_madvr_deb.png
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/sherlock_mpdn.png
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/sherlock_mpdn_deb.png

https://dl.dropboxusercontent.com/u/16254258/android/viavr/rendering/debanding/madoka2.y4m
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/madoka_madvr.png
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/madoka_madvr_deb.png
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/madoka_mpdn.png
https://dl.dropboxusercontent.com/u/16254258/test/video/debanding/madoka_mpdn_deb.png

[madshi]

Shhhh... Don't tell him... :p

[Blackfyre]

Shhhh... Don't tell him... :p

Hahaha!:sly::sly:

[huhn]

I wonder why there is a color shift at all.

[Shiandow]

About debanding. I've compared it - and it's not as good as madVR's f3kdb (which is very fast - my implementation takes 4ms on 720p frame on adreno 330 - mobile gpu). It's less effective while nuking a bit more details, compared to "high" in madVR. Also it shifts colors for some reason (and mpdn itself shift colors too).

Samples (everything on default with latest versions from the first post):
[...]



Hmm, well hopefully madshi was right to worry. After fiddling a bit with the settings I got this (http://i.imgur.com/QwJ1sUJ.png), which seems quite a bit better. I'm not too sure what's happening with the colours though, for some reason the difference seems to be smaller on my end, but I can't figure out why. You didn't happen to use SuperChromaRes did you?

[Shiandow]

Okay, the MPDN have been updated with various bugfixes. Hopefully one of them will fix this (http://forum.doom9.org/showthread.php?p=1713006#post1713006) issue. I've also changed the debanding defaults which should improve the debanding quality slightly.

[vivan]

I haven't touched anything besides selecting "Deband" in "Render Script". And selecting ordered dithering (though selecting random changes nothing).

Increasing strength is easy, not blurring everything at the same time is not (see madoka samples, there're also with 1 and 3 at the end).

[Zachs]

Tried the flushcache option, I still get:

Try deleting your %localappdata%\MediaPlayerDotNet\ScriptAsmCache.* folders. If this still doesn't help, then zip up the correspoding ScriptAsmCache folder (.32/.64/.AnyCPU) and let me take a look.

[Zachs]

Does this mean fluid motion works different than smooth motion?
It's definitely smoother with the latter one.
Player stats don't show any problems with glitches or dropped/delayed frames.

I can't say how well smooth motion works - I've never used it.

Is rendering time suppose to go up tremendously with xysubfilter/xy-vsfilter? I'm getting spike jump from 20ms to 60ms until the video is a stutter feast and the player just hangs. Unchecking the subtitle option stops the rendering time from spiking and it remains constant without any problem. FYI, I do not get such issue with MPC+madvr.

If you see this with xy-vsfilter as well then it is definitely not related to subtitles.

Subtitles still not working.

I've got a question for Zachs: do you plan on ever making this project open source?

1) Subtitle works fine - what do you mean not working?

2) No.

and mpdn itself shift colors too

As compared to?

[Anima123]

With the latest script, I got the following error:
TITLE: SharpDX.Direct3D9 Error
------------------------------

An unexpected error 'SharpDX.CompilationException' has occurred.

------------------------------
ADDITIONAL INFORMATION:

C:\Program Files\MediaPlayerDotNet\memory(13,10): error X1507: failed to open source file: './ColourProcessing.hlsl'
(SharpDX.Direct3D9)

------------------------------
BUTTONS:

&Abort
------------------------------

[Zachs]

With the latest script, I got the following error:
TITLE: SharpDX.Direct3D9 Error
------------------------------

An unexpected error 'SharpDX.CompilationException' has occurred.

------------------------------
ADDITIONAL INFORMATION:

C:\Program Files\MediaPlayerDotNet\memory(13,10): error X1507: failed to open source file: './ColourProcessing.hlsl'
(SharpDX.Direct3D9)

------------------------------
BUTTONS:

&Abort
------------------------------


Do you have ColourProcessing.hlsl in Extensions\RenderScripts\SuperRes folder?

I'm not getting any issues at all with the latest scripts.

[Anima123]

Yes, as I checked, the file's there. Just tried with --flushcache, still the same error.

Edit: BTW, the error occurred when starting to play a video.

[Zachs]

Yeah I tried playing a video with super res and didn't get such errors.

[Anima123]

Weird thing is, that error message is with SuperRes, now with SuperChromaRes, I got these:
TITLE: SharpDX.Direct3D9 Error
------------------------------

An unexpected error 'SharpDX.CompilationException' has occurred.

------------------------------
ADDITIONAL INFORMATION:

C:\Program Files\MediaPlayerDotNet\memory(10,10): error X1507: failed to open source file: '../ColourProcessing.hlsl'
(SharpDX.Direct3D9)

------------------------------
BUTTONS:

&Abort
------------------------------


The only difference between the two is the relative path of ColourProcessing.hlsl, from './' to '../', period.

[Zachs]

Weird thing is, that error message is with SuperRes, now with SuperChromaRes, I got these:
TITLE: SharpDX.Direct3D9 Error
------------------------------

An unexpected error 'SharpDX.CompilationException' has occurred.

------------------------------
ADDITIONAL INFORMATION:

C:\Program Files\MediaPlayerDotNet\memory(10,10): error X1507: failed to open source file: '../ColourProcessing.hlsl'
(SharpDX.Direct3D9)

------------------------------
BUTTONS:

&Abort
------------------------------


The only difference between the two is the relative path of ColourProcessing.hlsl, from './' to '../', period.

OK I have managed to replicate the issue...! Seems that if you put MPDN in a folder that contains spaces it'll fail.

[Anima123]

I've tried everything that I can think of, including clearing the whole program configure folder, no luck.

[Anima123]

My MPDN folder is in 'c:\Program Files\MediaPlayerDotNet\', which indeed has a space in. The error does not occur with previous version as I recall.

[Zachs]

Found the problem. It's due to the fact that you've placed MPDN under Program Files which has restricted file access (read-only).
Will release a new version with the fix.

EDIT: Done.

[Blackfyre]

New issue with the new version... With SVP Enabled I used to get Dropped Frames (xx every second) and 0 delayed frames (when FPS>Monitor Refresh Rate)... With version 2.22.2 (16th of March), delayed frames is emulating dropped frames with no apparent change in the fluidity of the video? So it's reporting wrong... For example, after 5 minutes say there used to be 10000 dropped frames, 0 delayed frames, now delayed frames emulates whatever dropped frames are, so after five minutes both of them would be on 10000, they increase together equally, as if delayed frames is showing dropped frames and not delayed frames.

[Zachs]

Which version did you find it to work? Nothing has changed in regards to that since a month ago.

[Shiandow]

I haven't touched anything besides selecting "Deband" in "Render Script". And selecting ordered dithering (though selecting random changes nothing).

Increasing strength is easy, not blurring everything at the same time is not (see madoka samples, there're also with 1 and 3 at the end).

Those also become blurred with MadVR's debanding, if anything MadVR blurs more. MadVR's method does seem to preserve contrast slightly better, which may or may not be related to MPDN's colour bias, I think it's probably better to fix that first before trying to improve the debanding algorithm.

I may also have found what's causing the colour bias. It seems to be caused by using a resize filter on YUV images. I suspect that some rounding errors make the UV values slightly to low (or high, I'm not too sure which) causing the colours to drift. The same effect probably occurs with the Y channel, but is probably too small to be noticeable. It should be possible to fix this by changing the normalization of the resize kernels. Or alternatively by using UV values between -0.5 and 0.5, but ideally that shouldn't be necessary.

[huhn]

have you unchecked "don't analyze gradient angles for debanding" under trade quality for performance?

and madVR high is pretty extreme and AFAIK it doesn't use a gradient analyze.

[Shiandow]

I have unchecked "don't analyze gradient angles for debanding", although MadVR high indeed doesn't seem to behave any differently if you turn it on. And I agree that MadVR high is pretty extreme, given that it seems to remove more than MPDN does, and MPDN's debanding is pretty permissive already, it tries to remove everything that can be considered a rounding error.

[Blackfyre]

Which version did you find it to work? Nothing has changed in regards to that since a month ago.

You're right Zachs, it was a problem on my end. I accidentally had my second profile enabled in MSI AfterBurner where core clock and memory are both under-clocked at half the speed.

[Zachs]

I found the cause of the difference in colour. I am using a midpoint of 127.5/255.0 (which is 0.5) whereas madVR seems to be using 128.0/255.0 (0.50196) for YUV to RGB conversion. Does anyone know which is the technically correct midpoint?

EDIT: MPDN uses the matrix from http://forum.doom9.org/showthread.php?p=1702321#post1702321 (note the 1/2 midpoint, not 128/255), which is the technically correct one. 128/255 is usually used as an approximation for integer maths. Regardless, I've updated MPDN to match madVR's colour bias.

[Anime Viewer]

EDIT: MPDN uses the matrix from http://forum.doom9.org/showthread.php?p=1702321#post1702321 (note the 1/2 midpoint, not 128/255), which is the technically correct one. 128/255 is usually used as an approximation for integer maths. Regardless, I've updated MPDN to match madVR's colour bias.

How about an option in settings to choose which one to use? I'd prefer to use what is technically correct.

[huhn]

both programs should use 100% the correct one and nothing else.

i don't get this mid point stuff because it doesn't make sense to me with the hole Y= 16-235 and CbCr=16-240 and stuff like this.

[Zachs]

both programs should use 100% the correct one and nothing else.

i don't get this mid point stuff because it doesn't make sense to me with the hole Y= 16-235 and CbCr=16-240 and stuff like this.

Please elaborate on what you mean by "100% the correct one".

[huhn]

Please elaborate on what you mean by "100% the correct one".

i don't know what is correct. i only care that the correct one is used and you said yourself:
EDIT: MPDN uses the matrix from http://forum.doom9.org/showthread.ph...21#post1702321 (note the 1/2 midpoint, not 128/255), which is the technically correct one. 128/255 is usually used as an approximation for integer maths. Regardless, I've updated MPDN to match madVR's colour bias.

[Zachs]

i don't know what is correct. i only care that the correct one is used and you said yourself:

How about an option in settings to choose which one to use? I'd prefer to use what is technically correct.

Adding an option is not an easy thing to do I'm afraid - this involves the values in the shaders which are precompiled. I'm not saying it can't be done - it's just not worth doing...

The reason is, it really comes down to how the encoder encoded the source in the first place. If it's from an RGB source, it may be converted to YUV using an integer math approximation. In which case, it is then more correct to convert it back using the approximation method.

EVR seems to use the approximated formula as well, so it would seem that in this case the popular one isn't the technically correct one.

[Shiandow]

Well, it all comes down to how to get the correct range of UV values. It would have made more sense if it was 127/255 though, that way pure blue would give a U value of 255/255, at the moment it gives 256/255.

[Zachs]

Yeah but I think it all depends on what the industry commonly use for their conversion matrix. If it's 128/255 then we would have to use the same to ensure we get the correct output. 128 seems to be the approximation used everywhere afaics on wiki instead of 127.

I wonder what ASIC encoder implementations employ. Anyone here knows anything?

[ryrynz]

Anyone here knows anything?

I thought you knew things man. :D *couldn't resist*

[madshi]

I would have thought that studying the basic standards is the first thing a video renderer developer would do... :p

(Of course what madVR does is correct. But did I really have to say that? :))

[Zachs]

If you have nothing useful to contribute, please shut up.

[madshi]

madVR's accuracy / technical correctness was questioned. I should be allowed to say that it's accurate.

Try BT.709, search for 128. Or try BT.2020, search for 512. It's not that hard to find.

[huhn]

http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-5-200204-I!!PDF-E.pdf

6.10

– Achromatic Cb, Cr 128

i guess that's it

[Shiandow]

The discussion was about the conversion matrix, which according to the standard here (http://www.itu.int/rec/R-REC-BT.709/en) (page 19 item table 3) has coefficients 0.7874/1.5748 and, 0.9278/1.8556, both of which are exactly equal to 0.5, so it seems that the values MPDN originally used were correct. They do include some extra steps to ensure that the chroma runs from 16 to 240 (inclusive) and such that gray has a chroma of 128.

[madshi]

http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-5-200204-I!!PDF-E.pdf

i guess that's it
Yes, exactly. At the very heart of the BT.709 spec it's defined that Y=16 is black, Y=235 is white, and that Cb/Cr=128 is neutral grey. That's not an approximation, but "the law", which every content is encoded in.

[madshi]

The discussion was about the conversion matrix, which according to the standard here (http://www.itu.int/rec/R-REC-BT.709/en) (page 19 item table 3) has coefficients 0.7874/1.5748 and, 0.9278/1.8556, both of which are exactly equal to 0.5, so it seems that the values MPDN originally used were correct. They do include some extra steps to ensure that the chroma runs from 16 to 240 (inclusive) and such that gray has a chroma of 128.
I'm not sure if those coefficients are correct or not. I don't have "final constants" for that in my source code. I'm calculating the final constants based on a complicated formula, so I can get some more exact numbers (more decimal digits) than listed in the standards. One thing to note is that some of those coefficients listed in the standards might be meant to be used for float 0.0 = black and 1.0 = white, while others might be meant to be used for int 16 = black and 235 = white. Also some might be meant to be used for neutral Cb/Cr = 0.0, while others might be meant for neutral Cb/Cr = 128. Add on top that Direct3D uses a 255 division instead of 256 to convert 8bit int to float, which absolutely makes sense, but is somewhat unusual, too. All of this needs to be carefully thought through to get perfectly accurate results.

I think the key reason why neutral gray is 128 and not 127.5 is that if you want to encode neutral gray with 8bit MPEG2/h264, using 127.5 would just not be possible without dithering. So the standards decided right from the start that 128 must be used for neutral gray. Imagine you want to encode a black & white movie in 8bit, if neutral gray were 127.5 - that would be a nightmare for encoders! And of course, since encoders are using 128 for neutral gray, video renderers must also use 128 to get correct results.

[vivan]

128.0 is a middle point between 16 and 240, and is a neutral chroma in TV range (which is what BT.601/709/2010 are all about).
127.5 is a middle point between 0 and 255, and should be a neutral chroma in PC range: (128 - 16) * 255 / 224 = 127.5 (conversion defined by c̶o̶m̶m̶o̶n̶ ̶s̶e̶n̶s̶e Rec H.264, Annex E).

[aufkrawall]

I can't say how well smooth motion works - I've never used it.

Could you please take a look at it?
I think the huge advantage of that kind of frame blending is that you can set it to on and you never need to worry about system clocks etc.
That's the way it works when you set it in madVR to be always enabled. I personally don't care about the motion blur, videos almost always have tons of it anyway.
With madVR smooth motion, the 60fps video is definitely much smoother at 75Hz. With MPDN fluid motion, it rather seems like it's not active (just the upper main checkbox is ticked, so there should be no reason that it's disabled).
It would be great if there was an option to really make it always enabled.

And :thanks: for fixing the color shift bug.

[madshi]

128.0 is a middle point between 16 and 240, and is a neutral chroma in TV range (which is what BT.601/709/2010 are all about).
Good catch, I missed that.

[harshal_rio91]

I cannot use the latest versions, after the version 2.20 I get black screen when using NVIDIA GPU. I have Optimus system with Intel HD 4600 + GTX 860M. It worked before but now it does not work after v2.20. Please help.

[Zachs]

madVR's accuracy / technical correctness was questioned. I should be allowed to say that it's accurate.

Try BT.709, search for 128. Or try BT.2020, search for 512. It's not that hard to find.

Yes but your original post before you edited it was simply trolling, and I should be allowed to tell people off when they're trolling (it's also against forum rules).

I would have thought that studying the basic standards is the first thing a video renderer developer would do... :p

(Of course what madVR does is correct. But did I really have to say that? :))

Jumping to conclusion much?

The reason I thought it was meant to be 127.5 was also because of this in the standards:
Quantization level assignment of video data for 8-bit coding:
1 through 254
Mathematically, the midpoint is 127.5, which coincidentally matches the conversion matrix posted by Shiandow.
However, I do see now that the standards defined the midpoint specifically as 128.

128.0 is a middle point between 16 and 240, and is a neutral chroma in TV range (which is what BT.601/709/2010 are all about).
127.5 is a middle point between 0 and 255, and should be a neutral chroma in PC range: (128 - 16) * 255 / 224 = 127.5 (conversion defined by c̶o̶m̶m̶o̶n̶ ̶s̶e̶n̶s̶e Rec H.264, Annex E).

Good catch, I missed that.

Is that what madVR does or did you assume all midpoints are 128, madshi?