madVR - high quality video renderer (GPU assisted)

[zoyd]

So basically I'd be using something like dE to calculate the best compromise between saturation loss and luminance loss (while keeping the hue angle constant)?

Yes but that assumes the hue angle is obtainable at the desired saturation location. This may not always be the case if for example you are mapping P3 primaries down to Rec709 primaries. In that case you have to vary all three to find the best dE-based compromise, because out-of-gamut now can involve the wrong hue, saturation and luminance.

[StinDaWg]

This can happen with weird refresh rates, especially in 10bit mode, especially with AMD GPU drivers. I don't think I've seen this reported with NVidia drivers yet. One possible fix is to lower the number of prepresented frames to e.g. 4-6. This reportedly has helped for most users in the past. I believe it's a GPU driver issue, which is related to the mixture of using D3D11, weird refresh rates, a high number of prepresented frames, and maybe 10bit output.
I tried changing present frames to 1,2,3, and 4 as well as changing to 8-bit output and it made no difference. Even though queues are near empty and stay that way madvr is not reporting any dropped frames, so I'm not sure what to think really.

Any idea why it does the same thing in D3D11 FSE after pausing the video and Windows screen saver activates? This happens with all files not just 30 fps. Should I just ignore the stats as long as I don't visually see stuttering?

[ShiftyFella]

Yes.


Ok. To be fair, both the resolution and the refresh rate differs when comparing hdmi and display port in your screenshots. So I'm not sure if it's proof yet that display port doesn't have the issue.
Ah, sorry. It's two different devices with different resolutions, tv is connected to hdmi and monitor to display port and can only do 60hz, while tv has different display modes set up.

Ok, just did a quick test again with display modes turned off for tv and monitor resolution dropped down to 1080p when using dp or hdmi connection to make it more fair comparison. Now I'm not sure what to make of it. With display modes turned off for TV and using hdmi or display port with monitor, FSE produces no issues and all ques are filled up with presentation times looking normal. turning display modes on for TV produces above mentioned glitch. Next thing I did is left only 1080p60 in display modes plus turned them on for monitor. Having display modes on or off for monitor produced no issues with FSE using either hdmi or display port connection. Meanwhile TV even with display mode of 1080p60 produces glitches in FSE but with it turned off and running at same 1080p60 has no issues. To make sure there is no bandwidth limitation or multi-monitor issues, I had one device connected at a time to video card and used same cable for hdmi connection. This is really weird and I'm not sure this is even same issue StinDaWg experiencing, if this is an issue at all and nothing more then just random amd driver glitches

[Sunset1982]

This is really what the media player should do. I do know that not all media players provide a nice exclusive mode GUI, though, which is the reason why I implemented the seekbar in the first place. Maybe at some point I'll add more GUI controls for media players that don't have their own in exclusive mode. But it's not a high priority atm.


Is there a player which supports madvr fse mode while using a gui osd? If so, which one is it? A player with support for madvr fse d3d11 (for 10 bit output) and a good skinnable gui would be great...

[SpoCk0nd0pe]

My control over what the GPU outputs is very limited. I can either output frame packed 3D, or conventional 2D. I have no other options. When outputting conventional 2D, I can do some fancy pixel resorting, which allows me to render 3D for those line or column alternate displays (passive IPS LCDs). But I don't see how I could do frame sequential 3D. Neither Windows nor the GPU manufacturers offer any kind of API for that.
Frame sequential 3d in conventional 2d is really what I am looking for.

So for example: madvr gets frame packed 3d material at 47.952 Hz. What I would like to be able to do is: split the right and left frames and send them one after the other at 95.904 Hz to the TV as conventional 2d frames.

[madshi]

- Radeon RX 480 (HDCP 2.2 and HDMI 2.0 with support for HDR), connected via HDMI to an HDR 4K television.

I'm trying to play HDR 4K demo clips on MPC-HC which has been configured to use MadVR but the screen remains black. Audio plays, though.
HEVC decoding with Radeon 480 has been reported to be problematic before. Does this work with EVR?

