madVR - high quality video renderer (GPU assisted)

[Sebastiii]

I'm getting a message on screen asking me to update to latest LAVFilters version :P
Did you get this message too ? (i'm on nightly build)
Thanks.

[Clammerz]

I'm getting a message on screen asking me to update to latest LAVFilters version :P
Wrong thread. This is for MadVR. Not LAVFilters.

[el Filou]

This time it worked for whole 7 minutes, i didn't paused it and it crashed MPC.
information before stuttering:https://abload.de/thumb/mpcinfowkoyr.png (http://abload.de/image.php?img=mpcinfowkoyr.png) and during stuttering https://abload.de/thumb/mpcinfowkoyr.png (http://abload.de/image.php?img=mpcinfowkoyr.png)Both images you linked to are the same, could you please check the URLs again?
Why are you using a present queue of 2? Lack of VRAM? A GTX 970 should be fine, try at least 4.

I'm getting a message on screen asking me to update to latest LAVFilters version :P
Did you get this message too ? (i'm on nightly build)
Thanks.A message from madVR? What, on the OSD? Or in the config GUI? I've never seen that.

[madshi]

HDR Sample (https://mega.nz/#!5A9UjCyR!qFf6ocXwhCSzJzq0KAGgIzsVmUQt9zr_3BXY7VjdARk)
@Madshi, I can reproduce this:

When playing a hdr file and using "let madVR decide" under hdr settings, the image turn grayish/colorless when displaying subtitles.
When using "convert HDR to SDR via pixel shader math", the image maintains the colors when playing subtitles.
Thanks, will have a look at this when I find some time.

I have only used 3 versions for this testing...
0.92.11 - not working - worst
0.92.1 - not working
0.91.11 - working

Never had this issue with any version prior to 0.91.11

Here are the files you requested, I've also added snips of each version showing the displays and idents - in the zip, so you can see the issue as is.

http://www.filehosting.org/file/details/720603/WrcJuwVVjk6q5soE/MadVR%20Settings.rar

Thanks for taking a look at this!
I'm getting "invalid download code".

Feature request, being able to customize saturation and hue settings a bit. Older anime can look a bit washed out, but I don't want to touch skin tones much or sometimes at all.
Anyone else keen on seeing a bit more flexibility here?
madVR already supports hue and saturation settings. You can use the media player settings for hue and saturation, madVR will do the actual processing. Or you can even use file tags, e.g. "saturation=+100".

Also I'd like to see madVR being able to set preserve hue in HQ and restoring compressed highlights under 'let madVR decide' if required, or maybe these can be set as default? They improve HDR -> SDR picture quality considerably and don't cost a lot.
Hmmmm... You're right, the "let madVR decide" settings are currently not tuned for highest quality. I'll add that to my list of things to think about. The problem is that if I activate those features by default, users with very slow GPUs will get stuttering, without any obvious way to fix that. So it's not easy to solve.

I'm specifically using the zoom function in MadVR because of the superior scaling algorithms compared to media players. it does the job well, except for zooming away top and bottom bars which I would prefer it did not do
I've already explained how to solve your problem. Did you miss my post? If so, search back.

madshi, I see you explain how zoom control doesn't work when using D3D11 decoding in LAV Filters, I've also discovered that hardware deinterlacing through madVR doesn't work as well (when using 3D11 decoding).

Is this something that's going to change in the future or are there insurmountable obstacles stopping that?
No insurmountable obstacles, just a lot of work.

1) Create the 3DLUT for the BT.2020 colorspace and a gamma of your choice. Using DCI-P3 will give incorrect results.
I don't see why DCI-P3 wouldn't work, but I'm not going to discuss this here. I'm not really an expert in the matter.

I find madVR's 'compress highlights' of HDR->SDR conversion to be too strong. It is trying to recover too much highlights, so much so that the result looks flat, without the necessary contrast.

For instance, a particular scene from Bladerunner 2049

bluray (http://i68.tinypic.com/14w4x11.png)
uhd with madvr HDR->SDR conversion (http://i66.tinypic.com/2vjue7d.png)
- 130nits
- preserve hue (hi, 50/50)
- compress highlights (measure peak lum, restore details, AB-100, AR)

It is worth noting that if I passthrough HDR to the display, what I see with my eyes is closer to bluray. To my eyes, highlights look bright and blown.

@madshi, would it be possible to tone down the strength of highlight recovery, or provide an option?
I have on my to do list to add an option to trade some highlight detail for more "pop". I don't have an ETA for that right now, though.

under ngu sharp there is an option called superresolution, but I don't see any difference in using at maximum strength or not using it.
SuperRes is mainly useful for faster algos with low quality. If you're already using NGU, there's usually no reason to use SuperRes. For chroma it's probably not overly useful, anyway. I wouldn't bother with SuperRes for chroma, to be honest.

Well I've looked at a few 4K videos and it does "harm" AFAIC, enough that I'd rather keep the option disabled and take almost 20 odd ms hit on my 1060. It's not like I'm doing anything with the 4K content other than downscaling anyway.. but with this option enabled as you can see in my previous screenshots it certainly affects the clarity of the image and based on what I've seen it's worth keeping it unticked if you have the performance to spare.
It's not just the general "chroma things" that get touched either like with upscaling..the whole image basically loses some vibrancy with this enabled.
Ok, fair enough. Well, the default settings are tuned for performance, so users with slow GPUs get a smooth experience.

so, nevcairiel came to the conclusion that it is a renderer problem :
https://forum.doom9.org/showthread.php?p=1831863#post1831863

only if I change the 3D setting in madVR from "auto" to "side-by-side" (as nevcairiel suggested) a smooth playback also of the faulty file-type is possible, but it’s very unstable: as soon I go with the mouse over the seek bar or fast-Forward, the playback gets jerky again;

so I have a few questions:

does the “side-by-side” trick provide the same quality as the “auto” mode (are 2 FHD pictures sent to the TV which it combines to a 3D-picture)?
Intel GPU drivers are pretty bad, unfortunately. Haven't had a chance to look at your PMs yet. There's some hope that things might improve for Intel GPUs when I finally switch madVR over to D3D11 rendering. But I don't know when that will happen exactly. Could be a while, I'm not sure.

I have a question about a note in the config GUI: next to "measure each frame's peak luminance" for HDR, it says: "(Does not work with DXVA scaling / decoding)". Is that still valid?
I'm using DXVA11 Native decoding for 2160p, and if I enable ShowRenderSteps, it does show a step 'measure peak luminance'.
Who's right, the config GUI or the OSD?
I'm not sure, from the top of my head. If the OSD says it's doing measurements, then it's probably working fine.

Is the method to using madVR to take a screenshot dependent on the media player? I'm using Alt + I (which is the default shortcut) on mpc-be, is this the correct way?

I have a 4k HDR REC. 2020 file and saving 200% view as png crashes. It works with bmp. Saving 300% view as bmp just maxes out my memory (16GB), then drops to 100MB and madVR crashes saying it can't write to a certain address. Obviously 3x 4k is dumb but should it work?
madVR provides the raw pixel data, the media player does the rest. If BMP works and PNG crashes then it's probably MPC-BE's fault. Or maybe it's simply running out of RAM, I don't know.

Are you using a 32bit or 64bit MPC-BE? I suppose in 64bit running out of RAM should be nearly impossible if you're using a big enough page file. But I don't really know. It's also possible the GPU driver itself can't handle such big images. The GPU could also run out of RAM.

have you ever considered the idea of writing a book on video processing and MadVR?
At some point I'm going to write a documentation / help. That should be enough work on its own.

Watched 4K blade runner 2049 on my 1060 6GB using SSIM 2D LL, upscaling chroma separately turned off (of course) and HQ HDR hue with NGU AA low for chroma. Had to overclock the card for it to have enough headroom and the fan was going pretty hard.. If u want to take HDR seriously (24fps) on a full HD TV a GTX 1060+ is a must. Asmodian will be jumping straight on Volta no doubt :)
To be fair, I have only seen very few situations where SSIM 2D looked noticeably better than SSIM 1D. So you could probably save quite a bit of performance by switching to SSIM 1D, without losing any noticeable image quality.

I'm getting a message on screen asking me to update to latest LAVFilters version :P
Did you get this message too ? (i'm on nightly build)
Weird. You should get that message if you use an outdated LAV build (because some older versions produced crashes). But you should not get it with a recent nightly. What exact version number does your "LAVSplitter.ax" file have?

[-Hitman-]

I'm getting "invalid download code".

Can you try this dropbox share...

https://www.dropbox.com/s/hkbxr5cmhw06q1b/MadVR%20Settings.rar?dl=0

Thanks.

[madshi]

Can you try this dropbox share...
Got it. But fixing will need to wait for the next build.

[madshi]

madVR v0.92.12 released

http://madshi.net/madVR.zip

* added option "use reduce compression artifacts only if it comes for free"
* added experimental "diffuse white" HDR option (mainly for projector owners)
* improved non-hue-preserving HDR tone mapping
* removed low quality hue preserving HDR tone mapping
* HDR option "fix too bright & saturated pixels" is now always available
* display peak nits edit control now accepts down to 80 Nits (formerly 120 Nits)
* added 3dlut information to OSD (only if active)
* fixed: RCA wasn't always run as part of NGU, even though it should
* fixed: little OSD scaling info text glitch
* fixed: #228: deintFps was not 24 for 720p60 decimated 6:4 cadence content (forced film)
* fixed: #394: madvr OSD didn't resize properly when screen masking options are used

[ryrynz]

Cool. Any quick info on the hue changes, say comparative quality to the HQ setting and performance?

[thighhighs]

Thx for new build! Any info about upcoming features?

[Neo-XP]

* added experimental "diffuse white" HDR option (mainly for projector owners)

Any explanation of what it does exactly please?

What are the differences between all these?

- 100 Nits
- 50 Nits, linear
- 50 Nits, spline
- 50 Nits, linear, desaturate
- 50 Nits, spline, desaturate

:thanks:

[SamuriHL]

Yeah SSIM 2D is sharper though with less artifacts and I don't want to settle.


I totally understand that one. My HTPC is probably going to undergo a windows reinstall soon so I can get it back to working status. 3D has been a problem but then I was just playing some recorded TV and it locked up my machine twice. That's not what I call acceptable. LOL. So I may get to play with a clean install and see if I can get SSIM2D working better.

[madshi]

Cool. Any quick info on the hue changes, say comparative quality to the HQ setting and performance?
The new "do *not* preserve hue" option should (hopefully) combine the best of the previous "do not preserve hue" and "preserve hue with low quality" options. And it might be a bit faster than before, too.

The new "preserve hue" option is almost the same as the old "high quality" version, but with a saturation bugfix. Speed probably no noticeable change.

Thx for new build! Any info about upcoming features?
Nope... :)

Any explanation of what it does exactly please?

What are the differences between all these?

- 100 Nits
- 50 Nits, linear
- 50 Nits, spline
- 50 Nits, linear, desaturate
- 50 Nits, spline, desaturate
I've been told that projector owners in a bat cave "officially" target diffuse/specular white at 50 Nits instead of 100 Nits. The HDR transfer function defines for each pixel with which Nits it should be displayed. But that's for 100 Nits diffuse white. So the new option practically scales all HDR pixels down by a factor of 2. So a pixel which should be drawn at e.g. 40 Nits is now drawn at 20 Nits instead.

I don't really know yet what practical effect that will bring. I'll wait for projector users to report back if the new setting is helpful at all or not.

The "linear" option simply halfs each pixel's brightness. The "spline" option tries to keep the original brightness in the shadow detail area, while still ending up at half brightness at diffuse white. I'm not really happy with the spline option yet, the curve probably needs some work.

The "desaturate" option does processing slightly different which results in ever so slightly lower saturation. I'm not sure which is "better" or more correct. So I'm offering both for testing. Of course one will go away once testing has been completed.

[Ver Greeneyes]

Thanks for the new release!


* HDR option "fix too bright & saturated pixels" is now always available

This is purely nitpicking of course, but I think this would flow better as "fix overly bright & saturated pixels".

[ABDO]

thanks @madshi for new madvr build:)

[LigH]

* added option "use reduce compression artifacts only if it comes for free"

:o

Documented to work with NGU resampling; so I tried it with medium AA option. Looks quite good in a rather dark video. Not sure if really fluid, though. I'll test further from here on...

:thanks:

[Manni]

Thanks for the new build Madshi. I still don't have much time right now but I tried to take a quick look.

The new diffuse white option is very useful to us projector owners in a dedicated room, so thanks for implementing this. I didn't have the time to test in depth but it's promising and goes in the direction of what I was asking. You might want to give more options, as although the standard is 50nits for SDR, with HDR we need to go down to 16-20nits in some cases, so I would suggest 25-50 as possible values (factor of 2 or 4).

I still have issues with the way highlights are being processed with the pixel shader conversion, and now that I can rule out the 3D LUT (with the new line in the OSD, super useful so thanks for that), there is something definitely wrong with MadVR's processing.

I specified - as you suggested - my true peakY which is 125nits. I've tested with "This display is already calibrated" and with a null 3D LUT for SDR BT2020 generated with Lightspace (checked and confirmed as not changing anything to the picture).

In both cases, there is very significant posterization/clipping (depending on the settings) with the pixel shader conversion that entirely goes away in passthrough when using a custom curve in the projector. If you don't have a way to upload a custom curve, trust me and take a look at the scene below with the pixel shader conversion.

Quick question: in passthrough, the OSD reports that it's using the SDR-BT2020 3D LUT if 3D LUTs are selectin in the calibration tab. Is it to be expected? It should either use nothing (as it's sending HDR, not SDR) or use an HDR BT2020 3D LUT (I think).

Please try the beginning of Mad Max, minute 3:20. The end of the shot is a sunset with dust settling down and a fade out. The posterization/clipping (depending on settings) on the red sun/sky is very, very bad.

I thought it was my 3D LUT but it isn't, as even a null LUT (or "this display is already calibrated") produces the same effect.

Let me know by email/PM if you need a short clip of the beginning of Mad Max (as well as the null 3D LUT I'm using for these tests if you want to check it).

Any progress on the custom API to send the SDR BT2020 info in the HDMI stream?

EDIT: I have since this that you requested feedback in this thread on AVS (http://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector.html#post55633112), so I posted a copy of this post there, as it's probably a better place to discuss this.
EDIT2: Madshi has confirmed that this is being discussed in the thread linked above as there are more projector owners on AVS, so if you are interested please follow the discussion there.

[zapatista]

Hi Madshi,

is there any possibility madvr would be able to downconvert video in 4k rec.2020 (or DCI-p3) color format to to 1080 resolution in x.v.Color (eg xvYCC, or Extended-gamut YCC)

there are a significant number of higher end 1080 pannels who can display x.v.Color (which is very close to the rec2020 color space), allowing those users to potentially benefit from the higher color detail/quality found in 4k UHD bluray (in addition to the 4k YUV 4.2.0 to 4k RGB 4.4.4 conversion step you have already implemented, before the 4k video is down converted to 1080 10 bit)

[huhn]

it's very unlikely that a display that support x.v color space can't display all these colors out side this mode so a 3D lut give you the same possibility.

just to make something every clear sony come up with this while 1080p sony TV are often used panels that can't reach 100 % BT 709.
and next problem can GPUs even handle this dead colorspace?

[YxP]

* added option "use reduce compression artifacts only if it comes for free"

Laughed at this, feels like it was added for me and other stupids :D :D :D But thanks! (btw using RCA@1 almost all the time)

[YxP]

Btw if it's any interest to you, the GPU sound is almost eliminated when using D3D11 decoder in lavfilters.

[Manni]

Hi Madshi,

is there any possibility madvr would be able to downconvert video in 4k rec.2020 (or DCI-p3) color format to to 1080 resolution in x.v.Color (eg xvYCC, or Extended-gamut YCC)

there are a significant number of higher end 1080 pannels who can display x.v.Color (which is very close to the rec2020 color space), allowing those users to potentially benefit from the higher color detail/quality found in 4k UHD bluray (in addition to the 4k YUV 4.2.0 to 4k RGB 4.4.4 conversion step you have already implemented, before the 4k video is down converted to 1080 10 bit)

x.v.color is not very close to BT2020, it's an extension of rec-709 that has no standard (it varies from manufacturer to manufacturer). With some manufacturers, it's a joke. For example, many Sony projectors reach barely more than rec-709 in x.v.color because they don't have a DCI-P3 filter. JVC projectors with a P3 filter do better. In any case, it's not possible to calibrate to x.v.color because it doesn't have any coordinates (it's entirely relative to rec-709 and dependent on each display's implementation), so I highly doubt that Madshi could do something like this.

You should use the native gamut of the display and create a 3D LUT to BT2020 or DCI-P3 if your display doesn't have a BT2020 or P3 mode. What matters most isn't the saturation at 100%, it's the way saturation will track within the gamut. You can get very decent results even with a display not able to reach much more than rec-709 as long as the saturations are tracking BT-2020.

[MS-DOS]

madshi, I don't recall if you answered this already, do you plan moving black bars detection to GPU?

[huhn]

* added option "use reduce compression artifacts only if it comes for free"

:o

Documented to work with NGU resampling; so I tried it with medium AA option. Looks quite good in a rather dark video. Not sure if really fluid, though. I'll test further from here on...

:thanks:

it's never free with AA only with soft, standard and sharp.
maybe AA should be renamed so it is not so misleading and unlike the other NGU algorithm quite different.

and it's quite an "issue" for me because i'm generally favouring AA for bad sources that need RCA.

[zapatista]

I highly doubt that Madshi could do something like this.

You should use the native gamut of the display and create a 3D LUT to BT2020 or DCI-P3

thank you for the answer and the clear explanation (even if i dont yet understand it fully)

i should have been a little more precise in my original wording
- most current tv models with UHD displays using rec.2020 can still not display the full range of this color space ( or the full range of DCI-P3 ), and in their specs this is quantified in a %
- for ex a 2015 higher end samsung UHD tv (model 65JS9500) (using rec.2020) can still only display 91% coverage of DCI-P3 colour gamut
- in comparison, my 1080p sony tv panel (with HD using rec.709) is able to display 94.7% of the DCI-P3 colour space (using the x.v.color setting i presume), and it can accept this signal over HDMI input (and my HTPC can output x.v.color)
- DCI-3 gamut and the x.v.color gamut are VERY similar in size (but use slightly different primaries)


so if i can convert a 4k video (yuv 4.2.0 10 bit) to 4k RGB 4.4.4, and then in the last conversion step (resolution 4k to 2k) i am hoping to maintain as much of the original color information by converting the rec.2020 UHD color gamut % used by the original file, to x.v.color at the highest % my display can cope with (instead of squashing it into rec.709)

i dont really know what Lut's are or how i can use them ( ? look up tables for the RGB primaries used by the display ?), i was hoping the conversion from UHD video to HD (but in x.v.color instead of rec.709 ) could do this in madvr

is there an easy way i can find out my tv model x.v.color primaries, and then create a 3D lut file, and then load it in madvr ? or would it be possible to enter my information directly into madvr maybe

[JarrettH]

I read this in the other thread about madvr settings.

run RCA as part of NGU, if possible: [Enabled] Combines most of the work required for 'reduce compression artifacts' into NGU Sharp upscaling for a large performance advantage when both are run at the same time.
With this option enabled medium quality forces NGU Sharp to high and high quality forces NGU Sharp to very high.

Why is there this behaviour? So it's only free if you can run NGU high or NGU very high? I run NGU luma medium, and yep it forces it to high, which I can't do.

[ryrynz]

That option has been removed now. I don't think that the requirements have changed.. Still NGU/NGU sharp high/very high.

I believe madshi was looking to add RCA for free with NGU AA it's just as huhn said quite different so requires extra code.

[har3inger]

To clarify:

When RCA tries to run for free, will it still run on NGU'd chroma channel, if the luma channel is not scaled by NGU/already full res native? Does the checkbox "process chroma as well" do anything when the algo tries to run for free?

[Sebastiii]

Wrong thread. This is for MadVR. Not LAVFilters.

From madVR itself and happening on both different player.
But to be sure will switch on EVR to confirm it at 100% :)

[Sebastiii]

Confirmed it comes from madVR and the OSD message in left upper corner is the same font as when changing madVR option from keyboard shorcut, so yes @Clammerz i'm right to asking this here :)

[Sebastiii]

Weird. You should get that message if you use an outdated LAV build (because some older versions produced crashes). But you should not get it with a recent nightly. What exact version number does your "LAVSplitter.ax" file have?

Hi :)
Thanks for the new build will try asap :)
So the version from LAVSplitter is on older one, so you are right, i have installed a tool this week-end that install on older version of LAV suite.
Sorry, that's shame that i didn't look into it myself.

