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

[Zachs]

Can someone let me know how to use XySubFilter (auto-load version) in GraphStudioNext?
It doesn't load subtitles at all and it doesn't even have an output pin?? How is it meant to be used?

EDIT: Ah nevermind. Found it: http://madshi.net/SubRenderIntf.h

[kerimcem]

volume bar and fly bar added?

[Zachs]

Originally Posted by kerimcem

volume bar and fly bar added?

Sorry what's a fly bar?
I'm keeping the UI minimalist so there won't be a volume bar.

[kerimcem]

Originally Posted by Zachs

Sorry what's a fly bar?
I'm keeping the UI minimalist so there won't be a volume bar.

http://jpegshare.net/thumbs/bb/f8/bb...7e1427636a.jpg
ok

[Zachs]

Originally Posted by kerimcem

http://jpegshare.net/thumbs/bb/f8/bb...7e1427636a.jpg
ok

Ah! Flybar actually suits the minimal UI concept very well. Come to think of it I could implement volume bar via drop down from one of the flybar buttons.

It'll be on my todo list.

[kerimcem]

Originally Posted by Zachs

Ah! Flybar actually suits the minimal UI concept very well. Come to think of it I could implement volume bar via drop down from one of the flybar buttons.

It'll be on my todo list.

[littleD]

I have 5470Mobility and suprisingly all render paths works. The only exception is that in dx9ex my card reject to render in 16bit and automatically fallback to 10 bit. 16 bit gives dark image in dx10 path though. I cant tell much about image quality, tested on built-in laptop display, but wanna report it works. Performance of renderer is also good considering 10 bit. Comparing to EVR in mpc-hc, 60 fps sample was good, but 120fps sample was slower in mpdn.

[Zachs]

Originally Posted by littleD

I have 5470Mobility and suprisingly all render paths works. The only exception is that in dx9ex my card reject to render in 16bit and automatically fallback to 10 bit. 16 bit gives dark image in dx10 path though. I cant tell much about image quality, tested on built-in laptop display, but wanna report it works. Performance of renderer is also good considering 10 bit. Comparing to EVR in mpc-hc, 60 fps sample was good, but 120fps sample was slower in mpdn.

Yes AMD has a bug in their 16-bit mode. I'll provide a workaround in my code for AMD cards in a future release.

120fps! I haven't tried that yet TBH. But glad to know it works. EVR will always be faster since it lacks a lot of features MPDN have turned on by default (e.g. dithering).

[Zachs]

@littleD

Version 2.2.0 now has a workaround for AMD cards in 16-bit mode.

I've also added 10- and 16-bit input support (accepts P010 and P016 formats from LAV Video Decoder).

[kerimcem]

dont work vc1 wmv files intel grapichs lga 1150

[Zachs]

Originally Posted by kerimcem

dont work vc1 wmv files intel grapichs lga 1150

That's probably because you haven't setup LAV Audio Decoder to allow WMA audio decode (as mentioned a few pages ago, LAV Audio Decoder does not have WMA decode enabled by default).

[kerimcem]

Originally Posted by Zachs

That's probably because you haven't setup LAV Audio Decoder to allow WMA audio decode (as mentioned a few pages ago, LAV Audio Decoder does not have WMA decode enabled by default).

[Hera]

I got exciting that this is in a .NET language (something I can understand).
But then, read that is closed source? Any reason given?

[Zachs]

Originally Posted by madshi

On a side note, personally I find Lanczos, Spline and Jinc with 2 taps (in your case 4 taps) to be not worth the effort. They don't look better than Bicubic to my eyes. That's why madVR starts at 3 taps with those algorithms (which you count as 6 taps).

Just found some time to test some low res video clips. I find the above to be false - 4-tap (eq madVR 2 taps) Lanczos, Spline and Jinc look quite different to Bicubic as well as to one another. Try blackberry.mp4 (compare the BlackBerry text) on this page - http://download.wavetlan.com/SVV/Med...P/http-mp4.htm.

You'll find that Jinc gives the best interpolation. In fact, I can't see the difference between 4 or 6 or 8 taps but I can immediately notice the difference going from Bicubic to 4-tap Jinc. Looking at the pictures side by side visually, I can't tell the difference (subjectively) between madVR's 3-tap (which is my 6 taps) to my 4 taps either.

