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

[Zachs]

Add a few more buttons on the player, give it the ability to change colour, add a ton of keyboard shortcuts for most things MPC-HC does..

Yeah if it continues this path it's going to be hard to pass up. The 64 bit option is great, this player looks to be quite lean on resources when playing too.. wouldn't mind seeing a more detailed comparison vs other players in that area. I just wonder when it's going to stop.. Zach any plans continuing with this as an options vs MPC and MadVR? Or are you just adding a few things here and there for the near future just to give to the community a bit? as you've already created what was required for your own work.

Not sure what you mean by continuing with this as an option vs MPC+madVR. But I'm just trying to get the extensions bit done so the community could chip in to help extend the capabilities of the MPDN, because I can't keep working on this at this pace forever. At some time I'll have to work on other things and at that stage, I'll be adding features mainly can't be added via plugins (If I have infinite time to work on this, I'd like to make the whole app fully extensible, from GUI to renderer).

Oh by the way, could you summarise the keyboard shortcuts you want to see implemented? One of the things I wanted to do was to have a "Player plugin" where you could write your own playlist manager etc. and be able to call into the player's functions like Play, Seek, Pause etc. That way, you could also then write your own plugin to add / change keyboard shortcuts. Think Winamp plugins (General plugins I believe?)

I have a lot of ideas, just not going through them nearly fast enough unfortunately.

[Anime Viewer]

I'm going to be naughty and give all of you a little sneak peak of what's to come :)

Custom scalers (Yes, you can add your own scaler)

And the following needs no introduction... (don't go and grab them just yet - they won't work with the current version of MPDN)

It'll be ready when it's ready. :p

Looks interesting. With the openness of custom there will be a lot of options, but when that is ready and running would it be possible to get a break down of what some of the scalers may be similar to? (Like how MPDN's Bicubic with sharpness set to 66 is similar to Mitchell, how Bicubic@100 in MPDN is similar to Catrom, etc)? It might also be useful for people to know what types of new custom scalers might be good for different types of content. (Similar to how to how the article posted by Shiandow revealed that Mitchell was a recommended option for line drawn content (animated content) and Jinc is recommended for live (human/animal) object reproduction. That may give people an idea of what types of custom to try to use in MPDN with all the new options that will be opened up.

Better than NNEDI might be difficult, I'm definitely going to try though! So far I've managed to make it sharper but with slightly more aliasing. Hopefully combining it with NEDI will improve this. And maybe someone will port NNEDI3 to MPDN at some point (which could also be combined with SuperRes...).

At any rate using SuperRes for chroma up-scaling beats any other algorithm I've seen purely because it can do part of the processing in linear light. Example: SuperChromaRes (http://i.imgur.com/HbvS1fw.png) vs Bicubic (http://i.imgur.com/mEaO6jh.png). If you are lucky you might achieve similar results with NNEDI3 but I doubt it, the SuperRes algorithm is just better suited for this kind of processing.

Even if NNEDI3 was an option I don't know that I'd ever use it. I'm not a fan of the large resource taxing it does and how even when it appears to be doing very little work (anti-aliasing) it causes system fans to kick up to high (at least when it comes to using it in madVR). I'm much more apt to stick with SuperRes+NEDI if it gives similar quality with less noise and resource hogging.

One of the things I wanted to do was to have a "Player plugin" where you could write your own playlist manager etc. and be able to call into the player's functions like Play, Seek, Pause etc. That way, you could also then write your own plugin to add / change keyboard shortcuts. Think Winamp plugins (General plugins I believe?)

I have a lot of ideas, just not going through them nearly fast enough unfortunately.

I know in the past you mentioned that you were looking into tying in a play next in folder feature into the playlist feature(s) you were working on/thinking about. That is the only thing that currently comes to mind that MPDN doesn't yet do that many other players offer (and that I use). Aside from that MPDN seems like a player with a good combination of video playback quality and relatively little crash inducing bugs (many of which - like the DX10 issue(s) - seem to be Nvidia/AMD/Intel driver related issues).

[Zachs]

Looks interesting. With the openness of custom there will be a lot of options, but when that is ready and running would it be possible to get a break down of what some of the scalers may be similar to?


That article you read covers a lot of the linear scalers out there, and it was based on that article that MPDN's original scalers were implemented. In fact, the additional ones via custom linear scaler plugins are from there too (Sinc-window). Lanczos is actually Sinc-Lanczos window, and the various additional options you see in that drop down list are mainly varying the window functions of Sinc (you'll find this explained in that same article). As far as I can gather from that article, different people swear by different window functions for a Sinc based scaler.

