madVR - high quality video renderer (GPU assisted)

[leeperry]

Originally Posted by madshi

Results?

I can't get 0.32 to lock up anymore(and I tried really hard ), I guess it was a PotPlayer problem indeed.

Originally Posted by madshi

Careful, it's easy to confuse people. YUY2 is 16-bit per pixel, YV12 is 12-bit per pixel. That's all correct. However, dithering is done to 8bit *per component* RGB. Without saying that it's "per component" people might think that YV12 has a higher bitdepth than madVR's output. So:

YV12: 12bit per pixel (native DVD/Blu-Ray/broadcast format)
YUY2: 16bit per pixel
madVR math: 96bit+ (floating point) per pixel
madVR buffers: 48bit (integer) per pixel
madVR output: dithered 24bit (integer) per pixel

Yep, the TMDS transmitter that encodes to DVI/HDMI <1.3 outputs RGB24 anyway.

Originally Posted by madshi

I've no idea, ask the Reclock programmer...

It was a mix up w/ an EVR screenshot, Reclock doesn't say YUY2 when using mVR...for very obvious reasons

[janos666]

Originally Posted by madshi

Does anybody have a Radeon 6xxx card? Could you please check if the latest PowerStrip version fully supports it?

I don't think it works.
I have a HD5850. It wasn't supported until the last PowerStrip release but this latest version doesn't seem to work neither. I tried to force some custom refresh rates but nothing happened.
May be it works with older drivers (<10.12) or other outputs (I am using DP right now).

[121sea]

YV12: 12bit per pixel (native DVD/Blu-Ray/broadcast format)
YUY2: 16bit per pixel
madVR math: 96bit+ (floating point) per pixel
madVR buffers: 48bit (integer) per pixel
madVR output: dithered 24bit (integer) per pixel

If you increase madvr's bit per pixel(double it for example) will that result in a visible improvement in video quality or is that a waste of computer resources?

[trainspotter]

Originally Posted by madshi

Hmmmm... Does it help if you disable the exclusive mode?

Another thing worth trying would be to use a lower refresh rate, just a test, only, of course.

In order to edit the madVR settings I have to wait for the timeout / D3D error. Any settings I make once that timeout has occurred, only seem to be saved for the session - after restarting and waiting for the timeout to edit again, the defaults are back.

Does madVR still save its settings to an ini file, so I could manipulate that file manually? Or is there any other possibility to get to the config editor without having to run madVR first?

Same behavior (as I described in my initial post) with a lower refresh rate (60hz) on a single monitor setup.
Would logs of these tests be of any use to you?


€dit: Strange observation - I am getting more and more confused by the minute..
If I wait for the timeout / D3D error and try to play the same file with the already opened mpc-hc, all madVR features (including exclusive mode) seem to be working.
Any other file opened in that instance of mpc-hc afterward works flawlessly.

I have created a log of that test. This time I did not get the D3D error but the movie started playing right away after said timeout.
Please let me know if there is anything else I could do to help debugging.

[madshi]

Originally Posted by leeperry

I can't get 0.32 to lock up anymore(and I tried really hard ), I guess it was a PotPlayer problem indeed.

It was a mix up w/ an EVR screenshot, Reclock doesn't say YUY2 when using mVR...for very obvious reasons

Good, two problems less I need to look into.

Originally Posted by janos666

I don't think it works.
I have a HD5850. It wasn't supported until the last PowerStrip release but this latest version doesn't seem to work neither. I tried to force some custom refresh rates but nothing happened.
May be it works with older drivers (<10.12) or other outputs (I am using DP right now).

Too bad...

Originally Posted by 121sea

If you increase madvr's bit per pixel(double it for example) will that result in a visible improvement in video quality or is that a waste of computer resources?

Which bitdepth? The output bitdepth? You mean from 24bit per pixel up to e.g. 48bit per pixel? As I said earlier, increasing the output bitdepth will lower the dithering noise floor. Apart from there there should be no change. If you don't notice the dithering noise with the current madVR 24bit output, then any higher output bitdepth will likely not bring any visible improvements for you.

Originally Posted by trainspotter

€dit: Strange observation - I am getting more and more confused by the minute..
If I wait for the timeout / D3D error and try to play the same file with the already opened mpc-hc, all madVR features (including exclusive mode) seem to be working.
Any other file opened in that instance of mpc-hc afterward works flawlessly.