LAVAudio and LAVVideo was the correct version but not LAVSplitter.

[ryrynz]

madVR is displaying it but it's your player providing it as LAV nor MadVR give any prompts to update, so.. not appropriate here. Ideally anything video related should be as up to date as possible anyway.
For those serious about video playback the nightly life is a well tread path. Given the changes in LAV and the time since last release it's probably not far off a "stable" release :p

[LigH]

:thanks: @huhn + @JarrettH (etc.); I joined this topic late, and reading 2440+ pages back will take time.

[madshi]

I don't recall if you answered this already, do you plan moving black bars detection to GPU?
At some point, probably.

it's never free with AA only with soft, standard and sharp.
maybe AA should be renamed so it is not so misleading and unlike the other NGU algorithm quite different.

and it's quite an "issue" for me because i'm generally favouring AA for bad sources that need RCA.
Actually, RCA currently only comes for free when using NGU *Sharp*. It's not yet supported for AA, Soft or Standard. Of course it would be nice to have support for all of them, but it's a LOT of work, so it will take time.

thank you for the answer and the clear explanation (even if i dont yet understand it fully)

i should have been a little more precise in my original wording
- most current tv models with UHD displays using rec.2020 can still not display the full range of this color space ( or the full range of DCI-P3 ), and in their specs this is quantified in a %
- for ex a 2015 higher end samsung UHD tv (model 65JS9500) (using rec.2020) can still only display 91% coverage of DCI-P3 colour gamut
- in comparison, my 1080p sony tv panel (with HD using rec.709) is able to display 94.7% of the DCI-P3 colour space (using the x.v.color setting i presume), and it can accept this signal over HDMI input (and my HTPC can output x.v.color)
- DCI-3 gamut and the x.v.color gamut are VERY similar in size (but use slightly different primaries)