[kostik]

Is it possible to create a pixel shader for callibration? something like YCMS? so you can input gamut measurements and grayscale measurements?
BTW thanks, great work.

[Zachs]

Is it possible to create a pixel shader for callibration? something like YCMS? so you can input gamut measurements and grayscale measurements?
BTW thanks, great work.

This is definitely possible via render script.
3dlut is also a possibility.
We are tied up with other things at the moment so if anyone wants to give it a go, we would surely appreciate it.
It is not too hard since there are plenty of related materials available on the net.

[feelingblue]

it would be possible to implement the ICC support?

Similar to "ICC color management in Media Player Classic Home Cinema"?

[Zachs]

Render script can do that too if someone writes one.
I'm tied up with other parts of MPDN at the moment though.

[kostik]

This is definitely possible via render script.
3dlut is also a possibility.
We are tied up with other things at the moment so if anyone wants to give it a go, we would surely appreciate it.
It is not too hard since there are plenty of related materials available on the net.

Here is a script from AVS Yesgrey posted it a long time ago for matrix correction.

http://www.avsforum.com/forum/26-home-theater-computers/912720-color-correction-htpc-simpler-solution-now-really-works.html

[Zachs]

Here is a script from AVS Yesgrey posted it a long time ago for matrix correction.

http://www.avsforum.com/forum/26-home-theater-computers/912720-color-correction-htpc-simpler-solution-now-really-works.html

Thanks for that info. It'll come in handy when I get some time to implement it.

[Zachs]

Heads up!

v2.12.0 has just been released with the promised features.
On top of that, the updated RenderScript API also fully supports Direct3D 11 (for cards that support the API obviously), which means SM5.0 and DirectCompute can now be used in the rendering pipeline. There's no scripts that take advantage of these new features yet, so if anyone feels like contributing, we would surely appreciate it!

[ryrynz]

Better than NNEDI might be difficult, combining it with NEDI will improve this.


Likely your code will be the future of high quality upscaling on PC.


At any rate using SuperRes for chroma up-scaling beats any other algorithm I've seen


Resources wise how demanding is it vs Jinc? That SuperRes image is very nice BTW.


But I'm just trying to get the extensions bit done so the community could chip in to help extend the capabilities of the MPDN, because I can't keep working on this at this pace forever. At some time I'll have to work on other things and at that stage, I'll be adding features mainly can't be added via plugins (If I have infinite time to work on this, I'd like to make the whole app fully extensible, from GUI to renderer).


Answers my question nicely, thanks.


Oh by the way, could you summarise the keyboard shortcuts you want to see implemented?


Right now I'd be interested in shortcuts for play, pause, stop, forward and rewind (small, medium, large) displaying the filename, remaining time, properties, next file, previous file, switching between subtitle options.

[Anima123]

Wow, you guys are awesome. I am quite happy with the effect of script chain SuperChromaRes -> SuperRes, though it is also quite expensive, resourcefully speaking, since my nVidia Geforce GT 640M can barely handle 1024x576 -> 1920x1080 @ 24p fluently.

Dreaming of that you guys can make it a little bit more efficient without suffer too much of the quality.

BTW, I remember Shiandow has mentioned somewhere that the SuperRes can resize to any resolution, so I guess there's really no other resizer needed at the last step at all.

[kerimcem]

best result pixel table? image quality..
luma up: ?
chorma up:?
sorry ,may bad english..

[Garteal]

Been keeping a close eye on this project and its really shaping up nicely.

At the moment I have the following in my Script Chain:
-> SuperChromeRes
-> SuperNEDIRes

madVR runs with NNEDI3 with 64 neurons on the Luma and Chroma is being upscaled with Lanczos 3t+AR. Image upscaling is done with Lanczos3t+AR+LL.