I have created a log of that test. This time I did not get the D3D error but the movie started playing right away after said timeout.
Please let me know if there is anything else I could do to help debugging.

Hmmmm... According to the log the timeout occurs during one of the following actions (not sure which):

(1) loading of "madHcNet.dll"
(2) enumeration of monitors
(3) initialization of madHcNet network
(4) start of "madHcCtrl.exe"

One thing you could try is to start madHcCtrl.exe manually. Wait until the madVR tray icon is visible (in case you haven't disabled it). Then start madVR. Does the timeout still occur? If yes, the problem is likely not (4). Otherwise it's probably (4). Also try disabling your firewall as a quick test.

It the problem is (2) or (3), it might be difficult to find the real cause for the timeout. Because no other user seems to have this problem, I fear it might be some kind of OS problem, which may only be cured by reinstalling the OS. Hopefully not.

[121sea]

Which bitdepth? The output bitdepth? You mean from 24bit per pixel up to e.g. 48bit per pixel? As I said earlier, increasing the output bitdepth will lower the dithering noise floor. Apart from there there should be no change. If you don't notice the dithering noise with the current madVR 24bit output, then any higher output bitdepth will likely not bring any visible improvements for you.

the math bitdepth if that's even posible whit current video cards

[trainspotter]

Originally Posted by madshi

Hmmmm... According to the log the timeout occurs during one of the following actions (not sure which):

(1) loading of "madHcNet.dll"
(2) enumeration of monitors
(3) initialization of madHcNet network
(4) start of "madHcCtrl.exe"

One thing you could try is to start madHcCtrl.exe manually. Wait until the madVR tray icon is visible (in case you haven't disabled it). Then start madVR. Does the timeout still occur? If yes, the problem is likely not (4). Otherwise it's probably (4). Also try disabling your firewall as a quick test.

It the problem is (2) or (3), it might be difficult to find the real cause for the timeout. Because no other user seems to have this problem, I fear it might be some kind of OS problem, which may only be cured by reinstalling the OS. Hopefully not.

It has to be something that was introduced together with the exclusive mode, as all releases I tried since 0.24+ seem to show the same behavior.
So I doubt it's because I have my firewall blocking the network function, as version 0.24 did not have that function and did not work either, but I will try and test to rule out all possibilities.
Another thing I don't get is why I don't seem to be able to save my madVR settings(?).

And you are right - it could be one of those random OS mess ups. Even though I can't recall any major changes I have made that would cause madVR to glitch, but as an IT professional I know that hardly anyone ever recalls those kind of changes until they are pointed on them specifically
When I get a chance I'll try and see if I get the same behavior with the same machine under another OS / a live OS.

€dit: I went through your list of possible causes.

(1) Any advice on how to rule this possibility out?
(2) Just did a couple of tests using a single monitor setup. No change.
(3) Even if I disable both my fw and av, I get the same behavior :/
(4) If I start madHcCtrl.exe manually it indeed takes forever until the task bar icon appears (even though the process starts immediately and does not cause any load). But madVR still shows the same behavior (timeout and afterward flawless playback).

[madshi]

Originally Posted by 121sea

the math bitdepth if that's even posible whit current video cards

The math is done at the internal bitdepth of the GPU pixel shaders. That's 32bit per component (96bit per pixel) with most newer DX9 GPUs, or even higher with some of the latest GPUs. Increasing this bitdepth any further would surve no purpose, because 96bit per pixel is already pretty much overkill.

Originally Posted by trainspotter

It has to be something that was introduced together with the exclusive mode, as all releases I tried since 0.24+ seem to show the same behavior.

Are you 100% sure that the problem occurs with 0.24, and does not occur with 0.23? If so, that would be interesting...

Originally Posted by trainspotter

Another thing I don't get is why I don't seem to be able to save my madVR settings(?).

Not sure on this one. Saving depends on madVR still working ok in the media player. Otherwise saving won't work.

Originally Posted by trainspotter

(1) Any advice on how to rule this possibility out?

I'll add some more log outputs to the next build. That should help figuring out which step exactly causes the freeze for you.

Originally Posted by trainspotter

(4) If I start madHcCtrl.exe manually it indeed takes forever until the task bar icon appears

That's already a good indication! On all my PCs the tray icon appears *instantly*, right when starting the exe, without any noticeable delay. madHcCtrl.exe, before showing the tray icon, does some of the same network initialization stuff that madHcNet.dll is doing. So my current guess is that one of those network calls hangs on your PC, for whatever reason...

[Snowknight26]

Originally Posted by madshi

Does the corruption always occur at the same frame? Or is it somewhere else every time? Are you sure that your RAM is alright?

I can't reproduce it anymore on the same system, too, so I'll consider it a non-issue.

[madshi]

Originally Posted by Snowknight26

I can't reproduce it anymore on the same system, too, so I'll consider it a non-issue.

Great!

[janos666]

Originally Posted by madshi

Too bad...

I tried the HDMI connection. The custom refresh rate forcing works with this output! (At least on the output side, because my display does internal FRC to feed the fixed RR panel. )

[6233638]

Originally Posted by madshi

The log file says that switching to 1080p72 failed with the Direct3D error information "invalid call". That's not a very helpful error message from Direct3D, I don't really know what went wrong. Are you sure that your display actually supports 1080p72? I'm not sure if single link DVI/HDMI can do that, maybe you need double link DVI for that?

The display does support 1080p72 however the nvidia drivers typically limit you to 1080p60 over HDMI. For some reason with that specific build I was able to create custom resolutions above that. (perhaps they broke the check?) It seems like this is probably an nvidia/windows issue rather than madvr. I no longer have that display now so it is not a problem for me any more.

Originally Posted by madshi

One more thing to consider: Currently madVR resizes the chroma channel directly from source -> target resolution, using the chroma upsampling algorithm. In a future version I plan to change that. I plan to upsample chroma from chroma source -> luma source resolution (2x in X and Y direction). Then I plan to use the luma upsampling algorithm for the remaining scaling. I hope that this will allow a better compromise between chroma detail and lack of artifacts/aliasing. So once I've changed that, you'll have to recheck which algorithms work best for you.

I actually thought this was how madVR was working currently. I did not test for it, I just assumed that to be the case.

It certainly seems like this is the way that it should be done. I would expect chroma upsampling to be done using the algorithm that has chroma matching luma as best as possible, and then both being scaled to the display resolution using the selected 'luma' scaling algorithm.

My original testing for chroma upsampling that resulted in me choosing Bicubic75 was displaying everything at the native luma resolution on CRT (720x480 for dvd and so on) so perhaps Bicubic75 is not the best choice for chroma if you are going to a 1080p native display, at least with the current method. I know you don't really like commenting on the future of madVR, but do you plan on implementing this change soon, or should I start testing chroma when going from SD to 1080p?


For what it's worth, I recently did another round of testing luma scaling going to a 1080p native LCD and after several tests my conclusion was the same: SoftCubic50 produces results that are truest to the source and the best approximation of what an SD source looks like natively on a high end CRT. (the best SD can look in my opinion)

Mitchell Netravali does look sharper, with less ringing than SoftCubic50, but suffers from a considerable amount of aliasing unfortunately. If it were not for this, it would be my choice.

8-tap Lanczos does an amazing job with aliasing and some detail reconstruction, but unfortunately there is far too much ringing with any variant of it. I wish there was an option for scaling with a high tap count that did not introduce such high levels of ringing into the image.

Originally Posted by madshi

Sorry, but that's totally incorrect. All the resampling algorithms used by madVR are doing the same math. They simply, for every target pixel, build a weighted average of the surrounding source pixels. The only difference between the various resampling filters is which weights are applied to which pixels. Spline does not try to draw everything as curves. Spline just has different weights than Lanczos. And Lanczos has different weights to Mitchell-Netravali etc. But in their core, they all do exactly the same math.

My mistake, I thought splines were curves, and that spline was trying to use the data from the surrounding area to calculate them. (number of taps)

Whatever it is doing, looks very artifiical to me.


Thank you for taking the time to go back through this topic and answer all these questions!

[pankov]

madshi,
I'm so glad that you're back.

Could you, please, look at this error report
http://forum.doom9.org/showthread.ph...86#post1449086
This problem is from a while back but it's still present and as far as I can tell independent on sourice filters/splitter and decoders and forced me to go back to v 0.30 to avoid it.
If you want I can provide more recent .log file?

Edit: Actually it was v0.31 I was using not v0.30

[madshi]

Originally Posted by janos666

I tried the HDMI connection. The custom refresh rate forcing works with this output!

Ok, so it works with digital output, but not with analog output?

Originally Posted by 6233638

I know you don't really like commenting on the future of madVR, but do you plan on implementing this change soon, or should I start testing chroma when going from SD to 1080p?

I'd refrain from doing further chroma tests now, because they will be invalid sooner or later, anyway. Don't know how long it will take, though.

Originally Posted by 6233638

For what it's worth, I recently did another round of testing luma scaling going to a 1080p native LCD and after several tests my conclusion was the same: SoftCubic50 produces results that are truest to the source and the best approximation of what an SD source looks like natively on a high end CRT. (the best SD can look in my opinion)

Mitchell Netravali does look sharper, with less ringing than SoftCubic50, but suffers from a considerable amount of aliasing unfortunately. If it were not for this, it would be my choice.

8-tap Lanczos does an amazing job with aliasing and some detail reconstruction, but unfortunately there is far too much ringing with any variant of it. I wish there was an option for scaling with a high tap count that did not introduce such high levels of ringing into the image.

http://forum.doom9.org/showthread.php?t=145358

Don't hold your breath too much, though, I've *loads* of other things on my to do list for madVR, first.

Originally Posted by 6233638

My mistake, I thought splines were curves, and that spline was trying to use the data from the surrounding area to calculate them. (number of taps)

Splines are curves, they're used to calculate the weights used for the weighted average. But weights/curves are *not* image content adaptive (which is I think what you thought). The exact same weights are applied to every destination pixel. FWIW, Bicubic and SoftCubic weights are also calculated by using curves...

Originally Posted by 6233638

Whatever it is doing, looks very artifiical to me.

Is it eventually possible that you were a bit prejudiced when testing spline, because you thought the image would be converted into curves? You're the only person whom I have heard saying that Spline resampling looks artificial.

[madshi]

Originally Posted by pankov

Could you, please, look at this error report
http://forum.doom9.org/showthread.ph...86#post1449086
This problem is from a while back but it's still present and as far as I can tell independent on sourice filters/splitter and decoders and forced me to go back to v 0.30 to avoid it.
If you want I can provide more recent .log file?

I have this problem in my "to look at before next build" list.

It doesn't occur with 0.30? Which is the exact first version it occurs with? 0.31? I need an exact answer to that, that would be helpful, thanks.

[leeperry]

Originally Posted by madshi

Doing "original->big->target" alone does not make any sense. However, doing "original->big->postProcessing->target" is a different matter. Depending on the post processing algorithms, doing the post processing in a higher than target resolution can be beneficial.

You have to decide whether chroma detail is more important or lack of chroma aliasing artifacts. If you pick Bicubic75, you'll have more detail, but also more artifacts and more aliasing.

One more thing to consider: Currently madVR resizes the chroma channel directly from source -> target resolution, using the chroma upsampling algorithm. In a future version I plan to change that. I plan to upsample chroma from chroma source -> luma source resolution (2x in X and Y direction). Then I plan to use the luma upsampling algorithm for the remaining scaling. I hope that this will allow a better compromise between chroma detail and lack of artifacts/aliasing. So once I've changed that, you'll have to recheck which algorithms work best for you.

my Avisynth scripts(LSF/GrainF3/SmoothL) look much better when I upscale before applying them(spline for luma/bicubic 0.0 for chroma) and then let mVR downscale using spline/softcubic100. I guess that mVR tweak you just mentioned wouldn't change anything for me? What do you use for luma/chroma up/down on your own rig? I find spline more natural and less noisy/oversharpened than lanczos(3/4) and softcubic100 perfect to clean chroma noise.

Chroma is encoded at 1/2 res because the brain supposedly isn't too sensitive to chroma res? So who cares if it's too soft? At least its noise doesn't interfere w/ luma anymore? But maybe that mVR tweak is what you meant when you were implying that the softest chroma was't necessarily the truest to the source? Ah well, PQ is eye popping anyway

[6233638]

Originally Posted by madshi

I'd refrain from doing further chroma tests now, because they will be invalid sooner or later, anyway. Don't know how long it will take, though.

Fair enough. I've been here long enough that I know it can be quite some time between releases so I don't mind about that.

The more I think about it, the more it makes sense to do it the other way. (which is why I assumed it was being done like that before) What might be the best chroma algorithm for DVD could be completely different for 720p sources, which would be different for 1080p the way things are being done now.

Only using chroma upsampling to bring chroma resolution to match the native luma resolution, and then scaling both using the luma resampler chosen should produce consistent results regardless of input video resolution. (because then you are always scaling chroma by the same amount)

Originally Posted by madshi

http://forum.doom9.org/showthread.php?t=145358

Don't hold your breath too much, though, I've *loads* of other things on my to do list for madVR, first.

Sounds good, I seem to remember reading about it a while back actually. Of course it remains to be seen how the end result compares to other algorithms in the real world.

Did anything ever come of that iNEDI / ICBI or other more advanced resamplers?

Originally Posted by madshi

Is it eventually possible that you were a bit prejudiced when testing spline, because you thought the image would be converted into curves? You're the only person whom I have heard saying that Spline resampling looks artificial.

That's what I thought the cause for things looking artificial was, it's not why I thought it looked artificial. I went into it 'blind' without any assumptions. If I have any free time I might see if I can come up with some examples.



Something I have noticed recently is that when bringing up the madVR preferences, it is quitting fullscreen mode in MPC-HC, which isn't very helpful when you're trying to compare scaling algorithms. (it resizes the window so that video is displayed at 100%)

Originally Posted by leeperry

my Avisynth scripts(LSF/GrainF3/SmoothL) look much better when I upscale before applying them(spline for luma/bicubic 0.0 for chroma) and then let mVR downscale using spline/softcubic100. I guess that mVR tweak you just mentioned wouldn't change anything for me? What do you use for luma/chroma up/down on your own rig? I find spline more natural and less noisy/oversharpened than lanczos(3/4) and softcubic100 perfect to clean chroma noise.

By oversampling with ffdshow you are losing most of the benefit with madVR in my opinion. However, I don't know what the solution would be, other than madshi implementing his own oversampling + sharpening + downsampling solution. With a good sharpening algorithm, I don't think there should be any need to initially oversample and then downsample though. It is probably a lack of precision with the sharpening that requires you to do this.

Originally Posted by leeperry

Chroma is encoded at 1/2 res because the brain supposedly isn't too sensitive to chroma res? So who cares if it's too soft? At least its noise doesn't interfere w/ luma anymore? But maybe that mVR tweak is what you meant when you were implying that the softest chroma was't necessarily the truest to the source? Ah well, PQ is eye popping anyway

I think this is just an excuse people in the industry have come up with to cut corners. Chroma resolution can be very obvious at times. With games or PC use, it is immediately obvious on anything. With Video it is less obvious but certainly does show up. With video it's not the resolution difference that is most obvious (unless it happens to be red on black) but rather the desaturation of coloured objects when chroma is blurred too much with something like SoftCubic100.

Quick example taken from a very poor DVD scaled to 1080p, shown at 200%.



If you open each in its own tab and switch between the two, the difference should be obvious. It has very little effect on reducing chroma noise, but a significant effect on reducing saturation.

[leeperry]

I'll give you that SoftCubic100 might look blurry on very sharp 1080p...70 looks too noisy to my eyes, maybe 80 is a good compromise. What remains to be seen is what it'll do on noisy SD, but it still looks like a good compromise between noise and bluriness.

[pankov]

Originally Posted by madshi

I have this problem in my "to look at before next build" list.

It doesn't occur with 0.30? Which is the exact first version it occurs with? 0.31? I need an exact answer to that, that would be helpful, thanks.

I did more testing and found that the problem begins with version 0.32. In fact when I though I reverted to 0.30 I actually used v0.31. Sorry for that mistake. I hate Mircrosoft and their ability to break simple stuff like showing file version of .ax files. I had to manually compare by file date and size to the older versions and I made a mistake and dubbed the file as v0.30 when in fact it was v0.31.

I hope this is more helpful information now.

[janos666]

Originally Posted by madshi

Ok, so it works with digital output, but not with analog output?

It works with HDMI but not with DisplayPort. I didn't try with any analog connection.