Yes but that assumes the hue angle is obtainable at the desired saturation location. This may not always be the case if for example you are mapping P3 primaries down to Rec709 primaries. In that case you have to vary all three to find the best dE-based compromise, because out-of-gamut now can involve the wrong hue, saturation and luminance.
Doing this kind of stuff in real time in a pixel shader does comes with some limitations. Minimizing dE doesn't seem to be a simple one-step math calculation, at least I don't see how I would do that. So I'll probably stick to keeping the hue angle constant at all times and just try to find the right compromise between reducing saturation and luminance.

Any idea why it does the same thing in D3D11 FSE after pausing the video and Windows screen saver activates? This happens with all files not just 30 fps. Should I just ignore the stats as long as I don't visually see stuttering?
I don't really know. I suppose as long as there are no frame drops reported, it's ok.

Is there a player which supports madvr fse mode while using a gui osd? If so, which one is it?
I think there are several players, but why don't you try for yourself? The list of supported players is available on www.madVR.com.

Frame sequential 3d in conventional 2d is really what I am looking for.

So for example: madvr gets frame packed 3d material at 47.952 Hz. What I would like to be able to do is: split the right and left frames and send them one after the other at 95.904 Hz to the TV as conventional 2d frames.
But how would the display know that it's receiving frame sequential 3D instead of 2D? And how would the display know which frame is for the left eye and which for the right eye? Probably HDMI supports metadata to pass this information to the display somehow. But there's no API available I could use to send this information to the display.

It's also not really all that simple to implement this feature. If audio and video run out of sync, I'll need to drop a frame. Usually I only drop one frame. But with frame sequential output I'd have to make sure I always drop 2 frames, so the eye order doesn't swap.

Why do you need this? Does your TV not support frame packed 3D?

[colinhunt]

HEVC decoding with Radeon 480 has been reported to be problematic before. Does this work with EVR?
HEVC 10bit UHD/59.94p (SDR), RX 480 connected via HDMI to a TV, MPC-HC with madVR: black screen, both fullscreen and windowed.

Same source, GPU etc. but with EVR: plays perfectly, CPU usage 2-5%

EVR doesn't support HDR output to HDR TV either.

[jerryleungwh]

The log is pretty hard to interpret. It's made for my eyes, so I'm not sure if you can find what you need. Those 2 lines you mentioned are "good", they should be there are don't indicate a problem.

If you upload the (zipped) log somewhere I can have a look if I can see something. Please activate the Ctrl+J OSD and keep it active while creating the log, then try to enter exclusive mode. Having the Ctrl+J OSD turned on is important because in this specific case it adds more information to the debug log.



Much appreciated. What I did was I turned on the OSD, enter fullscreen and see the "exclusive mode failed" message and leave it for 5 seconds before closing it. It hope that's correct.

https://drive.google.com/file/d/0By8yb27gSv3tXzIydFliaGRCdms/view?usp=sharing

And if you don't mind may I also upload another log file later for you to take a look? I cannot seem to play frampacked 3d properly either. My TV detects the 3D signal but the image output is still in 2D

[e-t172]

Doing this kind of stuff in real time in a pixel shader does comes with some limitations. Minimizing dE doesn't seem to be a simple one-step math calculation, at least I don't see how I would do that. So I'll probably stick to keeping the hue angle constant at all times and just try to find the right compromise between reducing saturation and luminance.

Couldn't you generate a 3DLUT that precomputes all this stuff, and then you just apply the 3DLUT to every frame? In fact, that's exactly what happens when someone generates a 3DLUT using e.g. Argyll's collink and applies it in madVR - collink computes the gamut mapping between, say, BT.709 and the (measured) gamut of the output device, precomputes the conversion for every possible color, and outputs a 3DLUT to be used in madVR. This is literally the exact same problem. In fact one could theoretically use collink for HDR to SDR conversion today, though I don't know how well it would work.

(Generating that 3DLUT in a reasonable amount of time, on the other hand, could prove challenging. collink for example can take a while to run. Waiting such a long time on playback start could be annoying. However it might be possible to make the process much faster by making a few reasonable performance tradeoffs. Graeme would probably know a lot more about this, since he wrote this stuff.)

