madVR - high quality video renderer (GPU assisted)

[aufkrawall]

Yes in windows 10 i am also not able to enable NNEDI3 in chroma upscaling,madvr instantly crashes so unable to get any OSD details.I have sent the crash report through MADVR application. Also cannot enable chroma or luma doubling,it works in windowed mode and if i do full screen(not exclusive mode) madvr crases.@madashi please look into it.I have reported it many times but nobody has acknowledged it.I am using gtx 980 and on 353.84 driver.:(:(:(:(:(

Plase try e.g. 350.12 driver to see if it really is related to madVR.

[Luv]

Never mind everybody. I figured it out, it was something i hadn't thought about ... i was still running windows classic theme. And that doesnt make the Dx11 path work ;-)

Thanx for the help though everybody.

I'm exactly in the situation you were before.Can you elaborate your solution,please? Thanks.
Ok,found it.Everything is fine now.

[Anime Viewer]

Not sure why the numbers are so bad for you. Is it the same for D3D9 with "use a separate device for presentation" either enabled or disabled?


The numbers I previously reported were with DX11 and use separate device for presentations checked. Here are my numbers with the other settings:

DX9 with use separate checked:
720p native window: 2.51-2.54ms
720p expanded to 1080: 2.67-3.48ms
480p native window 0.98 (very briefly) usually 1.33-1.46ms (reports this driver does not support Overlay when it first opens, but after a few seconds the numbers start).
480p expanded to 1080: 2.55-2.57ms

DX9 with use separate unchecked:
720p native window: 1-.50-1.75ms
720p expanded to 1080: 2.66-3.02ms
480 native window: 1.54-1.61ms (reports this driver does not support Overlay when it first opens, but after a few seconds the numbers start). (Unchecking smooth motion dropped this down to 1.07-1.70ms, , if pausing and unpausing the video it runs at 0.93-1.07ms for a short while.)
480 expanded to 1080: 2.62-2.79ms (2.81-2.98 with smooth motion unchecked).

DX11 with use separate unchecked:
720p native window: 3.38-3.44ms
720p expanded to 1080: 3.12-3.88ms
480 native: 2.23ms
480 expanded to 1080: 7.29-7.84m


Kind of weird results. DX9 seems to give slightly better numbers. Having use separate device checked seems to work better than unchecked for 480 content, but the opposite seems to hold true for 720p content. However none of these numbers may be significant enough to amount to anything.

[Shiandow]

I think tearing is not caused by the display, but it's caused by the GPU. These days we have digital connection via DVI or HDMI. And this connection works by sending full frames to the display. The display then receives these frames and displays them one by one. Whether the display internally draws the frames line by line or not doesn't really matter. We can treat the display as a black box. It shouldn't matter to us what the display does, as long as it does its job reasonably well.


Maybe I misunderstood, but I really don't see why the GPU would cause "tearing". Both DDR5 and HDMI should be more than fast enough to change the entire image in one go, so if it's not the display where else would you change the image line by line? In fact here (https://youtu.be/hD5gjAs1A2s?t=19) is a video showing in slow-motion how (most) LCD screens are drawn. The drawing is clearly not instantaneous, in fact it's only just done drawing a frame until it starts the next.

Anyway, I got the impression that you tried to use really exact timing to get the blending factors just right, so I wondered if you took into account that displaying the frame will take quite a long time.

[e-t172]

Maybe I misunderstood, but I really don't see why the GPU would cause "tearing".

It's not the GPU per se that causes tearing, it's how the software (application and OS) uses it. Tearing is caused by altering the GPU front framebuffer while it's being sent to the display. To prevent tearing, one must only change the framebuffer during the VSync interval, which is small compared to the interval in which frames are sent to the display. The easiest way to implement this is to "prepare" the new frame in some other buffer (typically called the back buffer, as opposed to the front buffer), and then when VSync occurs, quickly "swap" the two buffers in one fell swoop. This is called double buffering (https://en.wikipedia.org/wiki/Multiple_buffering#Double_buffering_in_computer_graphics).

It's the responsibility of the software to implement double buffering, so technically, madshi is wrong when he says that "it's caused by the GPU", though I'm sure that's what he meant by that. The problem with double buffering is that when you finished drawing a frame in the back buffer you then have to wait for the next VSync interval before you can swap it to the front buffer, which adds latency. The latency is problematic for games, but not for video, since the frames are prepared in advance anyway. Freesync/GSync removes this latency by allowing software to trigger VSync has soon as the frame is drawn, as opposed to waiting for the next interval.

[Asmodian]

Kind of weird results. DX9 seems to give slightly better numbers. Having use separate device checked seems to work better than unchecked for 480 content, but the opposite seems to hold true for 720p content. However none of these numbers may be significant enough to amount to anything.

I have noticed that Optimus (dual GPU) systems seem to have higher present times, I am not sure this is a sign of an issue beyond the driver oddities that these systems continue to have. Is it due to the memory copy from the Nvidia GPU to the Intel GPU that must happen before the frame can be sent to the display?

[cyberscott]

That is a bit surprising. How are you rendering times with v0.88.8 and v0.88.10? Do they differ noticeably? Could it be that for some reason v0.88.10 is simply slower for you, so that rendering doesn't keep up with your scaling configuration? Which queues are full and which are empty?

Using DX11 exclusive 10 bit triggers the queue trouble on 88.10, even after a fresh install and using just the default settings.

In 88.8, all queues fill up.
In 88.10, the render queue stays at 3-6/14 and the present queue stay at 1-5/14. Also, the decoder queue always shows one more that it should such as 23-25/24.
I've reduced the queues down to 5 and 8 with no change in the render and present queue fill.
Here is a comparison, running a 1080p video up-scaled to 2160p of the OSD while running the same video clip in each version of madVR. Was using chroma> Jinc3 AR, Luma >Nnedi64, chroma.Lanczos3 AR for both versions. Again, even at default madVR settings with DX11 exclusive mode (10 bit) the queue issue remains the same for me.

In 88.10
decoder queue 47-49/48
upload queue 11-14 /14
render queue 3-6 /14
present queue 1-5 /14
average stats:
rendering 23.78ms
present 0.06ms
present stats (5s)
rendering 38.35ms
present 0.14ms
--
in 88.8
decoder queue 47-48/48
upload queue 13-14 /14
render queue 12-13 /14
present queue 12-13 /14
average stats:
rendering 25.42
Present 1.33
Max stats (5s)
rendering 78.73ms
present 0.23
.

[kasper93]

@madshi: In D3D11 exclusive mode if something in background tries to steal focus. Screen goes dark and need to exit exclusive mode to restore. No such behavior in D3D9.

[FireFreak111]

For the NNEDI3 behaviour, I remember it occurring when WDDM 2.0 was still really unstable and I was using WDDM 1.3 drivers. It seems to be limited to Win 10. GTX 660.

Are there any plans to allow NEDI for Chroma Upscaling? It would be a high performance alternative to NNEDI3.

@madshi: In D3D11 exclusive mode if something in background tries to steal focus. Screen goes dark and need to exit exclusive mode to restore. No such behavior in D3D9.
Can verify this behaviour. Frustrating on multi-monitor, as if you try to snap something to the edge of the screen with the video next to it, it looses focus, and you have to exit and reenter exclusive mode to restore the video.

[QBhd]

I'm pretty sure this is the same problem I have as well. Pausing in PotPlayer some how steals focus and the only way to recover smooth playback is to close the file and open it again.

[Asmodian]

Are there any plans to allow NEDI for Chroma Upscaling? It would be a high performance alternative to NNEDI3.

I doubt it. NEDI must run on both luma and chroma at the same time. You can tell when you enable it for image doubling; it is forced for both luma and chroma.

[luk008]

Is there any advantage of D3D11 besides 10 bit output?

[Asmodian]

Is there any advantage of D3D11 besides 10 bit output?

I notice it is more responsive when changing window sizes and switching into FSE. The penalty for having SLI enabled is also lower. This seems to be very system dependent though.

[FireFreak111]

I doubt it. NEDI must run on both luma and chroma at the same time. You can tell when you enable it for image doubling; it is forced for both luma and chroma.

Back when NEDI was still a MPC-HC shader, there was a Chroma only version. I remember using it. It would likely be higher quality within the madVR pipeline.

[Sunset1982]

I#m only watching 1080p movies and I want to upscale them to 4K.

What settings should I use to upscale to 4K form 1080p in Madvr and what hardware do I need?

Currently I have an AMD R270 working with an Intel i5 on my old 1080p Display.

[Milez7494]

I've been lurking on this thread for a while wanting to post but I've had to wait for the two day waiting period to expire before I could.

I was wondering if there is another place where I can find the latest releases of MadVR? Coming back to this thread every week and trawling through the replies looking for Madshi's MadVR update posts get's kinda annoying.

I've looked on Madshi's website but I can't seem to find anything related to MadVR on there.

An RSS option would be ideal, honestly.

[nevcairiel]

The newest version is always in the first post of this thread.

[vivan]

There's videohelp link (http://www.videohelp.com/software/madVR) in the first post. They don't seem to have tool-specific RSS (only RSS for all tools, maybe you can filter it in your RSS reader), but they have email notifications.

[iSunrise]

I#m only watching 1080p movies and I want to upscale them to 4K.

What settings should I use to upscale to 4K form 1080p in Madvr and what hardware do I need?

Currently I have an AMD R270 working with an Intel i5 on my old 1080p Display.
That doesn't make any sense at all. Why would you want to upscale 1080p content to 4K, when you have a 1080p display?

[mindz]

Hi madshi,

I think it would be clearer for users to auto set chroma upscaling to DXVA when image is DXVA (make all options ready only). Right now users are finding out via the 'new' OSD, whereas i always thought i was using Jinc 3 AR for chroma.

[x7007]

Do you have an NVidia GPU? Then double check that the setting "max prerendered frames" (or something like that) is set to application control.



Thank you !! it works now great with 22 ms in 10bit FSE

No stutter , still must Present for every sync or else there are presentation errors.

[madshi]

AFAIK it applies for 8bit too, people have reported a significantly better PQ on AMD cards when using icc profiles because of that (with nvidia you get noticeable banding with icc profiles).
Ah ok, dithering does make sense with 8bit output if an ICC profile is used, of course. However, it doesn't make too much sense if no ICC profile is used. And if AMD uses ordered dithering (which I would expect) I don't understand why it would increase the noise if no ICC profile is used, because ordered dithering should not produce any dithering patterns if the output is clean rounded 8bit to begin with. Anyway, who knows what the driver does. It's good to have an option to disable that driver dithering.

Yes in windows 10 i am also not able to enable NNEDI3 in chroma upscaling,madvr instantly crashes so unable to get any OSD details.I have sent the crash report through MADVR application. Also cannot enable chroma or luma doubling,it works in windowed mode and if i do full screen(not exclusive mode) madvr crases.@madashi please look into it.I have reported it many times but nobody has acknowledged it.I am using gtx 980 and on 353.84 driver.:(:(:(:(:(
Probably a driver issue, I can only guess... :(

The numbers I previously reported were with DX11 and use separate device for presentations checked. Here are my numbers with the other settings:

DX9 with use separate checked:
720p native window: 2.51-2.54ms
720p expanded to 1080: 2.67-3.48ms
480p native window 0.98 (very briefly) usually 1.33-1.46ms (reports this driver does not support Overlay when it first opens, but after a few seconds the numbers start).
480p expanded to 1080: 2.55-2.57ms

DX9 with use separate unchecked:
720p native window: 1-.50-1.75ms
720p expanded to 1080: 2.66-3.02ms
480 native window: 1.54-1.61ms (reports this driver does not support Overlay when it first opens, but after a few seconds the numbers start). (Unchecking smooth motion dropped this down to 1.07-1.70ms, , if pausing and unpausing the video it runs at 0.93-1.07ms for a short while.)
480 expanded to 1080: 2.62-2.79ms (2.81-2.98 with smooth motion unchecked).

DX11 with use separate unchecked:
720p native window: 3.38-3.44ms
720p expanded to 1080: 3.12-3.88ms
480 native: 2.23ms
480 expanded to 1080: 7.29-7.84m

Kind of weird results. DX9 seems to give slightly better numbers. Having use separate device checked seems to work better than unchecked for 480 content, but the opposite seems to hold true for 720p content. However none of these numbers may be significant enough to amount to anything.
I have noticed that Optimus (dual GPU) systems seem to have higher present times, I am not sure this is a sign of an issue beyond the driver oddities that these systems continue to have. Is it due to the memory copy from the Nvidia GPU to the Intel GPU that must happen before the frame can be sent to the display?
Is that Optimus, Anime Viewer? That might explain the high present times. And those numbers are *average* numbers, not max, right? My numbers are 0.12ms for DX11 and 0.07ms for DX9, on Windows 8.1 with "use a separate device for presentation" activated, both in windowed and FSE mode, with my AMD HD7770 GPU. Maybe the OS also plays a role? Windows 8.1 does work better than Windows 7 for video rendering.

Anyway, I got the impression that you tried to use really exact timing to get the blending factors just right, so I wondered if you took into account that displaying the frame will take quite a long time.
It's very true that different displays have a different latency (delay from receiving a frame to actually displaying it). But this is something that only affects the audio/video sync, and usually users fix that by applying an audio sync correction in the HTPC or receiver. How much latency the displays has, doesn't really effect the smoothness of the video playback, because the display latency is the same for every video frame. The latency just causes an AV sync mismatch.

The reason madVR measures the VSync position for blending factors does not have anything to do with tearing. Actually I could add any random (but constant!) offset to the measured VSync position, and it wouldn't cause motion smoothness to be harmed. E.g. if I added a 0.5 frame offset to the measured VSync position, this would cause the blending factors to change accordingly, and the net result would be an audio/video sync mismatch of 0.5 frames, but motion smoothness would still be the same. The reason madVR measured the VSync position is that only this way the blending factors adjust perfectly to the output refresh rate, so that I never ever have to drop or repeat a video frame.

It's complicated, but I hope my explanation is understandable?

Using DX11 exclusive 10 bit triggers the queue trouble on 88.10, even after a fresh install and using just the default settings.

In 88.8, all queues fill up.
In 88.10, the render queue stays at 3-6/14 and the present queue stay at 1-5/14. Also, the decoder queue always shows one more that it should such as 23-25/24.
I've reduced the queues down to 5 and 8 with no change in the render and present queue fill.
Here is a comparison, running a 1080p video up-scaled to 2160p of the OSD while running the same video clip in each version of madVR. Was using chroma> Jinc3 AR, Luma >Nnedi64, chroma.Lanczos3 AR for both versions. Again, even at default madVR settings with DX11 exclusive mode (10 bit) the queue issue remains the same for me.

In 88.10
decoder queue 47-49/48
upload queue 11-14 /14
render queue 3-6 /14
present queue 1-5 /14
average stats:
rendering 23.78ms
present 0.06ms
present stats (5s)
rendering 38.35ms
present 0.14ms
--
in 88.8
decoder queue 47-48/48
upload queue 13-14 /14
render queue 12-13 /14
present queue 12-13 /14
average stats:
rendering 25.42
Present 1.33
Max stats (5s)
rendering 78.73ms
present 0.23
.
That's strange. The stats actually look better for v0.88.10, so I really wonder why the queues don't fill. What happens if you dumb down the settings, by using very cheap scaling algorithms (e.g. even Bilinear everywhere), no error diffusion or anything else expensive? Do the queues fill then? Or do they still stay empty?

@madshi: In D3D11 exclusive mode if something in background tries to steal focus. Screen goes dark and need to exit exclusive mode to restore. No such behavior in D3D9.
Ok, I've reproduced the issue, and it seems that D3D11 FSE mode is much more sensitive to other windows being on the same screen. For some reason, the D3D11 "Present" call just fails in that situation. So the next madVR build will exit FSE mode if the "Present" call fails. That "solves" the issue for me. However, after 3 seconds madVR will try to re-enter FSE mode. And if the other window is still on the FSE monitor, entering FSE mode will fail. So this could end up disabling FSE mode until you reload the video. Probably not much I can do about it. But at least the black screen should be gone in the next build.

I think it would be clearer for users to auto set chroma upscaling to DXVA when image is DXVA (make all options ready only). Right now users are finding out via the 'new' OSD, whereas i always thought i was using Jinc 3 AR for chroma.
Probably you're right, but it's too much work just to make things clearer at this time. Maybe some time in the future.

[madshi]

Let me sum up some possible DX11 related problems and potential solutions, because these seem to come up quite a lot:

Direct3D11 mode is not used, although the option is activated.

Potential fix 1: You're on Windows 7 and you have Aero/DWM deactivated. In this situation D3D11 mode cannot be used - it needs Aero/DWM to be active.

Potential fix 2: You're on Windows 7 and don't have the Windows 7 Platform Update installed (which is an optional update). This update is needed for Windows 7 to use madVR's D3D11 mode.

Render queue doesn't fill in Direct3D11 mode and/or you have unusually high rendering or presentation times (see OSD, Ctrl+J).

Potential fix 1: In the NVidia GPU control panel make sure that "Maximum pre-rendered frames" is set to application controlled.

Potential fix 2: Try lowering the madVR option(s) "how many video frames shall be presented in advance" to 8 (which is the default setting) or even lower. Some GPU drivers can't handle this being set to a high value.

Direct3D11 mode produces tons of presentation glitches.

Potential fix 1: Try activating the madVR option "present a frame for every VSync" (which is the default setting).

[har3inger]

I'm not sure if this counts under your first listed problem, but:

DX11, when toggled, causes black screen and no OSD to render. Audio plays normally and the seek bar works. So, can't strictly tell if it's being used or not, but ticking the box is clearly breaking something. So far has affected only me and one other poster from earlier. Both of us appear to use ATI mobile GPUs paired to intel GPUs in a switchable configuration. Both of us also get the exact same problem when we try to "use separate device for presentation". For what it's worth, the black screen is the right size for the video in windowed mode (1280x720 of solid black). (Win 8.1, x64 madvr)

[Anime Viewer]

Is that Optimus, Anime Viewer? That might explain the high present times. And those numbers are *average* numbers, not max, right? My numbers are 0.12ms for DX11 and 0.07ms for DX9, on Windows 8.1 with "use a separate device for presentation" activated, both in windowed and FSE mode, with my AMD HD7770 GPU. Maybe the OS also plays a role? Windows 8.1 does work better than Windows 7 for video rendering.



Yes, that is Optimus using the Nvidia GPU. When I have it use the Intel GPU it reports 0.16-0.17ms (with both presentation checked and unchecked) in the native windows for both 480 and 720 content. I'm not too concerned about the Nvidia numbers since I don't think those present times are causing any problems in video playback. On that note: What would be signs of problematic or too high present times? If I were to speculate very high present times would make render times higher, is that true or false? What would be too high times for proper playback? Would a value higher than vsync interval be the point at which it would be problematic?

As a test I tried setting the Global Setting in Nvidia control panel to Nvidia instead of auto-select, and for the 480 content expanded to full screen it dropped the present times down by 0.63 from 3.17 to , so to 2.5ish. Therefore there may be some other executable file that the video goes between (that slows it down slightly and flips between the GPUs) on its way from the Nvidia gpu to Intel gpu before being displayed, but its still probably not enough to be of significance.

[Soukyuu]

I just had the chance to try madvr with a 23.97fps anime episode on a 23.97Hz TV, and I actually prefer the picture @60Hz+smooth motion. 23.97Hz just seems to stutter.
Any idea why that might be? It's a Samsung series 4 plasma TV.

[Sunset1982]

That doesn't make any sense at all. Why would you want to upscale 1080p content to 4K, when you have a 1080p display?

Thats my current display, but I want to upgrade in the next weeks.

[huhn]

I just had the chance to try madvr with a 23.97fps anime episode on a 23.97Hz TV, and I actually prefer the picture @60Hz+smooth motion. 23.97Hz just seems to stutter.
Any idea why that might be? It's a Samsung series 4 plasma TV.

there a a lot of samsung screen out there that display 23/24p hz input as 59/60p some of them have an option called something like "true cinema" not frame interpolation some can't display smooth 23/24p.

here a new display with a price about 800-3500 that can't do 23/24p smooth AT ALL: http://www.rtings.com/reviews/tv/lcd-led/samsung/ju6500

This TV does not display 24p properly, even though it accepts it as an input. You can see judder when watching movies.

[XMonarchY]

Here my finding on medium/low-quality 720p SMPTE 170M content (600MB file, 45 minutes long):
1. Shiandow's default debanding settings (w/ add grain) + madVR's debanding (medium on top, high on bottom) = much detail seems lost in dark/black areas
2. Shiandow's default debanding settings (w/ add grain) + madVR's debanding (low on top, medium on bottom) = most detail seems preserved, banding seems minimal
*3. Shiandow's debanding is disabled + madVR's debanding (medium on top, high on bottom) = most detail seems preserved, but banding seems more obvious than in #2
4. Shiandow's debanding is disabled + madVR's debanding (low on top, medium on bottom) = most detail seems preserved, but banding seems even more obvious than in #3
* - these settings were advised by madshi for low/medium-quality content before Shiandow's debanding was integrate into madVR
Conclusion = Shiandow's debanding (in my case) works well on medium/low-quality 720p content when madVR's debanding is set to low on top and medium on bottom


Question about Error Upscaling Quality in Image Refinement. I assume using High setting provides the highest quality? The idea of "Error Quality" confuses me because to me it sounds like High quality error = a seriously bad error! Its like saying High Quality Virus, which is not a good thing!

[madshi]

Here my finding on medium/low-quality 720p SMPTE 170M content (600MB file, 45 minutes long):
1. Shiandow's default debanding settings (w/ add grain) + madVR's debanding (medium on top, high on bottom) = much detail seems lost in dark/black areas
2. Shiandow's default debanding settings (w/ add grain) + madVR's debanding (low on top, medium on bottom) = most detail seems preserved, banding seems minimal
*3. Shiandow's debanding is disabled + madVR's debanding (medium on top, high on bottom) = most detail seems preserved, but banding seems more obvious than in #2
4. Shiandow's debanding is disabled + madVR's debanding (low on top, medium on bottom) = most detail seems preserved, but banding seems even more obvious than in #3
* - these settings were advised by madshi for low/medium-quality content before Shiandow's debanding was integrate into madVR
Conclusion = Shiandow's debanding (in my case) works well on medium/low-quality 720p content when madVR's debanding is set to low on top and medium on bottom
Running both algorithms at the same time means double the performance cost. It'd be better to only use one. So if you compare Shiandow's deband vs. madVR's original deband, which do you prefer? When comparing, please try to setup both algorithms so that they have a similar debanding strength, or a similar detail retention.

Question about Error Upscaling Quality in Image Refinement. I assume using High setting provides the highest quality? The idea of "Error Quality" confuses me because to me it sounds like High quality error = a seriously bad error! Its like saying High Quality Virus, which is not a good thing!
All these settings will be replaced with "low/medium/high" sooner or later, so don't worry about the option names too much right now. "High" setting produces better quality, but the quality difference is probably not very big. But we're not really discussing SuperRes yet, we're still concentrated on debanding right now.

[Della]

Do you have an NVidia GPU? Then double check that the setting "max prerendered frames" (or something like that) is set to application control.

Thank you !! it works now great with 22 ms in 10bit FSE

No stutter , still must Present for every sync or else there are presentation errors.

Searched everywhere in the CP. Could someone point me to this setting?
Thanks.

[cyberscott]

That's strange. The stats actually look better for v0.88.10, so I really wonder why the queues don't fill. What happens if you dumb down the settings, by using very cheap scaling algorithms (e.g. even Bilinear everywhere), no error diffusion or anything else expensive? Do the queues fill then? Or do they still stay empty?


Starting with default settings on madVR 88.10, I set everything to Bilenear, no error diffusion, tried "present a frame for every VSync" both enabled and disabled. The stuck queue behavior remained in DX11 exclusive mode (10 bit) but I got great render times with those settings. :p

This issue for me started with 88.9. I might be rarity here as I actually have a display that can do 10 bit at 4k 30Hz and below and I do notice a slight improvement in picture quality when using 10 bit source material in 10 bit mode.

*OK, found something interesting. I've been up-scaling to my TV's native resolution 3840x2160pXX with madVR. If I set madVR matching display modes to do 1080pXX, the queue problem goes away and returns if I go back to 3840x2160pXX
So, it appears that 88.10 render queues doesn't like me up-scaling to 3840x2160pXX in DX11 Exclusive Mode (10 bit) but is fine with 1080p. This behavior doesn't happen with 88.8.

[XMonarchY]

Running both algorithms at the same time means double the performance cost. It'd be better to only use one. So if you compare Shiandow's deband vs. madVR's original deband, which do you prefer? When comparing, please try to setup both algorithms so that they have a similar debanding strength, or a similar detail retention.


All these settings will be replaced with "low/medium/high" sooner or later, so don't worry about the option names too much right now. "High" setting produces better quality, but the quality difference is probably not very big. But we're not really discussing SuperRes yet, we're still concentrated on debanding right now.

You mean I should tweak settings to make madVR's debanding produce the same effect as Shiandow's debanding? If that is possible, then how can you choose one if both produce the same results...


I had a small side-question. If I want to create a 3DLUT with 12bit depth setting selected in nVidia CP, should I use 10bit setting in madVR for madTPG pattern generator? I can't get a straight answer (or missed it?) whether 3DLUT made with 8bit depth setting (in both nVidia CP and madVR) would perform the same as 3DLUT made with 12bit depth setting in nVidia CP and 10bit setting in madVR..? I assume ArgyllCMS would still use only 256 levels for measurements to create a 3DLUT, which means that 8bit and 12bit depth 3DLUT's would perform the same.., no?

[madshi]

Searched everywhere in the CP. Could someone point me to this setting?
http://en.community.dell.com/cfs-filesystemfile/__key/CommunityServer.Components.ImageFileViewer/CommunityServer.Discussions.Components.Files.3339/6470.2010_2D00_04_2D00_29_5F00_012256.png_2D00_550x0.png

Starting with default settings on madVR 88.10, I set everything to Bilenear, no error diffusion, tried "present a frame for every VSync" both enabled and disabled. The stuck queue behavior remained in DX11 exclusive mode (10 bit) but I got great render times with those settings. :p

This issue for me started with 88.9. I might be rarity here as I actually have a display that can do 10 bit at 4k 30Hz and below and I do notice a slight improvement in picture quality when using 10 bit source material in 10 bit mode.

*OK, found something interesting. I've been up-scaling to my TV's native resolution 3840x2160pXX with madVR. If I set madVR matching display modes to do 1080pXX, the queue problem goes away and returns if I go back to 3840x2160pXX
So, it appears that 88.10 render queues doesn't like me up-scaling to 3840x2160pXX in DX11 Exclusive Mode (10 bit) but is fine with 1080p. This behavior doesn't happen with 88.8.
Is the display mode / refresh rate the same with v0.88.8 and v0.88.9/10? I've changed some things in the display mode changer for DX11 in v0.88.9.

Could you please create a debug log for me with v0.88.10, with all scaling algorithms set to Bilinear, so you get those great render times, but still the stuck queues? That might help me figuring out why the queues get stuck...

You mean I should tweak settings to make madVR's debanding produce the same effect as Shiandow's debanding? If that is possible, then how can you choose one if both produce the same results...
You could try which madVR setting gets nearest to Shiandow's default parameters. Or you could go the other way round, pick a madVR preset you like and then try to match Shiandow's algorithm to that. Obviously, if you want to compare the quality of madVR's debanding vs. Shiandow's algorithm, it would make sense to try to set them to a similar debanding strength. Because if you don't do that, one algorithm will win in debanding strength and the other will win in detail retention, which tells us nothing. Only if you set them both to the same debanding strength you can compare which retains details better at that setting. Or if you set them to the same detail retention level, you can compare which debands better at that setting. How else would you be able to tell which algorithm is better than the other?

I had a small side-question. If I want to create a 3DLUT with 12bit depth setting selected in nVidia CP, should I use 10bit setting in madVR for madTPG pattern generator? I can't get a straight answer (or missed it?) whether 3DLUT made with 8bit depth setting (in both nVidia CP and madVR) would perform the same as 3DLUT made with 12bit depth setting in nVidia CP and 10bit setting in madVR..? I assume ArgyllCMS would still use only 256 levels for measurements to create a 3DLUT, which means that 8bit and 12bit depth 3DLUT's would perform the same.., no?
For calibration related questions better ask here:

http://www.avsforum.com/forum/showthread2.php?t=1471169

[James Freeman]

I find Shiandows 0.80, 0.0, Grain On; vs High, identical in terms of detail loss and shape retention.

IMO, They are so close, any one of them will do perfectly.
As the old saying goes, if it's working don't touch it.

On the worst banded content like 720p (600-1000Mb) "Internet" downloads; The debanding algo's are just a savior.
They make the image at least as good as three times the file size or more.

[Ver Greeneyes]

On the worst banded content like 720p (600-1000Mb) "Internet" downloads; The debanding algo's are just a savior.
They make the image at least as good as three times the file size or more.Are we talking about debanding or deblocking at that point? I don't mind if they do both, but as I understand it deblocking is more of an unintended side effect.

[James Freeman]

Are we talking about debanding or deblocking at that point? I don't mind if they do both, but as I understand it deblocking is more of an unintended side effect.

I'm talking about debanding.
It also deblocks if the blocking is part of a banding, though we should not look upon this side effect as "lucky deblocking".
Proper deblocking may or may not come in the future... I don't know.

I'm very happy with what madVR debanding can do, that I don't feel the need to fine tune it in any way (nitpicking at this point for me).
In the end it is what madshi is striving for, a simple three way toggle switch which fulfills everyones needs with various size video content.

[Della]

[QUOTE=madshi;1724721]http://en.community.dell.com/cfs-filesystemfile/__key/CommunityServer.Components.ImageFileViewer/CommunityServer.Discussions.Components.Files.3339/6470.2010_2D00_04_2D00_29_5F00_012256.png_2D00_550x0.png

Thank you.

[Ver Greeneyes]

I'm talking about debanding.OK, just making sure :) I just imagine highly compressed content will have more problems with blocking than banding is all.

[Della]

Starting with default settings on madVR 88.10, I set everything to Bilenear, no error diffusion, tried "present a frame for every VSync" both enabled and disabled. The stuck queue behavior remained in DX11 exclusive mode (10 bit) but I got great render times with those settings. :p

This issue for me started with 88.9. I might be rarity here as I actually have a display that can do 10 bit at 4k 30Hz and below and I do notice a slight improvement in picture quality when using 10 bit source material in 10 bit mode.

*OK, found something interesting. I've been up-scaling to my TV's native resolution 3840x2160pXX with madVR. If I set madVR matching display modes to do 1080pXX, the queue problem goes away and returns if I go back to 3840x2160pXX
So, it appears that 88.10 render queues doesn't like me up-scaling to 3840x2160pXX in DX11 Exclusive Mode (10 bit) but is fine with 1080p. This behavior doesn't happen with 88.8.

Same here, Samsung 8550. 2160pAnything

[cyberscott]

Is the display mode / refresh rate the same with v0.88.8 and v0.88.9/10? I've changed some things in the display mode changer for DX11 in v0.88.9.

Could you please create a debug log for me with v0.88.10, with all scaling algorithms set to Bilinear, so you get those great render times, but still the stuck queues? That might help me figuring out why the queues get stuck...


My TV can do 23, 24, 25, 29, 30, 50, 59 and 60Hz at 1080p and at 2160p. I always had madVR up-scale to 2160p to match my TV native resolution and match the refresh rate of the content I'm watching. I've noticed no difference in the displayed refresh rate in the OSD.

Here is the debug log for 0.88.10. :)

[madshi]

Attaching to this forum can sometimes take a lot of time to approve. It's better to upload elsewhere. E.g. try tinyupload.com.

[vivan]

On debanding:
"Add grain". It adds grain, yes, but it's 10x stronger than madVRs/f3kdb's and I don't really feel it being useful. In some cases it even makes an opposite effect and makes banding more visible.
Overall I still strongly prefer madVR debanding over Shiandow's (on anime sources).

[cyberscott]

Attaching to this forum can sometimes take a lot of time to approve. It's better to upload elsewhere. E.g. try tinyupload.com.
Thanks for the tip. Here you go!
http://s000.tinyupload.com/?file_id=08517668317971035278

[madshi]

Thanks. There are some things that seem weird in the log. It's a bit short, though, to fully judge what's happening. Could you create one with 30 seconds worth of playback? Thanks!

[cyberscott]

Thanks. There are some things that seem weird in the log. It's a bit short, though, to fully judge what's happening. Could you create one with 30 seconds worth of playback? Thanks!
Here you go, this one should give you about a minute of info.
http://s000.tinyupload.com/?file_id=59839907807754082927

[leeperry]

All these settings will be replaced with "low/medium/high" sooner or later, so don't worry about the option names too much right now.
IME finetuning the SR sharpness figure is extremely subjective as the ideal value to the viewer will depend on his personal taste, display processing, viewing distance, anti-glare layers graininess, source file, mVR settings and so on :scared:

Having to use a sharpener filter on top of it sounds like a major waste of resources and nowhere near as versatile and powerful as SR :o

If an expert/simple settings checkbox ever made any sense to you, it would especially fit SR IMHO.

[Soukyuu]

there a a lot of samsung screen out there that display 23/24p hz input as 59/60p some of them have an option called something like "true cinema" not frame interpolation some can't display smooth 23/24p.

here a new display with a price about 800-3500 that can't do 23/24p smooth AT ALL: http://www.rtings.com/reviews/tv/lcd-led/samsung/ju6500
It might be that, thanks. The TV also apparently has a native resolution of 1024x768... on a 16:9 screen. *strikes Samsung from a list of possible "to buy" TVs*

[madshi]

Here you go, this one should give you about a minute of info.
http://s000.tinyupload.com/?file_id=59839907807754082927
Does this (32bit only) test build change anything?

http://madshi.net/madVR8810test.rar

[huhn]

It might be that, thanks. The TV also apparently has a native resolution of 1024x768... on a 16:9 screen. *strikes Samsung from a list of possible "to buy" TVs*

haha don't worry most better samsung can do that X-) and there are other companies that do stuff like this too. it's just very easy to find an test of an samsung TV that clearly says this.