so if i can convert a 4k video (yuv 4.2.0 10 bit) to 4k RGB 4.4.4, and then in the last conversion step (resolution 4k to 2k) i am hoping to maintain as much of the original color information by converting the rec.2020 UHD color gamut % used by the original file, to x.v.color at the highest % my display can cope with (instead of squashing it into rec.709)

i dont really know what Lut's are or how i can use them ( ? look up tables for the RGB primaries used by the display ?), i was hoping the conversion from UHD video to HD (but in x.v.color instead of rec.709 ) could do this in madvr

is there an easy way i can find out my tv model x.v.color primaries, and then create a 3D lut file, and then load it in madvr ? or would it be possible to enter my information directly into madvr maybe
x.v.color is not really supported well on HTPCs (or displays, properly). It's a weird standard, and I have no interest even trying to make it work.

However, if you have a meter, you can switch your TV into the most "native" mode it supports (whichever produces the widest colors/gamut) and then use a 3DLUT to calibrate it for BT.2020 content. Your TV doesn't even know it's receiving BT.2020 data. You should get the max out of your TV that way. Won't be possible without a meter, though. And with a meter you'll have to dive into the depths of calibration software, which can be a little scary sometimes...

To clarify:

When RCA tries to run for free, will it still run on NGU'd chroma channel, if the luma channel is not scaled by NGU/already full res native? Does the checkbox "process chroma as well" do anything when the algo tries to run for free?
Good question. I think it should actually work as you hope it would. You can verify by using an extremely high RCA strength and then check if you see any changes in the chroma channel.

