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]

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]

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/bbf8bb02c853cd7446ab237e1427636a.jpg
ok :(

[Zachs]

http://jpegshare.net/thumbs/bb/f8/bbf8bb02c853cd7446ab237e1427636a.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]

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.

:thanks:

[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]

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]

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]

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).
:thanks::rolleyes:

[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]

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/Media/HTTP/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.

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?

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]

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]

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? :p 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]

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.

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? :p 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]

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]

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?

[Zachs]

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



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.

I do exactly the same thing in FSE mode vs windowed mode. I am not sure why it would stutter in windowed mode but not FSE. The D3D9 render path I get it (not really, since it doesn't make much sense why increasing back buffer count would cause it to stutter) but definitely not D3D10. Anyway, I've changed the backbuffer count of D3D10 to 2 (as the recommended minimum from MSDN docs). Please let me know if stuttering issue still occurs in either rendering paths in the next release.

Scaling luma and chroma just once should yield better quality if all else is equal, otherwise it would defy logic wouldn't it? :)

For example, you wouldn't have to upscale chroma once to luma size, and then scale it again from there. Human eyes aren't very sensitive to chroma though, so you may not notice the loss of quality the way madVR does it.

Not to mention I just can't get madVR to play 4K movies properly on any of the systems I own!

E.g. Softcubic 50, no dithering, no smooth motion, 560 GTX.
Test clip: Interstellar-TLR-F2-5.1-4K-HDTN.mp4

Render times:
MPDN: 11.7ms
madVR: 44.4ms

madVR also constantly racks up presentation glitches (~5 per second).

EDIT: Just realised my 560GTX was running at lowest power state with MPDN since it didn't need the extra clock speed. MPDN's time was in the 7ms range at max power state. So this explains the difference Shiandow was seeing with his 560ti vs my 560.

[huhn]

still not working fine it works sometime and sometimes not. don't forget i'm on windows 10 who knows what Microsoft has broken in this preview so please don't take it to serious.

about UHd downscaling.

i can easily use madVR to downscale with dithering using spline 3 ar for a 60 fps UHD source to FHD with about 11 ms at max powerstate using a gtx 760.
when i use MPDN I get about 14 ms and the powerstate is min running at ~135 mhz so it is about 6-10 times faster and there must be a reason for that.

are you using a 16 bit frame buffer like madVR? is the chroma position corrected at all?

[Zachs]

No its 32 bit all the way. No 16 bit crap until the final output where it is 8, 10 or 16 bits.

Chroma position correction is free as in it doesn't affect render time.

[madshi]

Scaling luma and chroma just once should yield better quality if all else is equal, otherwise it would defy logic wouldn't it? :)
Actually upscaling the image, then doing some processing (e.g. detail enhancement/sharpening), then downscaling again can be beneficial sometimes. There are several AviSynth sharpening scripts which internal upscale first, then process, then downscale to reduce aliasing. Furthermore, the chroma channel was downscaled by the studio. It might make sense to use a different algorithm to try to restore the original chroma resolution again, and then a different algorithm for image up/down scaling. Finally, for high downscaling factors using linear light downscaling can improve the image quality, which is only possible if you restore the original chroma resolution first. Whether the final result looks better or worse depends on the exact algorithms that were used.

Not to mention I just can't get madVR to play 4K movies properly on any of the systems I own!
Well, you probably could, by using DXVA downscaling, or Bilinear downscaling, but obviously that's not a good idea for image quality. I guess I could add a different rendering path to madVR to skip chroma upsampling under specific circumstances to speedup downscaled 4K playback. It would be quite a lot of extra work, though... :(

[Shiandow]

E.g. Softcubic 50, no dithering, no smooth motion, 560 GTX.
Test clip: Interstellar-TLR-F2-5.1-4K-HDTN.mp4

Render times:
MPDN: 11.7ms
madVR: 44.4ms

madVR also constantly racks up presentation glitches (~5 per second).

That doesn't sound right, if I play back that file on a resolution of 1920x1080 I get render times of ~23 ms using Bicubic 75 AR chroma doubling, Mitchell AR LL downscaling, debanding, ordered dithering and smooth motion on a GTX 560 Ti.

Edit: Turns out that MPDN only needs 5 ms (using default settings) so it seems that the performance difference remains relatively the same. Apparently there's a larger difference between the GTX 560 Ti and the GTX 560 than I thought.

[Zachs]

Actually upscaling the image, then doing some processing (e.g. detail enhancement/sharpening), then downscaling again can be beneficial sometimes. There are several AviSynth sharpening scripts which internal upscale first, then process, then downscale to reduce aliasing. Furthermore, the chroma channel was downscaled by the studio. It might make sense to use a different algorithm to try to restore the original chroma resolution again, and then a different algorithm for image up/down scaling. Finally, for high downscaling factors using linear light downscaling can improve the image quality, which is only possible if you restore the original chroma resolution first. Whether the final result looks better or worse depends on the exact algorithms that were used.


Well, you probably could, by using DXVA downscaling, or Bilinear downscaling, but obviously that's not a good idea for image quality. I guess I could add a different rendering path to madVR to skip chroma upsampling under specific circumstances to speedup downscaled 4K playback. It would be quite a lot of extra work, though... :(

I wouldn't take AviSynth scripts as the de facto standards on how things should be done, they are usually written to utilize what's readily available from AviSynth core functions when there are other ways to achieve the same quality or better (esp in the reducing aliasing department) in a much less expensive way.

Correct me if I'm wrong but are you saying luma is scaled by a third party and chroma is scaled separately by the studio? My thinking was that they were both scaled by the studio?? e.g. Production company shoots footage in IMAX res, studio scales both luma and chroma to 4:2:0 for Bluray/DVD release. Or in the consumer space, video cams record straight to 4:2:0. TBH I can't see how upscaling chroma twice in that regard could be beneficial as opposed to detrimental in any way.

Personally I have not seen the benefits of scaling in linear light so I haven't done much research into that. However, my thinking is linear light scaling could be done on the individual YUV planes too, couldn't it?

[Zachs]

That doesn't sound right, if I play back that file on a resolution of 1920x1080 I get render times of ~23 ms using Bicubic 75 AR chroma doubling, Mitchell AR LL downscaling, debanding, ordered dithering and smooth motion on a GTX 560 Ti.

Edit: Turns out that MPDN only needs 5 ms (using default settings) so it seems that the performance difference remains relatively the same. Apparently there's a larger difference between the GTX 560 Ti and the GTX 560 than I thought.

Your settings are too unfair for madVR. If you really want to compare the relative performance of MPDN vs madVR, you should really set them up so they are on a level playing field - e.g. debanding and smooth motion cost quite a bit of rendering time.

EDIT: Turns out my GTX 560 was running at lowest power state when I took the measurement because it could with MPDN. At max power state, I got 7ms, so it is quite close to your 560ti, which it should be (384 vs 336 cores). As with madVR, it seems that its performance was affected by presentation glitches. I will try swapping drivers and report back. In the meantime, try comparing with madVR settings Softcubic 50 no AR chroma doubling, softcubic 50 no AR no LL downscaling, no debanding, no dithering and no smooth motion. And set MPDN's dithering to none as well.

[huhn]

first of all rendertimes are hard to judge. the GPU powerstate is a huge problem in these cases and can easily make rendertimes miss leadering at least.

it's not rare that I see way higher rendertime with a lot easier content.

this usually happens with 1080p23 and 1080i30 60 fields.
it's not rare that the rendertimes of GPU deinterlaced 1080i 60 fields is way lower than the rendertimes of 1080p23 and the reason is the gpu powerstate.

[Zachs]

first of all rendertimes are hard to judge. the GPU powerstate is a huge problem in these cases and can easily make rendertimes miss leadering at least.

it's not rare that I see way higher rendertime with a lot easier content.

this usually happens with 1080p23 and 1080i30 60 fields.
it's not rare that the rendertimes of GPU deinterlaced 1080i 60 fields is way lower than the rendertimes of 1080p23 and the reason is the gpu powerstate.

Yes that's absolutely correct.

It's especially difficult when one is maxing out the GPU while the other was going over leisurely.

Is there a way of forcing the GPU to run at constant power state for testing purposes?

[Zachs]

OK this is on an old 8400GS card that has constant clock (i.e. there's only two power states: card is on, or it's off, there's nothing in between) to rule out any difference in power states :)

Downscaling from 1920x1080 23p video to a 1280x1024 (1280x720 after scaling with aspect ratio) screen in FSE mode for both, all settings equal (Softcubic 50 no AR no LL for all scaling modes with madVR smoothmotion debanding off, MPDN and madVR dithering set to None). Consider this a poor man's UHD 3K to FHD comparison ;)

MPDN: 32.8ms (max 35.8ms)
madVR: 90ms (max 133ms) ** average rendering time keeps crawling up non-stop even after 5 mins into the video

Using the max stats (madVR's max is more consistent vs its avg time hovering around the 130ms mark), it's again a ~4 times difference.

This time around, madVR does not suffer too many presentation glitches (only the occasional ones when stopping and playing video from the start). MPDN on the other hand has zero presentation glitches.

[huhn]

madVRT creates usually presentation glitches when it is not in focus. and there where always problem when a program like gpu-z was running when madVR was used. and madVr has a lot of presentation mode. for exsample windows 7 overlay does a good job for me.

but the more important part is that when upscaling MPDN is not faster. so it is simply the way madVr handles 4:2:0 downscaling.

it is pretty hard to force a newer GPU in highest powerstate because that is not the highest powerstate anymore. all new card overclock them self.

you can disable this in most cases and forcing the gpu in highest power mode is possible too. should be in the driver settings.

i took a 848x480p23 file for upsacling tests the rendertimes are in the 1-2 ms range with high powerstate and bicubic 75. it's a bad comparison there is simply nothing to do for the gpu.

848x480 at 858x480 has there values:
MPDN chroma bicubic 75 directx 10.1 3.46 ms at 135 mhz ~10 % GPU usage

madVR chroma bicubic 75 windows 7 overlay 3.57 ms at 135 mhz ~11% GPU usage

madVR chroma bicubic 75 window mode (new path) 9.10 ms at 135 mhz ~20% GPU usage

madVR chroma bicubic 75 window mode (old path) 2.67 ms at 135 mhz ~10% GPU usage

what did we learn new path is pretty slow. on this PC.

[Zachs]

@huhn

Can you let me know if the latest version is better in terms of stuttering and if Lanczos and Jinc work without problems this time?

[madshi]

I wouldn't take AviSynth scripts as the de facto standards on how things should be done, they are usually written to utilize what's readily available from AviSynth core functions when there are other ways to achieve the same quality or better (esp in the reducing aliasing department) in a much less expensive way.
I'm not sure if I would upscale (luma) first, then process, then downscale again myself. It could be beneficial, but I suppose the benefits could be too small to make it worth it. But there are some arguments to be made for doing some processing in the original video resolution.

If you look at scientific image scaling papers, often upscaling to a higher resolution, then later downscaling again can provide better PSNR (or similar) results. The differences are usually minor, though.

Correct me if I'm wrong but are you saying luma is scaled by a third party and chroma is scaled separately by the studio? My thinking was that they were both scaled by the studio?? e.g. Production company shoots footage in IMAX res, studio scales both luma and chroma to 4:2:0 for Bluray/DVD release. Or in the consumer space, video cams record straight to 4:2:0. TBH I can't see how upscaling chroma twice in that regard could be beneficial as opposed to detrimental in any way.
99.99% of all movie content is available in at least 4:2:2, maybe 4:4:4 to the studios. The studio provides a master to the encoding facility. This master could be the original data the studio has, or already some conversion (e.g. it could be a 2K version of the studio's 4K master). The encoding facility then does any further conversions. I didn't mean to say that luma is scaled by a differently party then chroma. This *could* be the case, but it doesn't have to be, and it wasn't the point I was trying to make, anyway.

One point I'm trying to make is that we have luma available in a higher resolution than chroma. This means that there's a certain chance to use the luma information to guide in chroma upscaling. This method is currently not used in madVR, but it might be in the future. If we downscale chroma to the target resolution first, we're giving away the chance to use the luma information to guide with chroma restauration. But since I'm not using this method yet, this is probably a moot point right now.

A more important point might be that using a somewhat softer algorithm for chroma upscaling can sometimes bring benefits (some studios use rather bad/aliased chroma subsampling algorithms), while for image up/downscaling usually a rather sharp algorithm is what most users would prefer. If you scale chroma directly to the target resolution, you can only use one algorithm: Either a softer one or a sharper one.

Originally madVR used to do the same you're doing: Namely scaling chroma directly to the target resolution. This proved to be suboptimal in some situations, e.g. because when using a softer algorithm for chroma upsampling, the final image got overly soft when using large scaling factors. Just try this with a test pattern: Use a somewhat soft chroma upscaling algorithm (e.g. SoftCubic), and a sharp image upscaling algorithm (e.g. Lanczos), then upscale a small chroma test image by 400% and you'll see that chroma will be blurred a lot. Using a combination of SoftCubic + Lanczos would achieve better results. Some users argue for using a sharp chroma upscaling algorithm, anyway, so for those it might make no difference, though.

Personally I have not seen the benefits of scaling in linear light so I haven't done much research into that. However, my thinking is linear light scaling could be done on the individual YUV planes too, couldn't it?
No, that would produce incorrect results. The only proper way to convert the video to linear light is to do Y'CbCr -> R'G'B' -> RGB. You can then convert RGB back to YCbCr if you like. But you *have* to go through R'G'B' -> RGB.

[Tacio]

@Zachs

Do you have any plan to implement DXVA scaling? I found out that MadVR's DXVA scaler is quite good for me using Intel HD3000.

[huhn]

@huhn

Can you let me know if the latest version is better in terms of stuttering and if Lanczos and Jinc work without problems this time?

scaling looks fine. i don't see an obvious issue at the moment.

jincs looks pretty good but very unsharp even 8 tabs maybe linear light helps in this case like it helps with catmull-rom.

playback is still not working well this time it didn't work well in fullscreen and windowed.

i guess the issue has something to do with this:
http://abload.de/img/issue4nskk.png

edit: forget that screen happens with very stable numbers too.

[Zachs]

Originally madVR used to do the same you're doing: Namely scaling chroma directly to the target resolution. This proved to be suboptimal in some situations, e.g. because when using a softer algorithm for chroma upsampling, the final image got overly soft when using large scaling factors. Just try this with a test pattern: Use a somewhat soft chroma upscaling algorithm (e.g. SoftCubic), and a sharp image upscaling algorithm (e.g. Lanczos), then upscale a small chroma test image by 400% and you'll see that chroma will be blurred a lot. Using a combination of SoftCubic + Lanczos would achieve better results. Some users argue for using a sharp chroma upscaling algorithm, anyway, so for those it might make no difference, though.

Yes I notice it wasn't that long ago that madVR switched to the new algo. The thing about chroma is that our eyes aren't very sensitive to it which is why 4:2:0 exists in the first place. And making every user pay for the extra processing (and power bill) just to satisfy a few vocal ones isn't what I would do. I have plans (longer term) to allow scripting to add stages to the rendering pipeline (such as doubling chroma) via pixel shaders and a script file. It actually isn't that hard to do.

@Zachs

Do you have any plan to implement DXVA scaling? I found out that MadVR's DXVA scaler is quite good for me using Intel HD3000.

Yes I noticed that on my Intel HD 3000 too. However, MPDN isn't written with using DXVA at any stage in mind (hence no support for deinterlacing), so supporting it would be quite a massive rewrite. Besides, you *should* be getting DXVA scaling if you were using EVR on every other media player on Windows.

scaling looks fine. i don't see an obvious issue at the moment.

jincs looks pretty good but very unsharp even 8 tabs maybe linear light helps in this case like it helps with catmull-rom.

playback is still not working well this time it didn't work well in fullscreen and windowed.

i guess the issue has something to do with this:
http://abload.de/img/issue4nskk.png

edit: forget that screen happens with very stable numbers too.

Jinc generally gives a very smooth appearance even when used in upscaling. To get sharper images you could try Lanczos.

If playback stutters this time even in FSE mode, then it is definitely to do with backbuffer count (that's the only thing I changed in regards to playback - D3D9 backbuffer count to 4, D3D10 to 2). Are you still testing on Windows 10 preview? Can you try D3D9 path to see if it is better this time?

From the stats, if the present time is low and delayed frame count doesn't go up, then it's outside of MPDN's control (it'll be Windows or drivers from the moment you call Present()).

[madshi]

Yes I notice it wasn't that long ago that madVR switched to the new algo. The thing about chroma is that our eyes aren't very sensitive to it which is why 4:2:0 exists in the first place. And making every user pay for the extra processing (and power bill) just to satisfy a few vocal ones isn't what I would do.
Downscaling is rather the exception than the rule, though. Today most displays are either 1080p or higher, and 99.9% of all content available today is 1080p or lower. So in most cases you need to upscale. Sure, if you have 4K content, there's a chance you need to downscale instead today. But that won't be the norm for long, either. 4K displays are soon going to be everywhere. Handling chroma separately is a very big performance advantage when downscaling 4K to 1080p, but in most other cases, the performance benefit of scaling chroma separately is much smaller.

[Zachs]

Downscaling is rather the exception than the rule, though. Today most displays are either 1080p or higher, and 99.9% of all content available today is 1080p or lower. So in most cases you need to upscale. Sure, if you have 4K content, there's a chance you need to downscale instead today. But that won't be the norm for long, either. 4K displays are soon going to be everywhere. Handling chroma separately is a very big performance advantage when downscaling 4K to 1080p, but in most other cases, the performance benefit of scaling chroma separately is much smaller.

Not that soon as most people would've just bought new big screen LCDs in the past few years. I certainly won't be upgrading until my current LCDs kick the dust.

Not to mention a lot of the laptops sold today still spot a 1366x768 screen! In which case, even 1080p videos need to be downscaled. 4K Blu-rays are coming in April 2015. It'll take some time before 4k panels are ubiquitous, definitely not in half a years time!

My point is, pick any given point in time, you'll find that downscaling is a necessity -- 1080p on 1280x1024 or 1366x768 screens, 4K on 1080p screens, and in the future, where 4k screens are ubiquitous (long way yet), 8k on 4k screens and so on.

I'd say it is just as important as upscaling -- you could argue that we should all be watching 1080p contents now, which means you will never need to upscale, only downscale in windowed mode. ;) Or even at 720p, you will never need to upscale chroma to 400%, hence there's no benefits for chroma doubling. In fact, a couple of years back, I threw away my entire DVD collection because I bought a 1080p TV! Even my wife couldn't bare to watch DVDs on a 55" HDTV, regardless of upscaling algo used.

[madshi]

Who is going to buy 4K media for an 1080p display? In my experience the majority of madVR users are asking about upscaling algorithms. Some are asking about downscaling, but it seems to be the minority, at least that's my subjective impression.

BTW, April 2015 appears to be a bit too optimistic for 4K Blu-Ray:

http://www.techradar.com/news/television/4k-blu-ray-disks-will-be-on-the-shelves-by-christmas-2015-1264317

[dukey]

Over here there are a lot of 4k tvs on sale.

[Zachs]

Who is going to buy 4K media for an 1080p display?

Who wouldn't if it's around the same price?
Eventually, you'd want to get a 4K display. It's definitely worth while to spend that extra bucks to get 4k media.

Personally I have 3 monitors and 2 TVs at home. If I get a 4k display, the other 2 TVs are still going to be only 1080p.

Anyway this discussion is going nowhere. To each his own really. Freedom of choice is always good.

[Zachs]

Over here there are a lot of 4k tvs on sale.

That's hardly the point is it?

[huhn]

Yes I noticed that on my Intel HD 3000 too. However, MPDN isn't written with using DXVA at any stage in mind (hence no support for deinterlacing), so supporting it would be quite a massive rewrite. Besides, you *should* be getting DXVA scaling if you were using EVR on every other media player on Windows.

how about adding a simple bob deinterlacer better than nothing and no need for something like openCL.

Jinc generally gives a very smooth appearance even when used in upscaling. To get sharper images you could try Lanczos.

I just wonder how the result would look. I very very rarely downscale.

If playback stutters this time even in FSE mode, then it is definitely to do with backbuffer count (that's the only thing I changed in regards to playback - D3D9 backbuffer count to 4, D3D10 to 2). Are you still testing on Windows 10 preview? Can you try D3D9 path to see if it is better this time?

From the stats, if the present time is low and delayed frame count doesn't go up, then it's outside of MPDN's control (it'll be Windows or drivers from the moment you call Present()).
yes I'm still at windows 10 preview. current driver geforce 344.11

v2.5.1
in general the issue sometimes comes after some time
both fail directx 9 and 10.1
directx 9 fullscreen usually fails most up to issue like this:
http://abload.de/img/untitledmni96.png

if the issue isn't there from the start it can be started by changing the position in the file.

madVR runs totally fine.

I try it later on my windows 7 HTPC to make sure this isn't a issue with windows 10 preview

other new issue.
if the window of the is in the background video or audio can get stuck.

when audio crashes it give this error

TITLE: mscorlib Error
------------------------------

An unexpected error 'System.Runtime.InteropServices.COMException' has occurred.

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

Exception from HRESULT: 0x88780096 (mscorlib)

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

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


===================================

An unexpected error 'System.Runtime.InteropServices.COMException' has occurred.

------------------------------
Error Type = System.Runtime.InteropServices.COMException
Error Message = Exception from HRESULT: 0x88780096
Error Source = mscorlib
Error Site = Void ThrowExceptionForHRInternal(Int32, IntPtr)
Error occurred = at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at MediaPlayerDotNet.MainForm.†††
†††‰†�(Int32 )
at MediaPlayerDotNet.MainForm.†††
††††•Œ(Int32 )
at MediaPlayerDotNet.MainForm.†††
††††”ž()
at MediaPlayerDotNet.MainForm.†††
††††•Ž()
at MediaPlayerDotNet.MainForm.†††
††††˜†(Object , MouseEventArgs )
at System.Windows.Forms.ScrollableControl.OnMouseWheel(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseWheel(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at MediaPlayerDotNet.MainFormBase.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
OS Version = Microsoft Windows NT 6.3.9600.0
Total Physical Memory = 15,9 GB
Available Physical Memory = 13,3 GB
Date Time = 08.10.2014 14:58:36
User Name = KRAUSER\Administrator
Application Startup Path = C:\probs
Application Executable Path = C:\probs\MediaPlayerDotNet.exe
CurrentDirectory = C:\probs
SystemDirectory = C:\WINDOWS\system32
Ran As Admin = True
HasShutdownStarted = False
MachineName = KRAUSER
ProcessorCount = 8
LogicalDrives = C:\, D:\, E:\
EnvironmentVariables = COMPUTERNAME = KRAUSER; USERPROFILE = C:\Users\Administrator; HOMEPATH = \Users\Administrator; LOCALAPPDATA = C:\Users\Administrator\AppData\Local; PSModulePath = C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\; PROCESSOR_ARCHITECTURE = AMD64; Path = C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Livestreamer; CommonProgramFiles(x86) = C:\Program Files (x86)\Common Files; ProgramFiles(x86) = C:\Program Files (x86); PROCESSOR_LEVEL = 6; LOGONSERVER = \\KRAUSER; PATHEXT = .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC; HOMEDRIVE = C:; SystemRoot = C:\WINDOWS; SESSIONNAME = Console; ALLUSERSPROFILE = C:\ProgramData; PUBLIC = C:\Users\Public; FPS_BROWSER_APP_PROFILE_STRING = Internet Explorer; APPDATA = C:\Users\Administrator\AppData\Roaming; PROCESSOR_REVISION = 3a09; USERNAME = Administrator; CommonProgramW6432 = C:\Program Files\Common Files; TEMP = C:\Users\ADMINI~1\AppData\Local\Temp; CommonProgramFiles = C:\Program Files\Common Files; OS = Windows_NT; USERDOMAIN_ROAMINGPROFILE = KRAUSER; PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 58 Stepping 9, GenuineIntel; ComSpec = C:\WINDOWS\system32\cmd.exe; SystemDrive = C:; FPS_BROWSER_USER_PROFILE_STRING = Default; ProgramFiles = C:\Program Files; NUMBER_OF_PROCESSORS = 8; TMP = C:\Users\ADMINI~1\AppData\Local\Temp; ProgramData = C:\ProgramData; ProgramW6432 = C:\Program Files; windir = C:\WINDOWS; USERDOMAIN = KRAUSER
RuntimeVersion = 4.0.30319.36323
Thread Count = 52
Handle Count = 758
VM Size = 1,2 GB
Peak VM Size = 1,2 GB
Working Set Size = 458,8 MB
Max Working Set Size = 1,3 MB
Min Working Set Size = 200 KB
Modules = MediaPlayerDotNet.exe, ntdll.dll, MSCOREE.DLL, KERNEL32.dll, KERNELBASE.dll, ADVAPI32.dll, msvcrt.dll, sechost.dll, RPCRT4.dll, mscoreei.dll, SHLWAPI.dll, combase.dll, USER32.dll, GDI32.dll, IMM32.DLL, MSCTF.dll, clr.dll, MSVCR120_CLR0400.dll, mscorlib.ni.dll, ole32.dll, kernel.appcore.dll, CRYPTBASE.dll, bcryptPrimitives.dll, uxtheme.dll, clrjit.dll, OLEAUT32.dll, System.ni.dll, System.Drawing.ni.dll, System.Windows.Forms.ni.dll, bcrypt.dll, CRYPTSP.dll, rsaenh.dll, DirectShowLib-2005.dll, SharpDX.Direct3D9.dll, SharpDX.dll, comctl32.dll, dwmapi.dll, System.Configuration.ni.dll, System.Core.ni.dll, System.Xml.ni.dll, gdiplus.dll, DWrite.dll, WindowsCodecs.dll, shell32.dll, SHCORE.dll, YAXLib.dll, System.Xml.Linq.ni.dll, VideoFrameServicesNative.dll, d3d9.dll, nvd3dumx.dll, PSAPI.DLL, VERSION.dll, nvspcap64.dll, D3D9NativeServices.dll, SETUPAPI.dll, CFGMGR32.dll, WTSAPI32.dll, WINMM.dll, WINMMBASE.dll, DEVOBJ.dll, powrprof.dll, nvSCPAPI64.dll, WINSTA.dll, nvapi64.dll, WINTRUST.dll, CRYPT32.dll, MSASN1.dll, dxgi.dll, dcomp.dll, d3dx9_43.dll, usp10.dll, CommandLine.dll, clbcatq.dll, dataexchange.dll, TWINAPI.dll, twinapi.appcore.dll, quartz.dll, LAVSplitter.ax, avformat-lav-56.dll, WS2_32.dll, NSI.dll, avutil-lav-54.dll, libbluray.dll, avcodec-lav-56.dll, qcap.dll, sxs.dll, LAVVideo.ax, avfilter-lav-5.dll, swscale-lav-3.dll, qedit.dll, COMDLG32.dll, MSVFW32.dll, mfplat.dll, RTWorkQ.DLL, AVRT.dll, wmvdecod.dll, msdmo.dll, mfperfhelper.dll, LAVAudio.ax, avresample-lav-2.dll, DDRAW.dll, DCIMAN32.dll, devenum.dll, URLMon.DLL, WININET.dll, iertutil.dll, MMDevAPI.DLL, wdmaud.drv, ksuser.dll, AUDIOSES.DLL, msacm32.drv, MSACM32.dll, midimap.dll, DSOUND.DLL, ntmarta.dll, NETAPI32.dll, netutils.dll, srvcli.dll, wkscli.dll, CallbackFilter.ax, Microsoft.ExceptionMessageBox.dll, Microsoft.VisualBasic.ni.dll, System.Management.ni.dll, diasymreader.dll, SspiCli.dll


===================================

Exception from HRESULT: 0x88780096 (mscorlib)

------------------------------
Program Location:

at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at MediaPlayerDotNet.MainForm.†††
†††‰†�(Int32 )
at MediaPlayerDotNet.MainForm.†††
††††•Œ(Int32 )
at MediaPlayerDotNet.MainForm.†††
††††”ž()
at MediaPlayerDotNet.MainForm.†††
††††•Ž()
at MediaPlayerDotNet.MainForm.†††
††††˜†(Object , MouseEventArgs )
at System.Windows.Forms.ScrollableControl.OnMouseWheel(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseWheel(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at MediaPlayerDotNet.MainFormBase.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

[huhn]

Who wouldn't if it's around the same price?
Eventually, you'd want to get a 4K display. It's definitely worth while to spend that extra bucks to get 4k media.

Personally I have 3 monitors and 2 TVs at home. If I get a 4k display, the other 2 TVs are still going to be only 1080p.

Anyway this discussion is going nowhere. To each his own really. Freedom of choice is always good.

aren't the industry selling way more DVD than BD even in year 2014?

don't forget we need a way to get them ripped be for we can use them with madVR or MPDN. this may take sometime...

so getting UHD BD for fall/winter 2015 and using them for madVR or MPDN are to totally different things.

[XMonarchY]

This looks interesting, but there is no way to use 3DLUT's with this player, isn't there? Is that something that will be added later? I also noticed that some other madVR options/settings are missing and that it has some options and settings not present in native madVR. What's the advantage of this player over others, like MPC-HC + madVR combination?

I also think that upscaling is more important than downscaling at this point. madVR is not for laptops that use sub-1080p or sub-720p resolutions, although they can also use madVR's features to improve video playback rendering quality. madVR is for high-end HTPC / Gaming PC systems that can handle its demanding rendering improvement methods/techniques. madVR actually requires you have a high-end videocard to use the most demanding and most image-improving features it has, which happen to be image and chroma upscaling, NNEDI3, doubling/quadrupling, artifact removal, dithering, 3DLUTs, etc. No other renderers have those features, which is what madVR unique.

I actually think that madVR does an incredible job at making DVD content look superb on HDTV 1080p screens on systems that can handle NNEDI3 quadrupling, artifact removal, dithering, and 3DLUT utilization. It actually makes such low resolution content watchable on 1080p screens. Eventually, people will switch to 4K, which isn't going to happen so soon. I am not sure whether today's high-end videocards can easily handle 1080p to 4K NNEDI 3upscaling, doubling/quadrupling, etc., but it is usually gamers who own such high-end cards. Seeing how no single-core GPU card can handle all games @ 4K @ 60fps, I doubt there will be a massive switch to 4K screens in the near future as it would require very expensive investment into the screens themselves and hardware needed to use them for entertainment purposes. Personally, I feel that there are still plenty of room to improve video image @ 1080p.

[foxyshadis]

aren't the industry selling way more DVD than BD even in year 2014?

In the US it's ~45%/55%, in Japan it's up to ~70%/30%. Of course, among AV enthusiasts like us, it's probably nearly 90%/10% where it's possible to get BDs.

[huhn]

In the US it's ~45%/55%, in Japan it's up to ~70%/30%. Of course, among AV enthusiasts like us, it's probably nearly 90%/10% where it's possible to get BDs.

I only found a chart for germany (wikipedia) it's still 25%/75% there. I wonder about the rest of Europe.

[Zachs]

how about adding a simple bob deinterlacer better than nothing and no need for something like openCL.

other new issue.
if the window of the is in the background video or audio can get stuck.

when audio crashes it give this error


Bob deinterlacer isn't really adding much value? Doesn't LAV video decoder have DXVA deinterlacing built in?

The audio crashing is due to your audio device suddenly disappearing - when you scrolled your mouse wheel, MPDN tried to adjust volume but failed.

This looks interesting, but there is no way to use 3DLUT's with this player, isn't there? Is that something that will be added later? I also noticed that some other madVR options/settings are missing and that it has some options and settings not present in native madVR. What's the advantage of this player over others, like MPC-HC + madVR combination?

No 3DLUT support yet. I will look into supporting that in the future.

There's no advantage using this player. Not trying to pry people away from their beloved madVR, just sharing this player as an alternative. There are some features that MPDN have and not madVR such as fast downscaling, Jinc downscaling, 4-tap Lanczos Spline Jinc upscaling, 10- and 16-bit output modes. MadVR has a lot more features tough like what you mentioned 3DLUT, NNEDI3, linear light scaling etc.

Anyway, no one was disputing madVR doesn't do a good job or that upscaling isn't important. But I simply can't play 4K videos with madVR on my 1080p screen. Forget bluray, OnePlusOne has 4k 24fps recording capabilities. MPDN isn't as good as madVR in the picture quality department (namely it's missing advanced features but madVR wasn't written in one day either) but it works across a wider spectrum (namely downscaling from 4k). The goal of MPDN is not for the pedantic ones who want utmost quality regardless of cost but one for the pragmatists who want decent quality and at a reasonable cost. If there's an option to add higher picture quality features, I would but only if they do not affect those who don't need / want them.

[huhn]

Bob deinterlacer isn't really adding much value? Doesn't LAV video decoder have DXVA deinterlacing built in?
no dxva but CUVID/QS and of cause software YADIF.
YADIF can be pretty slow with FHD sources.

[Zachs]

@huhn

Can you test this version (http://www.zachsaw.com/downloads/MediaPlayerDotNet/MediaPlayerDotNet_x86_2_5_2_1891.zip) to see if it solves the problem of frame dropping / stuttering for you?

Did you get dropped frames when stuttering happens?