By the way, I see we've come full circle in this discussion, we're back to discussing the use of DeltaE which I already suggested 7 pages back (http://forum.doom9.org/showthread.php?p=1773509#post1773509). There was some talk about using CAM02-SCD (http://www.springer.com/cda/content/document/cda_downloaddocument/9781441961891-c1.pdf?SGWID=0-0-45-1337202-p173968189) as well. I believe the main reason why you were not very enthusiastic about this idea was because calculating dE94 or dE2000 is done in CIELAB, which goes against the ICtCp trend that you mentioned (http://forum.doom9.org/showthread.php?p=1773568#post1773568). Maybe there is a robust color difference formula that can be used in ICtCp somewhere?

(By the way: if you look at the DeltaE formulas themselves, you might notice that the problem of minimizing dE94 can be rephrased in 3D space as finding the closest point that is within the gamut volume in the CIELAB system of coordinates. Maybe that could help, especially considering this is done on a GPU? My math skills are not good enough to allow me to elaborate I'm afraid.)

[madshi]

HEVC 10bit UHD/59.94p (SDR), RX 480 connected via HDMI to a TV, MPC-HC with madVR: black screen, both fullscreen and windowed.

Same source, GPU etc. but with EVR: plays perfectly, CPU usage 2-5%

EVR doesn't support HDR output to HDR TV either.
Hmmmm... Does it work with madVR if you use DXVA copyback instead of native DXVA decoding?

Much appreciated. What I did was I turned on the OSD, enter fullscreen and see the "exclusive mode failed" message and leave it for 5 seconds before closing it. It hope that's correct.
According to the log madVR *tries* to enter fullscreen exclusive mode, but DXGI/Direct3D reports "DXGI_STATUS_OCCLUDED". Which according to Microsoft means:

> DXGI_STATUS_OCCLUDED if you request full-screen mode
> and it is unavailable

Whatever that means. I don't think there's much I can do about it.

And if you don't mind may I also upload another log file later for you to take a look? I cannot seem to play frampacked 3d properly either. My TV detects the 3D signal but the image output is still in 2D
A log file wouldn't help there.

I suspect all these problems are caused by Optimus. I don't really know how to help there, unfortunately.

Couldn't you generate a 3DLUT that precomputes all this stuff, and then you just apply the 3DLUT to every frame?
That's not possible, unfortunately, because the values I get are sometimes so much out of range that they don't fit into the 3dlut input range, even if use "video levels" for the 3dlut, which provides BTB + WTW headroom. E.g. consider a blue pixel with 400 nits, with a 400 nits display. For a legal RGB value (16-235) the blue pixel can be max 24 nits (with a 400 nits display). I'm not sure which RGB value the blue pixel would have with 400 nits, but it would be WAY *WAY* out of range.

By the way, I see we've come full circle in this discussion, we're back to discussing the use of DeltaE which I already suggested
Yes, but you suggested it in a different way. Basically you suggested to replace the out-of-gamut color with color "x". This color "x" would be the one in-gamut color which has the lowest dE difference to the original out-of-gamut color. I'm not aware of a simple math formula to calculate "color x" from the original out-of-gamut color. I'm not even sure how to calculate it at all, other than using trial-and-error.

We're now discussing using dE just to find a decent compromise between losing saturation vs losing luminance, while keeping the hue angle constant. That significantly simplifies the math. Although I'm still not sure how to do the math right now.

[e-t172]

That's not possible, unfortunately, because the values I get are sometimes so much out of range that they don't fit into the 3dlut input range, even if use "video levels" for the 3dlut, which provides BTB + WTW headroom. E.g. consider a blue pixel with 400 nits, with a 400 nits display. For a legal RGB value (16-235) the blue pixel can be max 24 nits (with a 400 nits display). I'm not sure which RGB value the blue pixel would have with 400 nits, but it would be WAY *WAY* out of range.

Have you considered widening the input range of the 3DLUT to account for all possible input values? That will probably require having a less-than-perfectly-granular 3DLUT (i.e. applying the 3DLUT will require interpolating between 3DLUT values), but that doesn't sound like a big deal - in fact, AFAIK color-managed software never use a fully specified 3DLUT like madVR does, they use something like a 64x64x64 cube and interpolate the missing points. ICC profiles, for example, contain such lower-precision 3DLUTs (cLUTs in ICC parlance) so that people don't end up with ICC profiles that are 100MB in size :)

We're now discussing using dE just to find a decent compromise between losing saturation vs losing luminance, while keeping the hue angle constant. That significantly simplifies the math.

Okay. Hopefully you'll be able to find some way to lift this constraint eventually, because as you said preserving the hue angle is sometimes counter-productive:

Graeme makes the excellent point that desaturating a pixel too much doesn't really preserve hue. E.g. an almost white pixel doesn't really preserve any hue at all, although strictly the hue angle might still be perfect.

[madshi]

Have you considered widening the input range of the 3DLUT to account for all possible input values? That will probably require having a less-than-perfectly-granular 3DLUT (i.e. applying the 3DLUT will require interpolating between 3DLUT values), but that doesn't sound like a big deal - in fact, AFAIK color-managed software never use a fully specified 3DLUT like madVR does, they use something like a 64x64x64 cube and interpolate the missing points.
The widening would have to be ultra extreme to handle all possible situations. I don't think that makes much sense. The widening would dramatically increase the needed 3dlut size, or alternatively noticeably decrease 3dlut accuracy. Furthermore the widening would also dramatically slow down offline calculation, due to all the possible extremely wide out-of-gamut situations. I expect calculating such a 3dlut offline would *at least* cost multiple seconds, after heavy optimizations. Maybe minutes, without heavy optimizations. It just doesn't make sense.

[colinhunt]

Hmmmm... Does it work with madVR if you use DXVA copyback instead of native DXVA decoding?
No. Green screen instead of a black one.

[e-t172]

The widening would have to be ultra extreme to handle all possible situations. I don't think that makes much sense. The widening would dramatically increase the needed 3dlut size, or alternatively noticeably decrease 3dlut accuracy. Furthermore the widening would also dramatically slow down offline calculation, due to all the possible extremely wide out-of-gamut situations. I expect calculating such a 3dlut offline would *at least* cost multiple seconds, after heavy optimizations. Maybe minutes, without heavy optimizations. It just doesn't make sense.

Actually, strike my last suggestion - I just realized that you were referring to RGB values, which are indeed problematic. What about generating a 3DLUT that maps YCbCr (or ICtCp) values? That would be just as valid, and I presume that wouldn't cause any range issues since your inputs are, almost by definition, in range. 3DLUTs can be applied in any color space, and in fact can even be used to convert between color spaces (e.g. YCbCr to RGB) in addition to doing color processing. So, for example, you could have a 3DLUT that takes ICtCp values as input, applies HDR processing such as gamut mapping or gamma ramps, other/various color processing stuff, and at the same time outputs the final RGB values.

I agree that still doesn't address the issue of calculation time though. However, I would still argue that decreasing 3DLUT accuracy would be a good tradeoff for solving that problem. After all, every color-managed application does this, and they don't suffer from accuracy problems. Argyll even has a tool, profcheck (http://www.argyllcms.com/doc/profcheck.html), that verifies the agreement between interpolated values from an ICC profile's cLUT and the original, full-precision measured values. If you can verify that the difference is less than 1 dE, it's unlikely anyone would be able to notice the difference.

[madshi]

Granted, doing it in YCbCr or ICtCp would be more reasonable. But I still think calculating the 3dlut offline would take much too long. And I don't really see the advantage right now: The math I'm using now works just fine. Except for this one specific problem, and I'm not sure right now how to solve it mathematically, either offline or online. Once I know how to solve it, it's probably possible to do it online, too. So why do it offline? It would cost many hours extra work, delay playback start, have less precision. I simply see no reason why I should do that.

[e-t172]

Sure, this is all mostly speculation :) It's a matter of processing budget, though. Say you have an algorithm or some math formula that, given an input color X, gives you the best output color Y to map to. Say this algorithm takes 4µs to complete for each color. There's no way to do this in realtime for every pixel of every frame, but it would only take 1 second to generate a 64x64x64 3DLUT using that algorithm.

[madshi]

Ok, but GPUs are massively parallel, while CPUs are not. If the algo takes 4µs per color per thread on the CPU, then with a quad core CPU it would actually only take 0.25 seconds to calculate a 64^3 3dlut. However, a GPU doesn't calculate just 4 colors at once, but hundreds or thousands at once (not sure how many). So even if the GPU needs 4µs per color, because of the massive parallel calculation, the algo would still run in real time without any problems. But I'd say 4µs on the CPU is very optimistic. It'd probably be much slower than that.

[Shiandow]

We're now discussing using dE just to find a decent compromise between losing saturation vs losing luminance, while keeping the hue angle constant. That significantly simplifies the math. Although I'm still not sure how to do the math right now.

Which dE are you referring to by the way? From the ones defined on this page (https://en.wikipedia.org/wiki/Color_difference), CIE76 seems doable, CIE94 only with constant hue, and CIEDE2000 is just ridiculous.

[madshi]

Good question. I was thinking of using either CIEDE2000 with all the hue stuff removed (which should bring it near to CIE94, I think), or straight CIE94. Alternatively, there's a dE formula available in the first google link for the search term "de color difference ipt". In any case, my plan was to stick to constant hue.

[Xaurus]

Anyone else having problems with Pascal GPU (1070,1080) getting the proper P-state when using Madvr in mpc-hc or mpc-be? I can't seem to make it happen actually. I've observed this by using several programs, and GPU-z confirms the speeds are reduced.
Setting "Prefer maximum power" in the Nvidia control panel doesn't make any difference. I've tried to use DDU and reinstall the latest drivers without any effect.
Could anyone else test the built-in graphics test in GPU-z and watch the clock speeds, and then compare it to when you run a full screen video with madvr? Noticeably the RAM speed is reduced.

[zoyd]

Good question. I was thinking of using either CIEDE2000 with all the hue stuff removed (which should bring it near to CIE94, I think), or straight CIE94. Alternatively, there's a dE formula available in the first google link for the search term "de color difference ipt". In any case, my plan was to stick to constant hue.

That's where I would start delL, delC components of dE94.

[SpoCk0nd0pe]

But how would the display know that it's receiving frame sequential 3D instead of 2D? And how would the display know which frame is for the left eye and which for the right eye? It does not necessarily need to know. The idea is to build two switches, one for 3d on/off, one to switch the left and right eye on the glasses.

It's also not really all that simple to implement this feature. If audio and video run out of sync, I'll need to drop a frame. Usually I only drop one frame. But with frame sequential output I'd have to make sure I always drop 2 frames, so the eye order doesn't swap.
I could live with that, I usuall have no frame drops at all with Reclock.

Why do you need this? Does your TV not support frame packed 3D?
I want to replace the motherboard on my TV with this:
https://hardforum.com/threads/no-latency-overclockable-up-to-1080p-270hz-monitor-controller-board.1894299/
My plan is to also build a custom shutter glasses+emitter setup to do 3d active.

[zaemon]

Dumb question but is it possible to create a 3DLUT for 3D playback (with glasses?) and for HDR playback?


Sent from my iPhone using Tapatalk

[huhn]

Dumb question but is it possible to create a 3DLUT for 3D playback (with glasses?) and for HDR playback?


Sent from my iPhone using Tapatalk

putting the glasses between the colorimeter and the display should do the trick.

[zoyd]

putting the glasses between the colorimeter and the display should do the trick.

It's easier if you first profile the meter with glasses in front to without glasses as reference, and create a correction matrix. Then you can do the 3dlut without glasses for more signal.

[Sunset1982]

No. Green screen instead of a black one.

That's exactly what I found out when testing the RX480. Greenscreen when using madVR and LAV with DXVE Copyback. Any ideas why this is happening?

[DragonQ]

What are my options if I want to use MadVR without administrator rights? Presumably there's no way to use it with MPC-HC but are there any other players that include it without having to manually register the filter file?

[Uoppi]

After updating from v0.90.20 to v0.90.21 (haven't got to try v0.90.22 yet), I started getting worse rendering times but only when scaling.

Just wondering what could be affecting the performance so much because according to the changelog, the .20 -> .21 update was almost exclusively HDR-related (which doesn't concern my usage scenario).

The get rendering times down and to avoid dropped frames, I've now downgraded from SSIM 2D to 1D in almost all of my profiles. Nvidia drivers are up to date (I have GTX 960).

[70MM]

Image Doubling question?

Guys Ive never used image doubling but want to try.
I have the new GTX1080 card.

Is it ok to use Image Doubling with just straight 1080p content (ripped BDs)?
Im using the JVC X9000 projector but not sure how you set this up for 1080p content, 1080p > 1080p.

Can some of you offer some instructions please?

Thanks in advance...

[QBhd]

After updating from v0.90.20 to v0.90.21 (haven't got to try v0.90.22 yet), I started getting worse rendering times but only when scaling.

Just wondering what could be affecting the performance so much because according to the changelog, the .20 -> .21 update was almost exclusively HDR-related (which doesn't concern my usage scenario).

The get rendering times down and to avoid dropped frames, I've now downgraded from SSIM 2D to 1D in almost all of my profiles. Nvidia drivers are up to date (I have GTX 960).

I'm wondering if this may be what I noticed after moving from .20 ==> .22

I had to skip .21 since mixed scaling was broken for me, but moving to .22 caused a pretty big performance hit. madshi thought it might be the new rules for when scaling is active and maybe some upscaling refinements now being used... But I'm not so sure, especially now that you see a performance hit with version .21.

QB

[wolfman2791]

It's likely a AMD driver error that stops me from using MPC-HC x64 with madvr. x86 version works fine. The issue is OpenCL. OpenCl kernel compile failure.

Not sure it's worth finding an older driver that works. Will just keep using x86 i guess.

[Uoppi]

I'm wondering if this may be what I noticed after moving from .20 ==> .22

I had to skip .21 since mixed scaling was broken for me, but moving to .22 caused a pretty big performance hit. madshi thought it might be the new rules for when scaling is active and maybe some upscaling refinements now being used... But I'm not so sure, especially now that you see a performance hit with version .21.

QB

Yeah, I saw the posts on previous pages about this and that's what got me wondering. I've encountered decreased performance once before but it was fixed by a GPU driver update.

Anyway, I'll try the .22 version later today and report back.

EDIT: No discernible difference in rendering times here when going from version .21 to .22. So, still no clue where those aforementioned differences originated from.

[Sunset1982]

anyone has an idea what player supports madvr exclusive mode while using a nice osd and not just the madvr fse bar?

[toniash]

anyone has an idea what player supports madvr exclusive mode while using a nice osd and not just the madvr fse bar?

PotPlayer

https://imouto.my/tutorials/configuring-potplayer-for-gpu-accelerated-video-playback-with-dxva-or-cuda-and-also-high-performance-software-decoding/

[Sunset1982]

PotPlayer

tried that, but when I enable FSE mode, I dont get an osd, and when I enable the bar in madvr settings I only get the madvr one. Is there a special option for this?

[toniash]

tried that, but when I enable FSE mode, I dont get an osd, and when I enable the bar in madvr settings I only get the madvr one. Is there a special option for this?

My settings in potplayer
https://www.dropbox.com/s/bhl4u4rfb1wjxbf/pot2.jpg?dl=0
https://www.dropbox.com/s/al74z459zoewwrh/pot1.jpg?dl=0

and enable automatic fullscreen exclusive mode im Madvr
you get the OSD when moving the cursor top or bottom

[chros]

tried that, but when I enable FSE mode, I dont get an osd, and when I enable the bar in madvr settings I only get the madvr one. Is there a special option for this?
Why do you even need this? :) Seekbar makes sense in FSE, but other controls? Use keyboard shortcuts or a remote for the player, and problem solved. :)

[ranpha]

anyone has an idea what player supports madvr exclusive mode while using a nice osd and not just the madvr fse bar?
PotPlayer's Direct3D skin mode. (https://miku.hatsune.my/potplayer-with-seeking-gui-in-madvr-exclusive-mode.jpg)

[Sunset1982]

Why do you even need this? Seekbar makes sense in FSE, but other controls? Use keyboard shortcuts or a remote for the player, and problem solved.

I want to have a nice looking seekbar with a nice blue line



PotPlayer's Direct3D skin mode.

ok, have to try it again

[Uoppi]

With the .22 version (I can't remember seeing this before), the madvr OSD is reporting Bicubic150 AR downscaling in addition to SSIM 1D that is chosen for the profile.

Like this:
image x > super-xbr > super-xbr < SSIM 1D100AR
image y > super-xbr > super-xbr < SSIM 1D100AR < Bicubic150 AR

Would someone be able to tell me what's going on there? This is quadrupling (luma) SD to 1080p.

[Chyrka]

Hi.
I have something strange with playback.
My main GPU is Intel HD3000. I also have Nvidia 210 in the PC but it is not connected to the monitor.
I am using MPC-HC x86 1.7.10.
The choma scaling algorithm is set to default SoftCubic but for some reason it does not work as well as other scaling options.
When I am watching 8-bit video (i.e. NV12 colorspace is used), I always get DXVA chroma scaling in the stats instead of SoftCubic or whatever set in settings. This DXVA scaling gives ugly aliasing and moreover it changes matrices 601-709.
I got this
http://grab.by/Rufs
and this
http://grab.by/RufG
In my old PotPlayer everything is OK.
My previous madvr 0.87.10 acts well.

[huhn]

Hi.
I have something strange with playback.
My main GPU is Intel HD3000. I also have Nvidia 210 in the PC but it is not connected to the monitor.
I am using MPC-HC x86 1.7.10.
The choma scaling algorithm is set to default SoftCubic but for some reason it does not work as well as other scaling options.
When I am watching 8-bit video (i.e. NV12 colorspace is used), I always get DXVA chroma scaling in the stats instead of SoftCubic or whatever set in settings. This DXVA scaling gives ugly aliasing and moreover it changes matrices 601-709.
I got this
http://grab.by/Rufs
and this
http://grab.by/RufG
In my old PotPlayer everything is OK.
My previous madvr 0.87.10 acts well.

you are using DXVA native. on default settings DXVA native is used with DXVA chroma scaling.

go to rendering -> trade quality for performance - disable "use DXVA chroma upscaling when..."

edit: or use DXVA copyback

[Uoppi]

Rendering queue is sometimes hitting a ceiling of 8 max, even though I have set it at 20. Is this a known issue?

I remember there's been reports along the way about rendering queues not filling but this probably only started happening to me with the latest madvr version (v.22).

If I either
1) stop and restart the video or
2) skip forward (and probably backwards too),
the rendering queue is filled properly to max again.

I have GTX 960 with latest drivers + Kodi DSplayer.

[Chyrka]

you are using DXVA native. on default settings DXVA native is used with DXVA chroma scaling.

go to rendering -> trade quality for performance - disable "use DXVA chroma upscaling when..."

edit: or use DXVA copyback

Thank you for your help. With DXVA copyback works great.

[madshi]

I do think the desaturation of high luminance red/orange is too aggressive when using preserve hue. Take this for example:

[...]

Without hue preserve the madVR image luminance is too low and appears oversaturated - with hue preserve you lose all of the amber light and a good portion of the red tent.

The CalMAN LUT appears to mildly desaturate and both white and amber headlights look correct. The red tent brightens without loosing too much red definition.
I've managed to reproduce something similar to the Calman result by keeping saturation the same and removing all excess luminance from each pixel. Which is pretty much the opposite of what madVR 0.99.22 does. The next madVR build will compromise by walking middle ground: I'm going to move such out-of-gamut pixels in-gamut by reducing both (perceived) luminance and saturation in a similar amount. It's not directly a dE formula I'm using, but it should be a decent approximation.

Dumb question but is it possible to create a 3DLUT for [...] HDR playback?
If you let madVR do the tone mapping ("enable HDR processing") then your SDR 3dlut should work just fine for HDR content, too. No need to create a separate 3dlut in that case.

That's exactly what I found out when testing the RX480. Greenscreen when using madVR and LAV with DXVE Copyback. Any ideas why this is happening?
No. If software decoding works fine the greenscreen could be a LAV bug, because it shouldn't make a difference to madVR whether LAV uses software or DXVA copyback decoding. Native DXVA is a different topic, though. Can you upload a zipped debug log with Native DXVA decoding and the black screen somewhere?

What are my options if I want to use MadVR without administrator rights? Presumably there's no way to use it with MPC-HC but are there any other players that include it without having to manually register the filter file?
I think J.River MC uses madVR without installing it. I'm not sure if MC itself might need installation, though.

After updating from v0.90.20 to v0.90.21 (haven't got to try v0.90.22 yet), I started getting worse rendering times but only when scaling.
Can you please post a screenshot of the Ctrl+J OSD for this situation with both v0.90.20 and v0.90.21?

With the .22 version (I can't remember seeing this before), the madvr OSD is reporting Bicubic150 AR downscaling in addition to SSIM 1D that is chosen for the profile.

Like this:
image x > super-xbr > super-xbr < SSIM 1D100AR
image y > super-xbr > super-xbr < SSIM 1D100AR < Bicubic150 AR
Interesting. Doesn't seem to happen on my PC. Again: Can you please post a screenshot of the Ctrl+J OSD, so I can see which exact source resolution and zoom factor etc you're using?

Rendering queue is sometimes hitting a ceiling of 8 max, even though I have set it at 20. Is this a known issue?
Is the present queue near empty? Really, in all these situations a screenshot of the Ctrl+J OSD helps.

[madshi]

After resetting my setting and nuking all of my profiles, I figured out the culprit. It was SuperRes turned on for chroma upscaling. When both SuperRes and HDR procesing turned on, it produces weird color shift and it changes depending on the SR level.
Just tried to reproduce this, but it seems to work just fine on my PC. Can you please make a screenshot of your Ctrl+J OSD, when the problem occurs?

[har3inger]

Three things:

1) Bilateral chroma upscaling is slower now (when using the new algo).
2) HDR handling is slower now.
3) Fixed a couple of bugs in deciding when image doubling and upscaling refinement becomes activated.



I've also noticed big (32ms->45ms) performance drops from .20->.22, but only today. Perhaps a windows update happened in the meantime? I didn't touch my GPU drivers in the meantime, and windows update didn't either. I've reverted for now, because the drop is huge.

What I've tested (not much):

1. At 1:1 scaling factor, render times are the same between the two versions.
2. At any scaling factor, the effect of the chroma scaler shows no differences between the two versions.
3. ED dithering isn't accidentally on. Neither are any of the image enhancement options.
3. Something in the image upscale chain (sxbr > bicubic 150 down > Superres) seems to cost way more with this version.

[madshi]

OK, here goes:

http://screenshotcomparison.com/comparison/178293

http://screenshotcomparison.com/comparison/178295

http://screenshotcomparison.com/comparison/178298

files on mega (https://mega.nz/#!q8ZD1a5b!y0GwLF6MjqVZSK8-1ggtrNsWcEiTIIhf--8oCj48-Ig)

I got a good bunch of other features enabled in the upscaling refinement window, my point was in my real-world use AB75 does wonders. Of course SR looks sharper than without but I believe the top left of the picture in my first link with SR1 looks better with AB25 than without. The whole point of AB to me is that motion looks smoother because edges aren't nearly as noisy anymore. Anyway, please bring it back :scared:
I've downloaded both your mega files, and looked at all your screenshot comparisons. To be honest, I'm not fully sure which image was made with which settings. The files are not named with the full settings in the file name. E.g. they should have been named "SR1 no AB" or "SR2 AB75". But instead they have names such as "1.png", "2.png", "3 orignal 4X.png" etc. How am I supposed to understand which SR level and which AB percent those were made with?

Because all the names are not clear, it's hard to draw final conclusions. But e.g. if I compare your "3 SR1 no AB 4X.png" image with "3 AB75 4X.png", then I think the first one (without AB) looks better with less noise around the edges, especially at the bottom left part of the image.

[madshi]

I've also noticed big (32ms->45ms) performance drops from .20->.22, but only today. Perhaps a windows update happened in the meantime? I didn't touch my GPU drivers in the meantime, and windows update didn't either. I've reverted for now, because the drop is huge.
So far nobody has provided even screenshots of the Ctrl+J OSD. Pretty sad, like 4 reports now, but nobody bothered to post any screenshots or anything else for me to look at.

[jerryleungwh]

According to the log madVR *tries* to enter fullscreen exclusive mode, but DXGI/Direct3D reports "DXGI_STATUS_OCCLUDED". Which according to Microsoft means:

> DXGI_STATUS_OCCLUDED if you request full-screen mode
> and it is unavailable

Whatever that means. I don't think there's much I can do about it.

I have managed to solve the fullscreen exclusive mode problem. Turns out the problem is that I set madVR to present 16 frames in advance while in exclusive mode but apparently my GPU doesn't support that. I change it back to any value lower than 16 then it works perfectly. Thanks!