So the version from LAVSplitter is on older one, so you are right, i have installed a tool this week-end that install on older version of LAV suite.
Haha, got ya!

madVR is displaying it but it's your player providing it as LAV nor MadVR give any prompts to update
Actually, this is a rare exception. I've recently added detection for a specific range of old LAV builds, because I regularly received crash reports caused by them. So this specific hint actually comes from madVR. It's not a regular "just so you know, there's a new build available, would you like to update" message. It's just a detection for a specific very old unstable LAV version.

[huhn]

Actually, RCA currently only comes for free when using NGU *Sharp*. It's not yet supported for AA, Soft or Standard. Of course it would be nice to have support for all of them, but it's a LOT of work, so it will take time.

see it's confusing :-)

[madshi]

see it's confusing :-)
Yes, it is. But I can't magically make it work by just changing some code lines quickly. Each RCA strength with each NGU version with each NGU quality level is its own separate algorithm. If you multiply the variants you'll see how crazy much work that is. You can already look at how the madVR.ax file size has increased in recent versions. It's all due to the high number of new algorithms, due to combining NGU Sharp + RCA.

[huhn]

that's not what my point is it's the line "as part of NGU".

changing it to NGU sharp and it may help.

[Axelpowa]

Yes, it is. But I can't magically make it work by just changing some code lines quickly. Each RCA strength with each NGU version with each NGU quality level is its own separate algorithm. If you multiply the variants you'll see how crazy much work that is. You can already look at how the madVR.ax file size has increased in recent versions. It's all due to the high number of new algorithms, due to combining NGU Sharp + RCA.