Originally Posted by huhn

not working.

it looks like it is not nearest neighbour it is bilinear when i select nearest neighbour it aliased even more the rest doesn't have an effect even softcubic 100.

Can you give v2.4.2 a test to see if downscaler bug is completely fixed?

Originally Posted by Hera

I got exciting that this is in a .NET language (something I can understand).
But then, read that is closed source? Any reason given?

Sorry to disappoint but performance critical parts are actually in ASM and C / C++. C# merely provides the glue logic and it isn't very good at that too with GC stopping all managed threads when it feels like it (which means all MPDN's time critical threads are also in C++).

I can only share it as closed source or don't share it at all (for reasons I can't disclose). If you want to learn about writing a video renderer, there are plenty of resources on the net to get you started.

[huhn]

looks like the general bug is fixed.

but there are other issue.

lanczos creates very strange artefacts when used as downscaler and it is at least half an pixel off to the bottom right compared to spline 4 ar. spline as less deforming aliasing and it sharper at the same time. laczos even creates double lines.

here 2 screens:

spline 4 ar : http://abload.de/img/downsplinewvaq4.png
laczos 4 ar : http://abload.de/img/downlaczosn2l61.png

i added madVR 3 tab ar spline/laczos to show that the difference is very minimal compared to MPDN between them.

i'm currently using windows 10 preview so this can be an windows 10 issue.

on a 120 hz screen playback of 23p is very choppy and juddering a lot more than 23p on a 60 hz screen. madVr works fine with and without smoothmotion.

[Zachs]

Originally Posted by huhn

looks like the general bug is fixed.

but there are other issue.

lanczos creates very strange artefacts when used as downscaler and it is at least half an pixel off to the bottom right compared to spline 4 ar. spline as less deforming aliasing and it sharper at the same time. laczos even creates double lines.

here 2 screens:

spline 4 ar : http://abload.de/img/downsplinewvaq4.png
laczos 4 ar : http://abload.de/img/downlaczosn2l61.png

i added madVR 3 tab ar spline/laczos to show that the difference is very minimal compared to MPDN between them.

i'm currently using windows 10 preview so this can be an windows 10 issue.

on a 120 hz screen playback of 23p is very choppy and juddering a lot more than 23p on a 60 hz screen. madVr works fine with and without smoothmotion.

Found the problem. Affects both Lanczos and Jinc. Fixed in next release. Looks like Jinc is actually quite a good downscaler - it has anti-aliasing features like softcubic but more faithfully retains original color.

You'll also notice that MPDN's downscalers are much faster than madVR, only sacrificing a little bit of image quality. With madVR, I couldn't play 4k downscaled to 1080p on my system with 560GTX but MPDN works without a fuss.

Also found the problem with choppy playback but to confirm, can you switch to D3D10 rendering path to see if it happens there too?