So far the difference is mostly negligible to me.
madVR: http://abload.de/img/l_madvrdic5p.png
MPDN: http://abload.de/img/l_mpdn2sehi.png

The rendertimes for the MPDN chain is about 10ms higher than madVR (22ms, 12ms on avg for both).
(I'm using the x64 build of MPDN)

I'm going to test some HD content now and see how they perform.

As for a feature request; since it's kind of hard to precisely grab the same frame for comparison sake mostly, would it be possible to implement a "Go to" dialog similar to how MPC-HC handles it? Not a huge priority though.

[Anime Viewer]

Heads up!

v2.12.0 has just been released with the promised features.


After extracting 2.12.0 as well as the new RenderScripts and CustomLinerScalers when I click on some of those new scalers (to configure them in the script chain) they produce error messages:

When I click on SuperChromaRes and/or SuperRes it produces the error:

TITLE: Framework Error
------------------------------

An unexpected error 'System.NotImplementedException' has occurred.

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

Config dialog has not been implemented (Framework)

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

&Ignore
&Abort
------------------------------


The error only pops up when clicking on them in the script chain configuration screen. Clicking on them in non-chain mode produces no error message, but also doesn't produce a configuration box either.

NEDI shows its configure screen properly, so it appears it may only be certain scripts.

[Garteal]

After extracting 2.12.0 as well as the new RenderScripts and CustomLinerScalers when I click on some of those new scalers (to configure them in the script chain) they produce error messages:
It's just as the error says; these don't have any config dialogs yet so the "error" is normal until they create one.

Oh yeah, another request: chapter markers on the timeline as well as the ability to jump to them with a shortcut.

[Shiandow]

At the moment I have the following in my Script Chain:
-> SuperChromeRes
-> SuperNEDIRes

madVR runs with NNEDI3 with 64 neurons on the Luma and Chroma is being upscaled with Lanczos 3t+AR. Image upscaling is done with Lanczos3t+AR+LL.

So far the difference is mostly negligible to me.
madVR: http://abload.de/img/l_madvrdic5p.png
MPDN: http://abload.de/img/l_mpdn2sehi.png

The rendertimes for the MPDN chain is about 10ms higher than madVR (22ms, 12ms on avg for both).
(I'm using the x64 build of MPDN)

I'm going to test some HD content now and see how they perform.


With those settings scaling 480p -> 1080p I'm getting render times of 19ms and 24ms for MPDN and MadVR respectively. But I've noticed that for some reason SuperRes tends to have high rendertimes without much GPU usage, I'll see if I can improve that somehow.

[Thunderbolt8]

Been keeping a close eye on this project and its really shaping up nicely.

At the moment I have the following in my Script Chain:
-> SuperChromeRes
-> SuperNEDIRes

madVR runs with NNEDI3 with 64 neurons on the Luma and Chroma is being upscaled with Lanczos 3t+AR. Image upscaling is done with Lanczos3t+AR+LL.

So far the difference is mostly negligible to me.
madVR: http://abload.de/img/l_madvrdic5p.png
MPDN: http://abload.de/img/l_mpdn2sehi.png

The rendertimes for the MPDN chain is about 10ms higher than madVR (22ms, 12ms on avg for both).
(I'm using the x64 build of MPDN)

I'm going to test some HD content now and see how they perform.

As for a feature request; since it's kind of hard to precisely grab the same frame for comparison sake mostly, would it be possible to implement a "Go to" dialog similar to how MPC-HC handles it? Not a huge priority though.the subs looks better with madvr, they are blurred with MPDN

[toniash]

the subs looks better with madvr, they are blurred with MPDN

Do you use XYSubFilter?

[Thunderbolt8]

yes, but thats irrelevant as I was comparing the two screenshots linked there.

[madshi]

the subs looks better with madvr, they are blurred with MPDN
This is probably due to a different subtitle renderer, and so outside of the intended comparison purpose. However, I find the lines in the image to be clearer and cleaner in the NNEDI3 screenshot. Look at the lower left side of the face/image. A bit less aliasing and less mosquito noise in the NNEDI3 screenshot, I believe. Not a dramatic difference, though.

[Garteal]

I'm using xySubFilter with both players but it appears that it renders a bit differently in MPDN (possibly not at the desktop resolution as I have it set to in MPC-HC).

With those settings scaling 480p -> 1080p I'm getting render times of 19ms and 24ms for MPDN and MadVR respectively. But I've noticed that for some reason SuperRes tends to have high rendertimes without much GPU usage, I'll see if I can improve that somehow.
Interestingly enough, I get the exact opposite for HD content where MPDNs chain is 10ms lower than madVR. (12ms to 22ms)

Here are some 10bit HD shots (720p -> 1080p). Again nothing too noticeable. Yes I'm aware madVR has a red tint going over it. Not sure what causes it though.
madVR: http://abload.de/img/akgesdesu_madvrh4f8t.png
MPDN: http://abload.de/img/akgesdesu_mpdngyekr.png

As for the GPU usage; from my testing I get the following for Death Note (480p):
- approximately 25% usage with madVR
- approximately 35% usage with MPDN

As for Akame ga Kill (720p):
- approximately 55% usage with madVR
- approximately 30% usage with MPDN

Forgot to mention my specs, but here they are:
CPU: Intel i5-2500K @ 4.5GHz
GPU: AMD Sapphire R9-280X Dual-X

[Scyna]

Hi I'm currently using Jinc 16 on everything to watch anime. Are the new custom scalers better suited for anime? If someone can point me to an article about them would be great thanks.

[Shiandow]

As for the GPU usage; from my testing I get the following for Death Note (480p):
- approximately 25% usage with madVR
- approximately 35% usage with MPDN

As for Akame ga Kill (720p):
- approximately 55% usage with madVR
- approximately 30% usage with MPDN


Your GPU usage with MPDN is higher than I expected. I get more or less the same values when I use SuperChromaRes + SuperNEDIRes, but there's simply no way I'm ever going to get smooth playback with NNEDI3 64 neurons.

By the way, did you still have SuperChromaRes enabled? Because that uses a lot of GPU power as well and it's a bit unfair to compare the performance of NNEDI3 (which only does luma upscaling) to that of SuperChromaRes + SuperNEDIRes.

[Garteal]

By the way, did you still have SuperChromaRes enabled? Because that uses a lot of GPU power as well and it's a bit unfair to compare the performance of NNEDI3 (which only does luma upscaling) to that of SuperChromaRes + SuperNEDIRes.
Yeah I did and you're right. I forgot about it. Though to be honest, it's kind of hard to measure the usage with MPDN and the scripts since the usage is very jumpy which fluctuates the GPU clocks (MPC-HC+madVR has a steady usage and has the GPU on its max clocks).
http://abload.de/img/gpu-usagemii84.png

Though if I had to give an approximation, I'd say it dropped to around the madVR range (25% or so).

[Anima123]

Yeah I did and you're right. I forgot about it. Though to be honest, it's kind of hard to measure the usage with MPDN and the scripts since the usage is very jumpy which fluctuates the GPU clocks (MPC-HC+madVR has a steady usage and has the GPU on its max clocks).


Well, that may explained some of what I encountered: playback is jiggly despite the statistics tell me otherwise, no dropped frames nor delayed frames.

Edit: If it's really a power state issue then it may be helpful by Setting Power management mode from "Adaptive" to "Maximum Performance". I will try it after I got home.

[Zachs]

Well, that may explained some of what I encountered: playback is jiggly despite the statistics tell me otherwise, no dropped frames nor delayed frames.

Edit: If it's really a power state issue then it may be helpful by Setting Power management mode from "Adaptive" to "Maximum Performance". I will try it after I got home.

Power state switching shouldn't make a difference to smoothness of render queue isn't exhausted. It takes nothing at all to present from queue to screen. Maybe it's Optimus thinking it should switch to intel gpu when usage drops? Is there a way to force it to use nvidia gpu only? Anyone else on a more traditional setup seen this issue?

[cyberbeing]

This is probably due to a different subtitle renderer, and so outside of the intended comparison purpose.

madVR output is correct, so you don't need to worry about that. I can reproduce this blurryness issue when using XySubFilter with MPDN. Though you have to keep in mind that the XySubFilter consumer implementation in MPDN is not fully completed.

I'd suspect it has something to do with how MPDN still requests subtitle bitmaps desktop resolution and then rescales to output resolution. Since the positioning seems slightly off with MPDN, I would speculate that either there is a texture resolution/positioning mismatch between the subtitle bitmaps the the video which results in a bilinear shift, or worse that MPDN may be downscaling the high resolution subtitle bitmaps to video resolution before upscaling the video. Either way, this would seem to be a MPDN bug.

http://screenshotcomparison.com/comparison/102493

[Zachs]

madVR output is correct, so you don't need to worry about that. I can reproduce this blurryness issue when using XySubFilter with MPDN. Though you have to keep in mind that the XySubFilter consumer implementation in MPDN is not fully completed.

I'd suspect it has something to do with how MPDN still requests subtitle bitmaps desktop resolution and then rescales to output resolution. Since the positioning seems slightly off with MPDN, I would speculate that either there is a texture resolution/positioning mismatch between the subtitle bitmaps the the video which results in a bilinear shift, or worse that MPDN may be downscaling the high resolution subtitle bitmaps to video resolution before upscaling the video. Either way, this would seem to be a MPDN bug.

http://screenshotcomparison.com/comparison/102493

I'm aware of that as I've described in my earlier post. It scales down from desktop resolution to target size. Like i said this will change when i get some time to work on it further. It also currently only use bilinear to downscale. So you should expect only maximal quality when target size == desktop resolution.

Edit: what is the resolution of your desktop when you to the screenshot?

[Anima123]

Power state switching shouldn't make a difference to smoothness of render queue isn't exhausted. It takes nothing at all to present from queue to screen. Maybe it's Optimus thinking it should switch to intel gpu when usage drops? Is there a way to force it to use nvidia gpu only? Anyone else on a more traditional setup seen this issue?

I was running MPDN with right click and chose the nVidia under 'Run with Graphics Processor' options. Does that mean the program still can get back to the integrated video card automatically?

If not, then there's something to do with the nVidia settings itself maybe. For my assumption, the nVidia 640M with my laptop should be powerful enough of handling SuperChromaRes + SuperRes for 1024x768 -> 1920x1080 upscaling fluently.

[Zachs]

Is there anyway at all to disable igp in the BIOS? That way you can find out if optimus is the culprit.

[Anima123]

I will try later.

FYI, here's the link of how to force nVidia in your own programs: http://stackoverflow.com/questions/15372931/force-system-with-nvidia-optimus-to-use-the-real-gpu-for-my-application

Hope it of any help.

[Zachs]

Thanks for the link.

I don't know how this could be done with a .NET executable though - but I've asked the question on stackoverflow.
If someone knows the answer, please let me know and I'll add that into MPDN. I don't mind if it could be done as a postbuild step either.

EDIT: It seems that if you add MPDN in to your optimus profile, it'll use your NVIDIA GPU. Have you tried that yet?

EDIT2: Oh this is bad news for Optimus setup. It seems that the flaw is in its design itself. You see, NVIDIA GPU isn't connected directly to the display port. It writes its output to the Intel GPU and have it present instead. This is quite bad for smoothness of video (and I have experimented a lot with Intel GPUs) because Intel GPUs clock waaaaay down (i.e. too low for even copying frame buffers) when it's not loaded. Clocking it up causes quite a bit of delay (the Intel driver seems to be quite reluctant to ramp up its clock - it usually takes about 50ms of high workload before it will do that). This is detectable if MPDN writes straight to the Intel GPU but Optimus abstracts it away by telling MPDN everything is fine when it's not (i.e. waiting for Intel GPU to clock up). The problem in this case is, the clock rates on Intel GPU will fluctuate a lot because it's too lightly loaded when NVIDIA GPU is doing most of the work. To verify my theory, see if you can get GPU-Z to show the clock rates on both your NVIDIA GPU and the Intel one (Not sure if it'll show 2 distinct GPUs). If the Intel one shows its clock fluctuating or remains low, then that's where the problem is. Optimus driver should really force Intel GPU to run at max clock when user forces an app to use NVIDIA GPU, but I don't think they have implemented that (not even sure if Intel GPU drivers allow that).

EDIT3: This is why MPDN usually shows delayed frame when used on Intel GPUs for the first couple of frames.

[Anime Viewer]

it's a bit unfair to compare the performance of NNEDI3 (which only does luma upscaling) to that of SuperChromaRes + SuperNEDIRes.

I'd been experimenting around with the SuperChromaRes -> NEDI ->SuperRes chain, but I'm guessing you might advocate SuperChromaRes -> SuperNEDIRes since that's less scripts to do the same thing. (Would that make a difference and be less taxing on a system, or would the results generally be the same.

I don't know if I'm noticing any difference between having SuerChromaRes as part of the chain or not part of the chain. If its working correctly what should I be looking for? A change in the lighting/brightness, shading of colors, ringing?

[Zachs]

@Anime Viewer

BTW, are you sure your 640M can handle SuperChromaRes -> NEDI -> SuperRes?
My 560GTX took 24.5ms for 720x576 -> 1080p. That's not even fast enough for 50fps materials. I expect 1024x768 to be even more demanding.

[Anima123]

Why does it only affect SuperChromaRes + SuperRes, instead of the NEDI + resizer I used before?

[Zachs]

Perhaps the NVIDIA GPU is now taxed a lot more and running out of time to do that extra work to copy the frame buffer to the system memory to be accessed by Intel GPU, and then having to wait for that extra delay to have it presented etc. Unless NVIDIA engineers explain how they are doing that frame buffer copying part (e.g. whether it's fully parallel which I highly doubt), it'll just be speculation. The part of which it sends to the IGP frame buffer for presentation definitely isn't being measured by MPDN, so you may find that it's running out of resources without MPDN reporting so.

[cyberbeing]

It also currently only use bilinear to downscale. So you should expect only maximal quality when target size == desktop resolution.

Edit: what is the resolution of your desktop when you to the screenshot?
Yes, my Desktop resolution for that comparison was 1920x1080, and the bitmaps XySubFilter was sending were also 1920x1080 (target size == desktop resolution). There should be no reason for blurriness or additional scaling in this instance, even with MPDN always requesting desktop size subtitle bitmaps. Since subtitle positioning was also slightly skewed, it would seem that MPDN must have applied an undesired bilinear shift to the subtitle bitmap for some reason.

[Zachs]

Yes, my Desktop resolution for that comparison was 1920x1080, and the bitmaps XySubFilter was sending were also 1920x1080 (target size == desktop resolution). There should be no reason for blurriness or additional scaling in this instance, even with MPDN always requesting desktop size subtitle bitmaps.

Yeah exactly. In that case I'll need to find out what is going on.
MPDN draws the bitmaps to the screen in the most straight forward manner i.e using hardware filtering, after all processing e.g. RenderScript is done. Can you post a sample of the media file so I could find out what's wrong?

[cyberbeing]

I think this issue may occur with all subtitles, but I'll send you the sample and also a XySubFilter build for dumping bitmaps+alpha in case you'd find it useful for debugging.

[Anime Viewer]

@Anime Viewer

BTW, are you sure your 640M can handle SuperChromaRes -> NEDI -> SuperRes?
My 560GTX took 24.5ms for 720x576 -> 1080p. That's not even fast enough for 50fps materials. I expect 1024x768 to be even more demanding.

I have a 680M (GTX) as noted in my signature. Anima123 is the one with the 640M. I haven't noticed any problems playing videos with the SuerChromaRes->NEDI->SuperRes. I did notice (on one file I was testing) the render times were fluctuating from between ~18ms-~28ms, but surprisingly there didn't seem to be any playback problems during those 28ms times. SuperNEDIRes by itself (with all scalers set to Jic 6 taps) fluctuates between 16-24ms on a file I was testing recently.

(Edit: Watching the Railgun S intro to compare subtitles rendered by XySubFilter to cyberbeing's screen captures noticed Render under Max durations read 93+ms :confused: Clearly its not rendering at that speed (:sly: as far as my eyes tell me), so something is making the readings short circuit (the electricity of that intro?) :rolleyes: - not that I care since everything is running smoothly).

There should be no reason for blurriness or additional scaling in this instance, even with MPDN always requesting desktop size subtitle bitmaps.
(People encountering the blurring cyverbeing, Thunderbolt8, and Garteal?) Do you have ffdshow or SVP active when running MPDN? I remember seeing blurry subtitles back when I was testing those out, and I recall it disappearing when I had changed some settings in one or both of those. I eventually determined that I didn't see significant benefit to running with SVP, and it was always kicking the fan up more then I liked. As a result disabled both when it comes to playing videos in MPDN. If you have both or either of those programs running try with them disabled/shut off, and see if your subtitles clear up.
(BTW: All of the video I've tested with XYsubFilter has been clear. (Mostly 720 and 480 videos). What is the resolution of the videos people are seeing blurry subtitles with? I saw the Scientific Railgun screen shot(s), and if I'm reading that screen correctly it was 720p upscaled to 1080p, correct?)

[Anima123]

Yes, I had the one with a 640M card in my laptop.

Just tested with SuperNEDIRes only, it'll do. I have to sacrifice something, in this case SuperChromaRes, to get visually pleasure.

NNEDI3 is totally unwatchable with that configuration due to the high resource demand.

[Anime Viewer]

madVR output is correct, so you don't need to worry about that. I can reproduce this blurryness issue when using XySubFilter with MPDN. Though you have to keep in mind that the XySubFilter consumer implementation in MPDN is not fully completed.

I'd suspect it has something to do with how MPDN still requests subtitle bitmaps desktop resolution and then rescales to output resolution. Since the positioning seems slightly off with MPDN, I would speculate that either there is a texture resolution/positioning mismatch between the subtitle bitmaps the the video which results in a bilinear shift, or worse that MPDN may be downscaling the high resolution subtitle bitmaps to video resolution before upscaling the video. Either way, this would seem to be a MPDN bug.

http://screenshotcomparison.com/comparison/102493

Attached below is screen shots I took of UTW_Mazui Railgun S ep 03 720p upscaled to 1080p opening on my system with madVR (top image) and MPDN (bottom image).

Both are using XySubFilter. MPDN settings are Jinc 6-tap for all scalers (no anti-ringing checked), random dithering (default 2.0 setting), and SuperNEDIRes the only running script. madVR settings are chroma upscaling - mitchell (with anti-ringing), image upscaing - mitchell (ant-ringing and scale in linear light checked), and downscaling -mitchell (anti-rining and liner light checked), SM off, ordered dithering (colored noise and change dither every frame checked), no trade quality checked.

I can just make out a bit of alaising with madVR (could be the mitchell setting) while the MPDN looks smoother (I wouldn't call it blurred IMO). (Check out the bottom right leg of the k(s) and the w(s), or any of the letters with straight lines). (Edit: Tried with all madVR scaling set to Jinc (except for downscaler of course), unchecking anti-ringing and linear lights, but it still maintained the same amount of alaising to the subtitles at the top shown in the attachment).

Railgun S opening test (http://postimg.org/image/spd5yk5xn/full/)

(BTW: I think both players subtitles look good, and probably wouldn't notice the difference under normal conditions where video is playing, and eyes are more drawn to the action of the scenes then the quick karaoke animating and disappearing from the screen.)

[Zachs]

That is what the others are calling blurriness with MPDN's XySubFilter.
Technically if the target size == desktop resolution, MPDN should not scale the subs at all, so it should appear all aliased if that's what XySubFilter has provided MPDN with.

EDIT: LOL. It might be a bug but I actually prefer MPDN's anti-aliased subs personally :)

EDIT2: Found the problem and fixed in next build.

[cyberbeing]

Do you have ffdshow or SVP active when running MPDN?
No.

LOL. It might be a bug but I actually prefer MPDN's anti-aliased subs personally :)

Well you could certainly add an optional subtitle softening setting if you wanted to. In the past we were considering adding dynamic blur based on the scale factor so typesetting would blend better onto upscaled video with high resolution subtitles, but we never got around to it. This is mostly an issue with older scripts though. Nowadays, typesetters are more in the practice of of adding \blur to their subtitles which allows them to blend properly even when upscaled. XySubFilter does have a non-default "8x8 (bilinear)" subpixel positioning setting which will yield a softer appearance, but since not all edges require subpixel positioning the results can be rather inconsistent on dialog lines.


Found the problem and fixed in next build.

Out of curiosity, what did the problem end up being? [Edit: nevermind, I see you mentioned it in your PM]

[Anime Viewer]

EDIT: LOL. It might be a bug but I actually prefer MPDN's anti-aliased subs personally :)


Me too, I like the smoother look that I see during the MPDN paused screen shot(s) I attached compared to the more jagged madVR look (http://postimg.org/image/spd5yk5xn/full/). Not that it matters now that its been patched. :rolleyes:

I will concur that cyberbeing's example with the subtitles of "sister's noise" lines look blurry in his/her example (http://screenshotcomparison.com/comparison/102493), but to me it doesn't look like mine were anywhere never that level of un-sharpness, so something else may have been a factor too. It also would probably be more noticeable the larger the screen the video is being watched on (ex: tv vs notebook screen).

[Zachs]

Me too, I like the smoother look that I see during the MPDN paused screen shot(s) I attached compared to the more jagged madVR look (http://postimg.org/image/spd5yk5xn/full/). Not that it matters now that its been patched. :rolleyes:

I will concur that cyberbeing's example with the subtitles of "sister's noise" lines look blurry in his/her example (http://screenshotcomparison.com/comparison/102493), but to me it doesn't look like mine were anywhere never that level of un-sharpness, so something else may have been a factor too. It also would probably be more noticeable the larger the screen the video is being watched on (ex: tv vs notebook screen).

Don't worry, I kept that smoother version as an option since I prefer that too. I simply hate jagged lines and rather prefer it a bit softer to reduce distraction it creates when other parts of the video isn't as 'sharp'.

Edit: I think I know why you prefer cyberbeing's screenshot being less blurry -- perhaps it's because it hasn't got a background.

[Anima123]

I had two findings for the new version related to SuperRes stuff.

1. Adding SuperChromaRes into the top of the script chain and then remove it, then the video became unwatchable due to lack of a plane of color like, all I saw is shadows of people;

2. When using SuperNEDIRes to playback a video, after scroll the video a few times, it can be very juggy to watch due to lots of dropped and delayed frames, while re-playback this video will get it back to normal.

[Garteal]

Awesome. Great to see such fast debugging happening. I too like the "anti-aliased" subs and it is nice to have an option for it. Thanks Zachs.


1. Adding SuperChromaRes into the top of the script chain and then remove it, then the video became unwatchable due to lack of a plane of color like, all I saw is shadows of people;

It appears that the script chain does not "update" its settings if you make changes afterwards. Changing to another render script entirely and back to the script chain should fix it though for now.


2. When using SuperNEDIRes to playback a video, after scroll the video a few times, it can be very juggy to watch due to lots of dropped and delayed frames, while re-playback this video will get it back to normal.
I cannot reproduce this.

[Shiandow]

EDIT: LOL. It might be a bug but I actually prefer MPDN's anti-aliased subs personally :)

EDIT2: Found the problem and fixed in next build.

FWIW XySubFilter has a setting "SubPixel-Position" under Settings->More; changing this to "8x8 (bilinear)" results in smoother subtitles like the one MPDN (accidentally) showed.

I'd been experimenting around with the SuperChromaRes -> NEDI ->SuperRes chain, but I'm guessing you might advocate SuperChromaRes -> SuperNEDIRes since that's less scripts to do the same thing. (Would that make a difference and be less taxing on a system, or would the results generally be the same.

I don't know if I'm noticing any difference between having SuerChromaRes as part of the chain or not part of the chain. If its working correctly what should I be looking for? A change in the lighting/brightness, shading of colors, ringing?

Yeah it's probably better to use SuperNEDIRes instead of NEDI ->SuperRes, in fact in that last configuration SuperRes won't do anything unless the image needs to be scaled by a factor > 2.

Using SuperChromaRes should result in slightly more vibrant colours, it should also prevent chroma bleed which is usually visible as a dark outline, especially with a red object on a white background.