Hi madshi!

Regarding this topic of ngu sharp + rca, must we check the rca option too?

If I do so the rendering times increase a lot (like 55ms) and the movies in UHD dont play smooth, start dropping a lot of frames.

I use a nvidia gtx 1080.

Regards!

[ryrynz]

Yeah, you should have 'activate only if it comes for free as part of NGU' as well in your case.
Also remember that NGU gets bumped up to high/very high as well that's likely the cause for the render time increases.

[vinnytx]

Is it possible activating a profile with a keyboard shortcut?

[ryrynz]

Yeah it's right under the profile name field once you create one.

[vinnytx]

Thanks!

I use Potplayer. I assigned "-" and "3" but they don't work

[clsid]

You should not use keyboard shortcuts that are already defined in your player.

[Manni]

As far as I can see, at least on my set-up (see sig below), there is no way to get 4K60p and Zoom Control.

If I want Zoom Control, I can't use D3D11 in LAV.

If I want 4K60p (@ RGB 8bits 4:4:4), I have to use D3D11 in LAV, or I get tons of dropped frames. The rendering time is fine, it's far below 16.68ms, it's the queues that are all near empty.

Of course I only have that issue in 4K60p, I can play almost everything else (including 4K23p @ RGB 12bits 4:4:4) without any h/w acceleration.