On my system, the choppy playback only happens in D3D9. That was the result of increasing backbuffer count (why this would cause choppy playback, I don't know). A few versions back would have been ok too.

[madshi]

Originally Posted by Zachs

You'll also notice that MPDN's downscalers are much faster than madVR, only sacrificing a little bit of image quality. With madVR, I couldn't play 4k downscaled to 1080p on my system with 560GTX but MPDN works without a fuss.

With or without anti-ringing? Or both? I wonder if your algorithm does the same work that madVR does? Maybe you're not reading in enough source pixels? FWIW, are you calculating the weights in real time? Or are you reading them from a texture? I'm reading them from a texture. I sometimes do wonder whether calculating them in real time would be faster. But it will probably differ, depending on GPU generation (and on the scaling algorithm). Older generations have less shader power than newer generations. So probably reading the weights from a pre-calculated texture is faster on older generation GPUs and using real time calculation could be faster on newer generation GPUs.

[huhn]

Originally Posted by Zachs

Found the problem. Affects both Lanczos and Jinc. Fixed in next release. Looks like Jinc is actually quite a good downscaler - it has anti-aliasing features like softcubic but more faithfully retains original color.

You'll also notice that MPDN's downscalers are much faster than madVR, only sacrificing a little bit of image quality. With madVR, I couldn't play 4k downscaled to 1080p on my system with 560GTX but MPDN works without a fuss.

Also found the problem with choppy playback but to confirm, can you switch to D3D10 rendering path to see if it happens there too?

On my system, the choppy playback only happens in D3D9. That was the result of increasing backbuffer count (why this would cause choppy playback, I don't know). A few versions back would have been ok too.

it's broken with directx 10.1 too but it's fine in full screen mode.

Originally Posted by madshi

With or without anti-ringing? Or both? I wonder if your algorithm does the same work that madVR does? Maybe you're not reading in enough source pixels? FWIW, are you calculating the weights in real time? Or are you reading them from a texture? I'm reading them from a texture. I sometimes do wonder whether calculating them in real time would be faster. But it will probably differ, depending on GPU generation (and on the scaling algorithm). Older generations have less shader power than newer generations. So probably reading the weights from a pre-calculated texture is faster on older generation GPUs and using real time calculation could be faster on newer generation GPUs.

so with a UHD source on a FHD screen madVR does.

chroma upscales FHD to UHD (2 channels to UHD) chroma position correction and RGB conversation and now scaling the hole UHD RGB frame (3 channel) down to FHD.


MPDN has a option for chroma up and down so I guess it's not working like madVR that creates always 48 bit RGB first.

by just scaling the luma channel (1 channel) to 1080p, correct chroma position and by doing a RGB conversation in just 1080p it has to be a lot faster or not?

not sure about the quality through.

[madshi]

Originally Posted by huhn

so with a UHD source on a FHD screen madVR does.

chroma upscales FHD to UHD (2 channels to UHD) chroma position correction and RGB conversation and now scaling the hole UHD RGB frame (3 channel) down to FHD.


MPDN has a option for chroma up and down so I guess it's not working like madVR that creates always 48 bit RGB first.

by just scaling the luma channel (1 channel) to 1080p, correct chroma position and by doing a RGB conversation in just 1080p it has to be a lot faster or not?

not sure about the quality through.

Good thinking. Yes, that would explain at least some of the difference. For linear light downscaling you *have* to upscale chroma first. I guess if you downscale in gamma light it should also be fine to downscale chroma directly to save performance. However, this also means that you can't do certain things in the original video resolution, like rendering 4:4:4 subtitles, doing color corrections, run certain filters etc. And how do you want to run custom pixel shaders in the original video resolution? That's not possible if you don't upscale chroma first. Also, you would need different rendering paths for different sources (4:2:0 vs. RGB etc). Because of all these reasons madVR always converts everything to RGB first, before even starting to scale anything.

[Zachs]

Originally Posted by madshi

Good thinking. Yes, that would explain at least some of the difference. For linear light downscaling you *have* to upscale chroma first. I guess if you downscale in gamma light it should also be fine to downscale chroma directly to save performance. However, this also means that you can't do certain things in the original video resolution, like rendering 4:4:4 subtitles, doing color corrections, run certain filters etc. And how do you want to run custom pixel shaders in the original video resolution? That's not possible if you don't upscale chroma first. Also, you would need different rendering paths for different sources (4:2:0 vs. RGB etc). Because of all these reasons madVR always converts everything to RGB first, before even starting to scale anything.

Anything in YUV wouldn't be much hassle to support but RGB will need to be converted to YUV 4:4:4 first. It's slower where RGB is involved (MPDN doesn't do that yet) but it's only needed for RGB input formats (XySubFilter can render straight to the RGB scaled resolution, even for PGS subs -- everything needs to be scaled properly before it's being displayed anyway).

As such, I'm not too concerned about doing things in the original video res. You could always run custom pixel shaders in the scaled resolution rather than original. It's not something I have planned in the near term anyway.

But knowing that madVR converts chroma to RGB first definitely explains why UHD to FHD would fail to render in realtime on my 560GTX with 45ms render time while MPDN does it in 14ms when set to the same settings* (before the next release where I have further optimizations for MPDN's downscalers which will improve their speed and image quality at the same time).

* No dithering, softcubic, no AR, no linear light scaling, same video @23p. madVR specific: no smooth motion, no debanding.

EDIT: So does this mean that madVR doubles chroma res first and then scale RGB yet again?