So unless I'm getting something wrong, it looks like I'll have to use manual zoom control until zoom control is supported with D3D11.

Sharing this in case others are wondering why they are getting loads of frame drops at 4K60p.

[huhn]

which queue isn't filling?
4k60 blackboard detection is quite CPU heavy.

[iSeries]

So unless I'm getting something wrong, it looks like I'll have to use manual zoom control until zoom control is supported with D3D11..

Change the device in LAV filter properties to specify your GPU when using D3D11, this should enable D3D11 copyback (which will make zoom control work)

[ashlar42]

As far as I can see, at least on my set-up (see sig below), there is no way to get 4K60p and Zoom Control.Is it just for testing? What content do you need it for? I'm just curious.
I'm mostly preoccupied with DX11 not allowing hardware interlace, to be honest. Because that pretty much stops me from having a fire&forget setup when I'll move to a 4K display.

[huhn]

it's not like there is anything to miss with hardware deinterlancing. give software deinterlancing a try it so much better with the current drivers.

[ashlar42]

it's not like there is anything to miss with hardware deinterlancing. give software deinterlancing a try it so much better with the current drivers.??? I beg to differ, I've tried both yadif and weston and with 1080i soccer matches the experience was nowhere near hardware deinterlacing.

[Manni]

which queue isn't filling?
4k60 blackboard detection is quite CPU heavy.

All of them. I don't have a problem with zoom control, I have a problem with 4K60p without hardware acceleration.

Change the device in LAV filter properties to specify your GPU when using D3D11, this should enable D3D11 copyback

Will zoom control work with D3D11 copyback? I thought that wasn't recommended anyway (to select a specific device).

Is it just for testing? What content do you need it for? I'm just curious.
I'm mostly preoccupied with DX11 not allowing hardware interlace, to be honest. Because that pretty much stops me from having a fire&forget setup when I'll move to a 4K display.

Billy Lynn is one of the titles in 4K60p, but I do have quite a lot of demo test files in 60p.

Sure I could forget 4K60p more easily than zoom control, but I don't like the idea of having to fumble with settings when playing some files, so as I can use the lens shift memories on my projector to do the zoom control manually, I end up doing that for now. With 4 memories it covers 90% of the needs. Not as good as MadVR's zoom control, but good enough. I have to do that with my other sources anyway, so not a big deal.

[iSeries]

Will zoom control work with D3D11 copyback? I thought that wasn't recommended anyway (to select a specific device)

Yep it's the only way to make zoom control work with D3D11. I use it, works great.