View Full Version : madVR - high quality video renderer (GPU assisted)
DragonQ
22nd January 2014, 18:31
it's opencl for sure just read: http://forum.doom9.org/showthread.php?t=169766 it never was a secret. but i wonder if it's done in 16 bit but why guessing.
edit: he even stated that the new dithering mode is opencl too
1.85 fps on a GT 430? Well that's me out then.
mandarinka
22nd January 2014, 18:58
Regarding Titan, it should only have a lead on double-precision performance. But since I am not a Titan or 780 owner myself, I can just go by the very few OpenCL benchmarks that are currently available on the web and my understanding of the Kepler (GK110 in this case) architecture.
Yes, only the double-precision performance should be crippled on GeFroce 780/780Ti, and that should not really matter. Most OpenCL tasks probably run on 32-bit math, including this, because with double precision the performance would be too low - basically everything besides Tahiti, Hawaii, GK110 would be unusable.
Cape Verde/Pitcairn/Bonaire GPUs iirc only have 1/16th performance in double precision, while GK104 (and lower) give 1/24th IIRC.
ikarad
22nd January 2014, 22:16
> NNEDI3 upscale
.
What is nnedi3 upscale? Is to replace jinc,lanczos and similar?
If image doubling does what I think it does, will it be possible to, say, perform image doubling from 480p to 960p and then perform rest of the scaling to 1080p using the normal upscaling algorithms?
Is it a new version of smooth motion?
Mangix
22nd January 2014, 22:30
Yes, only the double-precision performance should be crippled on GeFroce 780/780Ti, and that should not really matter. Most OpenCL tasks probably run on 32-bit math, including this, because with double precision the performance would be too low - basically everything besides Tahiti, Hawaii, GK110 would be unusable.
Cape Verde/Pitcairn/Bonaire GPUs iirc only have 1/16th performance in double precision, while GK104 (and lower) give 1/24th IIRC.
In general nvidia hardware does very well with 64-bit operations whereas AMD does very well with 32-bit ones.
AMD also does better on ints than nvidia. This is why oclHashcat is faster on 32-bit hashes with amd hardware. 64-bit hashes are faster on nvidia hardware.
oclHashcat also has the nvidia kernels compiled(it is not open source) using CUDA and NOT OpenCL. There was a section in the wiki where the author explained why this was but I cannot find it. If memory serves me correctly, he mentioned driver issues, a few CUDA-only features, and general stability.
He wanted to switch to OpenCL for nVidia but the cross-compiler seems to produce slower code.
6233638
22nd January 2014, 22:31
What is nnedi3 upscale? Is to replace jinc,lanczos and similar?Yes, it should be a higher quality option than Jinc scaling.
Is it a new version of smooth motion?No, it would seem that "image doubling" is going to be an option to use a high quality algorithm to scale the image 2x, and another to scale that to your display resolution.
nnedi3 is a very demanding algorithm, so few systems are probably going to be able to use it.
However, it might be possible for them to use nnedi3 to scale 2x (which should be faster) and then use another algorithm to scale the resulting image to your display resolution, while still benefiting from some of nnedi3's quality improvements.
ikarad
22nd January 2014, 22:35
Yes, it should be a higher quality option than Jinc scaling.
No, it would seem that "image doubling" is going to be an option to use a high quality algorithm to scale the image 2x, and another to scale that to your display resolution.
nnedi3 is a very demanding algorithm, so few systems are probably going to be able to use it.
However, it might be possible for them to use nnedi3 to scale 2x (which should be faster) and then use another algorithm to scale the resulting image to your display resolution, while still benefiting from some of nnedi3's quality improvements.
Thanks.
If I well understand, image doubling make upscale (multiply by 2 the resolution of image) and downscale (at the display resolution) after, doesn't it?
nnedi3 is a very demanding algorithm, so few systems are probably going to be able to use it.
Do you think that a i5 3570k at 4.5ghz with a gtx780 is more than enough?
6233638
22nd January 2014, 22:44
If I well understand, image doubling make upscale (multiply by 2 the resolution of image) and downscale (at the display resolution) after, doesn't it?More likely something like 360p > 720p (nnedi3) > 1080p (lanczos), or 480p > 960p (needi3) > 1080p (lanczos)
It would probably be faster to go from 720p > 1080p with nnedi3 directly, than 720p > 1440p (nnedi3) > 1080p (catmull-rom)
Do you think that a i5 3570k at 4.5ghz with a gtx780 is more than enough?While AMD seems to be about twice as quick as Nvidia cards (I'm concerned that my GTX 570 may not cut it) I would hope that a 780 is fast enough to handle it.
We'll see soon enough. I'd rather not speculate.
vivan
22nd January 2014, 22:57
It would probably be faster to go from 720p > 1080p with nnedi3 directly, than 720p > 1440p (nnedi3) > 1080p (catmull-rom)but nnedi3 can upscale only by factor of 2x. Or not?
truexfan81
23rd January 2014, 00:04
but nnedi3 can upscale only by factor of 2x. Or not?
nnedi3 only upscales by powers of 2 (ie, 2x, 4x, 8x...).
6233638
23rd January 2014, 00:37
Oh - I was not aware of that. I assumed it was a performance-saving feature, not a requirement.
truexfan81
23rd January 2014, 00:52
yeah so people with weird sized videos, your downscale setting will be more important as it will actually get used
Stereodude
23rd January 2014, 01:24
1080p (catmull-rom)Why would you prefer catmull-rom over some of the other downscaling options?
kasper93
23rd January 2014, 02:37
Because it's the best. Just read the thread, everything has been said already.
Stereodude
23rd January 2014, 02:42
Because it's the best. Just read the thread, everything has been said already.That's not what I've read elsewhere. And with 21k posts it's not a very realistic option to read the whole thread.
kasper93
23rd January 2014, 04:00
So to make it clear. You want me to search the thread for you because you're too lazy, or what? Just search for "Catmull-Rom" and you will get all related posts. CR with AR and Linear Light enabled produce the most accurate and natural looking picture. I tested it a lot myself and I like CR best. Here is comparison to Lanczos done by @6233638 http://forum.doom9.org/showpost.php?p=1606829&postcount=16482
And remember that there is no best option, some people like sharp image with aliasing, some like softer image but without artifacts. You need to compare results yourself, it's not that hard.
drew_afx
23rd January 2014, 04:01
Has anyone cared about upscaling 1080p video(or film) to UHD (2160p) and downscaling back to monitor resolution (1080p)?
Visual difference I found were CGs (pixelated fonts etc) blending
in with rest of the picture although seeming a bit blurry (probably
due to outlines being blended with adjacent pixels).
More importantly, digital noises seemed less intrusive to my eyes.
mandarinka
23rd January 2014, 04:01
However, it might be possible for them to use nnedi3 to scale 2x (which should be faster) and then use another algorithm to scale the resulting image to your display resolution, while still benefiting from some of nnedi3's quality improvements.
Nnedi3 can only do 2x enlargement - it isn't a scaler, but interpolator (hence why it is used for deinterlacing and anti-aliasing). All it can do is interpolate an image into a double-height version. If you stack that two times (once for reach dimension), you will get a 2x upscaled image.
So to do general rescaling with it, you need to combine it with a conventional resampler that will change the resolution to desired values.
For example, if you have 640x360 source, nnedi3 can only give you these sizes: 640x720, 1280x360, 1280x720, 2560x720, 1280x1440, 2560x1440 ...
Also since nnedi3 is a (complex) interpolator, not a scaler, it can lead to various sorts of artifacts, since basically, the filter is "guessing" what is in the extra pixels. It can make mistakes, like blurring/connecting adjacent sharp lines for example.
leeperry
23rd January 2014, 07:28
nnedi3 only upscales by powers of 2 (ie, 2x, 4x, 8x...).
so if I wanna upscale a 4:3 360*288 video to 1080p, I want it to be 1440*1080 in the end so ideally I would like to go 4X360 + 2X288? Apparently mVR will only do 2X :o
Has anyone cared about upscaling 1080p video(or film) to UHD (2160p) and downscaling back to monitor resolution (1080p)?
Visual difference I found were CGs (pixelated fonts etc) blending
in with rest of the picture although seeming a bit blurry (probably
due to outlines being blended with adjacent pixels).
More importantly, digital noises seemed less intrusive to my eyes.
The Avisynth ppl call it SuperSampling, it's like processing audio in 48int/64fp and then dithering back to 24int.
huhn
23rd January 2014, 08:34
so if I wanna upscale a 4:3 360*288 video to 1080p, I want it to be 1440*1080 in the end so ideally I would like to go 4X360 + 2X288? Apparently mVR will only do 2X :o
do you really think that matter with a 288 p. 2x is all what is needed for most video
foxyshadis
23rd January 2014, 09:47
Has anyone cared about upscaling 1080p video(or film) to UHD (2160p) and downscaling back to monitor resolution (1080p)?
Visual difference I found were CGs (pixelated fonts etc)
This is the one and only reason you should ever do this. (Similarly, watching cheaply made aliased junk like YuGiOh.) Anti-aliasing is one of the primary purposes of EDI, but it's much faster to use regular denoising shaders or filters if you don't have extreme aliasing. At that resolution, anti-aliasing would probably not be realtime, anyway; you'd have to re-encode, and you could manually do just the subtitles.
With any luck XySubFilter will eventually do anti-aliasing for VobSub and PGS, so there's no need to do it on the full screen. I feel your pain!
so if I wanna upscale a 4:3 360*288 video to 1080p, I want it to be 1440*1080 in the end so ideally I would like to go 4X360 + 2X288? Apparently mVR will only do 2X :o
Garbage in, garbage out. It'll look different, but it'll never look good. Just stick with one iteration+jinc.
(If you have a cartoony palette with lots of aliasing though, hq4x or double nnedi might be useful. But rarely for natural video.)
Qaq
23rd January 2014, 09:49
How about Nnedi de-interlacing? I suppose Nnedi can provide better results than motion/vector adaptive?
huhn
23rd January 2014, 09:54
but field matching is way better and 60fps bob with nnedi is pretty unrealistic
madshi
23rd January 2014, 10:02
For video mode deinterlacing madVR will continue to rely on DXVA for the near future. At some point (not soon) I'm going to look into the whole deinterlacing topic again. But for now no changes in that area. FWIW, motion adaptive video mode deinterlacing (= weaving for static image areas) and something like nnedi3 are not mutually exclusive.
James Freeman
23rd January 2014, 11:34
How will an HD picture look upscaled to 2560x1440?
Any sharpness loss?
Anyone directly compared between the two (side by side)?
huhn
23rd January 2014, 11:58
How will an HD picture look upscaled to 2560x1440?
Any sharpness loss?
Anyone directly compared between the two (side by side)?
just try it out with the avisynth script
LigH
23rd January 2014, 15:13
Any sharpness loss?
Before asking questions about "sharpness" again, understand what it means (http://svn.int64.org/viewvc/int64/resamplehq/doc/kernels.html). :rolleyes:
I am not a big fan of the Gibbs phenomenon (http://en.wikipedia.org/wiki/Gibbs_phenomenon) caused by bicubic, Lanczos, or similar "sharp" interpolations.
sheppaul
23rd January 2014, 15:18
DxVA2 Scaler seems not working in full screen mode with 1080p videoes.
Demo mode (it can be enabled in CCC) does not work in full screen.
James Freeman
23rd January 2014, 15:26
Before asking questions about "sharpness" again, :rolleyes:
Again? :scared: Isn't it the reason why this thread exists?
Yes, I have read about ringing artifacts and Gibbs phenomenon (I also see them).
I merely want to know from first hand experience how does it look watching 1080p content on a 1440p monitor, and how well MadVR's upscalers doing their job.
madshi
23rd January 2014, 15:47
"How does it look" compared to what? Your real question is probably this:
Is it better to watch 1080p content on a 30" 1080p display? Or is it better to watch 1080p content on a 30" 1440p display, using madVR upscaling?
If this is your question, then I can't answer it because I have no way to test that. The only way you could fairly test this is if you had two 30" display, one with 1080p physical resolution and one with 1440p physical resolution, so you could play the same movie on both and compare directly. Without such a direct comparison, I find it hard to say whether upscaling is beneficial or not. That said, it depends on the upscaling factor. The bigger the scaling factor, the higher the chances upscaling can be beneficial. With scaling factors south of 1.2x I would guess that upscaling is not beneficial, maybe even harmful. However, if you approach a 2.0x factor, upscaling is going to look *a lot* better. So playing back 1080p content on a 4K display should look noticeably better than playing back 1080p content on a 1080p display of the same size. But this is only true if you sit close enough to see the difference. If you sit far enough away, the difference will vanish into thin air...
madshi
23rd January 2014, 15:48
DxVA2 Scaler seems not working in full screen mode with 1080p videoes.
Which GPU? Which OS? Can anybody reproduce this problem?
(Don't care about demo mode.)
DarkSpace
23rd January 2014, 16:22
The Avisynth ppl call it SuperSampling, it's like processing audio in 48int/64fp and then dithering back to 24int.
Uhm, I doubt that. Supersampling is upscaling the video to a higher resolution, processing it there, and then scaling it back. Compared to audio, it would be like upsampling 48 kHz to 192 kHz, doing the modifications there, and then sampling back to 48 kHz.
I don't know where you get the audio bitdepth idea from, but higher audio bitdepth after e.g. a volume change would be similar to increased video bitdepth after e.g. debanding...
sheppaul
23rd January 2014, 16:23
Which GPU? Which OS? Can anybody reproduce this problem?
(Don't care about demo mode.)
ATI 7850, Windows 8.1
Actually I don't use it by myself and don't care too. Someone told me the problem. So I just tried it and found a same problem.
Enabling demo mode makes it figure out easily.
madshi
23rd January 2014, 16:54
ATI 7850, Windows 8.1
Actually I don't use it by myself and don't care too. Someone told me the problem. So I just tried it and found a same problem.
Enabling demo mode makes it figure out easily.
Using the demo mode (I used split screen) to check whether DXVA scaling is active is actually good idea, thanks. I've now tried to reproduce the problem on my PC. I have here also Windows 8.1 and an AMD 7770. DXVA scaling works just fine here in both windowed and fullscreen exclusive modes. Are you sure that in fullscreen exclusive mode zooming/scaling was actually active/needed? madVR only uses DXVA scaling if it's necessary. If you play 1080p content on a 1080p display, madVR does not apply scaling, so in that case also demo mode can't work, because DXVA is not used at all. And the demo mode can only work if the video runs through DXVA, because otherwise the AMD drivers have no influence on what madVR is doing. So try forcing scaling to become active, by zooming into the image a bit.
sheppaul
23rd January 2014, 18:02
If you play 1080p content on a 1080p display, madVR does not apply scaling, so in that case also demo mode can't work, because DXVA is not used at all. And the demo mode can only work if the video runs through DXVA, because otherwise the AMD drivers have no influence on what madVR is doing. So try forcing scaling to become active, by zooming into the image a bit.
Aha, exactly. madVR is really smart. :D
However, can you make an option to force to enable DxVA2 scaler in such case if possible? I'm not really a fan of post-processing of AMD graphic processor but there are several people eager to use it, not because of the dxva2 scaler but because of the video processing provided by the graphic vendor.
Or is there any way to independently use it while using madVR's scalers?
sdancer75
23rd January 2014, 18:02
Hi,
Why I can not find any recources of how to use madvr renderer under c++; Is it free of use ?
Regards
madshi
23rd January 2014, 18:15
However, can you make an option to force to enable DxVA2 scaler in such case if possible? I'm not really a fan of post-processing of AMD graphic processor but there are several people eager to use it, not because of the dxva2 scaler but because of the video processing provided by the graphic vendor.
Or is there any way to independently use it while using madVR's scalers?
To be honest, I'm not totally sure how good the AMD post-processing algorithms are. I don't think it makes sense to activate DXVA2 scaling just to get the post-processing. However, it would surely be possible to make the post-processing available as extra options. I'm not sure if it's a good idea, though. It depends on how good the AMD algorithms really are. Maybe someone else knows how they compare to e.g. AviSynth scripts? The DXVA processing definitely has one big disadvantage: It usually only works in NV12 = 8bit. I prefer to run my algorithms in 16bit.
In the long run madVR may give you alternative algorithms to what those AMD algorithms do, probably with higher quality (but slower performance).
Why I can not find any recources of how to use madvr renderer under c++; Is it free of use ?
Look at "madVR\developers\mvrInterfaces.h". If you know how to use e.g. VMR9, using madVR is not that much different. madVR supports many of the VMR9 interfaces, plus all those private ones listed in the mentioned header file. You can also look at e.g. MPC-HC or MPC-BE, which are open source projects supporting madVR.
Please read the "madVR\license.txt" carefully to see what is allowed and what is not allowed. Especially the paragraph "3RD PARTY SOFTWARE RESTRICTIONS" may be of interest to you.
madshi
23rd January 2014, 18:16
madVR v0.87.0 released
http://madshi.net/madVR.zip
* added debanding algorithm, based on improved version of "flash3kyuu_deband"
* added file name tag "deband=off|low|medium|high"
* added automatic detection for fades from/to black or white (for debanding)
* added support for using OpenCL with NVidia, AMD and Intel GPUs
* added DXVA surface splitting via OpenCL (only AMD and Intel GPUs)
* added error diffusion algorithm (requires OpenCL)
* added NNEDI3 chroma upsampling (requires OpenCL)
* added NNEDI3 image doubling/quadrupling (requires OpenCL)
* added flexible settings profile functionality
* added file name tag "profile='profile name'"
* added IMadVRSettings2 interface to enumerate settings and manage profiles
* settings can now be edited without madVR running (only on local PC)
* madNvLevelsTweaker -> madLevelsTweaker now also works for Intel GPUs
* madVR doesn't dither, anymore, when a pixel doesn't need dithering
* added Intel driver bug workaround for "use separate device for presentation"
* added madHcNet64.dll to allow madTPG automation from 64bit calibration tools
* added API for asking madVR about the output levels (TV, PC, custom)
* fixed: full backbuffer queue slowed rendering down
* fixed: madTPG sometimes didn't update to newly requested test pattern color
* fixed: madTPG dithering produced blocking artifacts
* fixed: when upscaling exactly 2x, AR filter wasn't active for blue channel
* fixed: ArgyllCMS/HCFR disabling the 3dlut didn't work
* fixed: LAV Video Decoder sending v210 produced corrupted image
* improved frame cropping support
* improved windowproc hook stability
* a couple of very small pixel shader performance improvements
* optimized madVR default settings
* improved madVR tray icon menu looks on newer OSs
* tags now require "tag=value" or "tag:value"; "tag value" no longer accepted
* disabled automatic DCI-P3 detection through 2048 video width
I've a lot of comments about this version, so here goes:
(1) I've released this version "early", meaning there are still 2 features missing I was planning to add into v0.87.0. One of them is convergence correction for front projection. I will probably add those features in the next days/weeks and release them as v0.87.something. Also I've ignored most of the bugs you guys reported because I wanted to finally finish the new features. I'll go do bug fixing after I've finished all the planned v0.87.0 features, so bear with me until then...
(2) The debanding feature is nearly unchanged compared to the last test build. There's just one added "trade quality for performance" option now which allows you to disable the going back to re-render old frames, when a fade in/out is detected. Practically this "trade" option results in the stronger debanding setting being used for the whole fade in/out except for the first 5 frames, which will still use the default debanding strength.
(3) The latest AMD drivers *FINALLY* added OpenCL <-> D3D9 interop. I had been waiting for this for a looong time. So finally I can now use OpenCL in madVR with Intel, NVidia and AMD GPUs. You will need the latest AMD drivers, though. It won't work with older drivers.
(4) For best OpenCL performance, currently AMD seems to be the way to go.
(5) Thanks to OpenCL I can now process DXVA2 NV12 data coming from native DXVA decoders, or coming from DXVA2 deinterlacing, losslessly and directly on the GPU. Sadly, this only works for Intel and AMD GPUs. So with NVidia I still have to use copyback, or alternatively live with a small chroma resolution loss. FWIW, I've found that using OpenCL to process DXVA2 NV12 surfaces seems to increase rendering times on Intel GPUs in windowed mode, while it seems to decrease rendering times on Intel GPUs in FSE mode. So I'm not fully sure whether it's a performance improvement or not. Maybe you guys could test that and report back.
(6) The OpenCL error diffusion algorithm can be used instead of the default random dithering (see "trade quality for performance"). Error diffusion should produce similar smoothness as random dithering, but error diffusion should have a lower noise floor. I had to do some minor compromises to implement this on a GPU with decent performance, so quality might be ever so slightly lower than when doing error diffusion sequentially via CPU, but I think it's not too bad. Unfortunately performance is not too great, so make your own decision on whether you like it and whether the performance cost is worth it for you.
(7) NNEDI3 is a somewhat complicated topic, so I'll reserve an extra post for that.
(8) The new profiling support is very flexible. By default the settings look exactly the same way you're used to. But you can now select any settings page (for which it makes sense) and activate profiles for it. You can also group multiple settings pages into one profile group, if you prefer. Each profile group can have an infinite number of profiles. And there's a complicated profile rule set (simplified script language) which lets you decide which profile gets auto selected in which situation. E.g. you can have one profile auto selected for SD content, one for HD content, one for MPEG2 sources, one for h264 sources etc etc. The possilibities are almost endless. Have fun playing with this!
(9) Intel users can now use the latest drivers with the "use a separate device for presentation", but you have to activate a custom border color for this to work. A black border color makes the bug appear. A gray border color will make it go away. Since many media players don't allow you to specify a custom border color, you can force a border color by creating the following registry key:
HKEY_CURRENT_USER\Software\madshi\madVR\BorderColor DWORD 1
You can set this value to any RGB color you want. I'd suggest value 1, which is almost black (Red=0, Green=0, Blue=1). With this border color the Intel driver bug does not occur, anymore.
madshi
23rd January 2014, 18:17
So let's discuss NNEDI3:
(1) NNEDI3 is a resolution doubler. It can double resolution in either X or Y direction. Of course you can run it multiple times, so you can double both X and Y resolution, once, twice, thrice, whatever. Of course you can also double X twice and not double Y at all. Whatever you like. NNEDI3 cannot do anything else except exact 2x resolution doubling.
(2) NNEDI3 has a number of very nice advantages: It is quite sharp, has very low aliasing levels, produces almost no ringing or similar artifacts and has a very clean look to it. Due to the lack of artifacts you can also apply it multiple times to e.g. quadruple image resolution without any problems, or you can followup NNEDI3 upscaling with a different up- or downscaling algorithm.
(3) NNEDI3 unfortunately also has disadvantages: It is relatively slow. It can't do anything other than 2x resolution doubling. It shifts the image by half a pixel (compared to other upscaling algorithms). And it can sometimes introduce weird artifacts that are unknown from linear resamplers like Lanczos or Jinc.
Let's look at a first test image (Monsters Inc. Blu-Ray, run time 0:13:45), upscaled from 1080p to UHD:
http://madshi.net/madVR/monsters.png
Looking at this image, NNEDI3 seems to combine the positive attributes of Lanczos and Jinc upscaling: It's even sharper than Lanczos, has even lower aliasing levels than Jinc and has the lowest levels of artifacts. With this image I'd say it beats the hell out of Lanczos and Jinc. However, it's not perfect. There are a couple image areas which are still aliased. But I guess with this specific source (which is quite heavily aliased to start with) that's really the max we can possibly expect. But now let's look at a different test image:
http://madshi.net/madVR/lighthouse.png
First let's look at the positive aspects of the NNEDI3 upscaling here:
(1) NNEDI3 renders all 3 roofs cleaner and sharper than Lanczos does. The handrail on the lighthouse top outer floor makes this especially obvious.
(2) The whole NNEDI3 image has a clean and sharp look to it. It almost doesn't look like it's upscaled. In contrast to that the Lanczos image has a lot of aliasing, ringing and overall a somewhat coarse look to it. It's pretty obvious that the Lanczos image was upscaled.
But this test image also brutally showcases some of the NNEDI3 weaknesses:
(1) Look at the fence pickets directly at the bottom right of the lighthouse. Lanczos manages to keep the picket sizes nicely equal. NNEDI3 reproduces the pickets at unequal sizes, similar to what Bilinear does. This is one case where the natural ringing in the Lanczos algorithm is actually beneficial. Yes, ringing can sometimes help reproducing images better.
(2) Look at the grass at the bottom part 1/4 of the image. It looks quite weird in the NNEDI3 image, almost like a fractal. This is what bothers me most about NNEDI3. But it seems that all "intelligent" algorithms have this kind of artifact. With grass/trees/nature they often see lines/geometrical figures to connect which don't belong together. No such problem with Lanczos/Jinc.
So there you have, all the good and bad things about NNEDI3. Pick your own poison! At least you have all the options now. If you like NNEDI3, you can also say "thanks" to SEt for providing the OpenCL kernel in this thread:
http://forum.doom9.org/showthread.php?t=169766
Now let's talk performance a bit: Since NNEDI3 is a rather slow algorithm, I've added the option to convert the image to YUV and to only upscale the Y channel with NNEDI3, while using a different algorithm for the chroma channels. Using NNEDI3 on the chroma channels is IMHO slightly wasted. The benefit for the Luma channel is much bigger. Of course you can use NNEDI3 for the chroma channels, too, if you have the GPU juice for that. You can even use it for chroma upsampling, if you prefer. My recommendation is to use NNEDI3 only for the Luma channel and to use a cheap algorithm in the "image upscaling" section, which will then be used to upscale the chroma channels, e.g. Lanczos3 AR or even Bicubic AR.
NNEDI3 doesn't have "taps", instead it has "neurons". The lowest quality level of 16 neurons performs a little bit slower than Jinc3 AR on my PC, when using it only on the Luma channel and when doing an exact 2x size improvement. Every higher quality step almost doubles rendering times. So 32 neurons almost cut performance in half. Using 64 neurons in quarter etc. For Luma upscaling I recommend to use at least 32 neurons. The lowest quality setting of 16 neurons leaves a bit too many artifacts in the image, IMHO. It could still be useful for chroma upscaling, though, if you insist on using NNEDI3 for chroma.
James Freeman
23rd January 2014, 18:24
InstallFilter.exe crashes when clicking install.bat
It actually finishes installing (MadVR.ax Registered Successfully) but when existing InstallFilter.exe it crashes "(InstallFilter.exe Has Stopped Working" appears.
MPC-HC crashes on playback.
Its asking for mini-dump, when I click NO, "MPC-HC.exe Has Stopped Working" window appears.
Same thing, perfectly fine with 0.86.11
mark0077
23rd January 2014, 18:33
Thanks madshi! Fantastic update.
sheppaul
23rd January 2014, 18:33
To be honest, I'm not totally sure how good the AMD post-processing algorithms are. I don't think it makes sense to activate DXVA2 scaling just to get the post-processing. However, it would surely be possible to make the post-processing available as extra options. I'm not sure if it's a good idea, though. It depends on how good the AMD algorithms really are. Maybe someone else knows how they compare to e.g. AviSynth scripts? The DXVA processing definitely has one big disadvantage: It usually only works in NV12 = 8bit. I prefer to run my algorithms in 16bit.
In the long run madVR may give you alternative algorithms to what those AMD algorithms do, probably with higher quality (but slower performance).
I agree with you completely.
Actually I didn't know there was an option for DxVA2 Scaler and failed to explain the purpose of the option. Why did you add it? :p
The post-processing by the graphic card seems to be done via shader as it always works in EVR or EVR C/P regardless of DxVA decoding. madVR is already using shaders. What's the difference between EVR and madVR in such case?
And thank you for the new release.
You are the one of the hidden treasures we have. :cool:
sdancer75
23rd January 2014, 18:35
To be honest, I'm not totally sure how good the AMD post-processing algorithms are. I don't think it makes sense to activate DXVA2 scaling just to get the post-processing. However, it would surely be possible to make the post-processing available as extra options. I'm not sure if it's a good idea, though. It depends on how good the AMD algorithms really are. Maybe someone else knows how they compare to e.g. AviSynth scripts? The DXVA processing definitely has one big disadvantage: It usually only works in NV12 = 8bit. I prefer to run my algorithms in 16bit.
In the long run madVR may give you alternative algorithms to what those AMD algorithms do, probably with higher quality (but slower performance).
Look at "madVR\developers\mvrInterfaces.h". If you know how to use e.g. VMR9, using madVR is not that much different. madVR supports many of the VMR9 interfaces, plus all those private ones listed in the mentioned header file. You can also look at e.g. MPC-HC or MPC-BE, which are open source projects supporting madVR.
Please read the "madVR\license.txt" carefully to see what is allowed and what is not allowed. Especially the paragraph "3RD PARTY SOFTWARE RESTRICTIONS" may be of interest to you.
Hi
Currently I am using vmr9 but in the mvrInterfaces.h I didn't see any interfaces that matches with the vmr9 renderer. I didn't even saw where I can connect window handle with this renderer. Another problem is when I am trying to use your interfaces I get compiling error that says I can not use this interface (I am not writing from my computer now so I don't remember the exactly error right now).
Regards
cyberbeing
23rd January 2014, 18:43
Black screen on my GTX 770 | 332.21 driver | Win7 SP1 x64 when enabling any of the new OpenCL features (NNEDI & Error Diffusion Dither).
Also occurs when enabling OpenCL features after resetting to default settings.
May also be noteworthy that your 2013-12-31 version of the OpenCL code for that Avisynth plugin produces a "Failed to allocate OpenCL Resources" error, while SEt's original OpenCL code runs fine.
noee
23rd January 2014, 18:45
argh. Win7 Ult/HD6570, MPC-HC and jRiver MC, latest CCC
just copied the new files on top of the others, left settings alone completely. Everything is slide show, 8bit, 10bit, film, video, interlaced, progressive....
Back to the last deband "test" version, all is good.
Perhaps something OpenCL is being turned on even though I haven't explicitly done so? Should I start with a complete settings reset?
BTW, tremendous release.
Edit: Looks like it starts with the upload queue, which never goes beyond "1-2". Decoder queue is always at max....
andyvt
23rd January 2014, 18:51
Hi,
Why I can not find any recources of how to use madvr renderer under c++; Is it free of use ?
Regards
madVR is a DirectShow filter. At a high level load and connect it just like any other filter renderer, then use IVideoWindow to configure it. There are other interfaces for settings and OSD, the interfaces are included in the zip.
sneaker_ger
23rd January 2014, 18:52
MPC-HC crashes on playback.
Are you using smooth motion? That will make it crash instantly here. Win 7 x64, Radeon HD 5850, default settings otherwise
iSunrise
23rd January 2014, 18:53
Thanks a lot for 0.87.0 madshi! Perfect timing, as I have the whole evening to test.
Black screen on my GTX 770 w/ 332.21 driver when enabling any of the new OpenCL features.
Same here. I´m on an NV, too, however, I´m using 331.82 (modded Quadro drivers).
A more detailed explanation:
Didn´t change any defaults, just enabled NNEDI3 under the image upscaling option triggers the black screen every time.
James Freeman
23rd January 2014, 18:55
Are you using smooth motion? That will make it crash instantly here. Win 7 x64, Radeon HD 5850, default settings otherwise
No, I don't.
Default everything, MPC crashes.
GTX660, with v331.82
DragonQ
23rd January 2014, 19:01
* added automatic detection for fades from/to block or white (for debanding)
Minor typo there...
Can't test this on my work laptop (which these days can't do anything right, even when playing SD MPEG2 using EVR with no scaling it stutters all the time) but should have some time to test things on my desktop later. I fully expect NNEDI3 to be useless on my GTS250!
madshi
23rd January 2014, 19:12
InstallFilter.exe crashes when clicking install.bat
It actually finishes installing (MadVR.ax Registered Successfully) but when existing InstallFilter.exe it crashes "(InstallFilter.exe Has Stopped Working" appears.
I have an idea why this could be happening. Doesn't occur on my PC, though. In any case I think installation succeeded, so don't worry too much about this.
MPC-HC crashes on playback.
Its asking for mini-dump, when I click NO, "MPC-HC.exe Has Stopped Working" window appears.
This is bad. And I've no idea why this occurs. It runs fine on both my development PC (Windows 8.1 x64, Intel HD4000 and AMD HD7770) and on my HTPC (Windows 7 x64, NVidia 9400).
Does anything OpenCL work on your PC? Although, OpenCL should really not be used by default on your PC, so I don't understand what's going on there. Ok, OpenCL is initialized even if you don't use it, but it's only *initialized*, not actually used...
Actually I didn't know there was an option for DxVA2 Scaler and failed to explain the purpose of the option. Why did you add it? :p
Mostly because the DXVA2 scaling algorithm on Intel GPUs has a nice performance vs. quality ratio. Of course madVR's scaling algorithms are better, but also slower.
The post-processing by the graphic card seems to be done via shader as it always works in EVR or EVR C/P regardless of DxVA decoding. madVR is already using shaders. What's the difference between EVR and madVR in such case?
I don't know what media players do when using EVR or what EVR does inside. I can only speak for madVR, and I try to avoid DXVA whereever I can, because often the AMD video options are set to crazy settings by default, and usually *not* using them is the best idea to get best quality.
Currently I am using vmr9 but in the mvrInterfaces.h I didn't see any interfaces that matches with the vmr9 renderer. I didn't even saw where I can connect window handle with this renderer.
Why would I re-define the interfaces in my header? They're already defined in the MS headers. All the usual interfaces like IBasicVideo and IVideoWindow are supported by madVR.
Another problem is when I am trying to use your interfaces I get compiling error that says I can not use this interface (I am not writing from my computer now so I don't remember the exactly error right now).
You should use QueryInterface() on the madVR instance to get access to those custom interfaces.
Black screen on my GTX 770 w/ 332.21 driver when enabling any of the new OpenCL features.
:( Strange. Works with my old 9400.
argh. Win7 Ult/HD6570, MPC-HC and jRiver MC, latest CCC
just copied the new files on top of the others, left settings alone completely. Everything is slide show, 8bit, 10bit, film, video, interlaced, progressive....
Back to the last deband "test" version, all is good.
Perhaps something OpenCL is being turned on even though I haven't explicitly done so? Should I start with a complete settings reset?
Oh man. Seems like it doesn't work for *anybody*? <sigh> Why does it work on both of my PCs without any problems. I'm confused...
Edit: Looks like it starts with the upload queue, which never goes beyond "1-2". Decoder queue is always at max....
Oh ok. Can you try with different video clips? E.g. one SD clip? You're using J.River MC, right? Can you disable the option that crops 1-2% of the image area, in case you have this option enabled? Don't remember the exact name/place of this option. Can you double check with a different media player, just to isolate the cause of the problem?
Same here. I´m on an NV, too, however, I´m using 331.82 (modded Quadro drivers).
A more detailed explanation:
Didn´t change any defaults, just enabled NNEDI3 under the image upscaling option triggers the black screen every time.
Hmmmm... Same happens with error diffusion? What happens if you give it a couple of seconds? The first time you use any of these features the OpenCL kernels need to be compiled from source code. They compiled kernels are then cached to the registry. See HKCU\Software\madshi\madVR\OpenCL. Does this registry key exist on your PC?
Are you using smooth motion? That will make it crash instantly here. Win 7 x64, Radeon HD 5850, default settings otherwise
Doesn't happen here. Smooth motion works fine here on Win 8.1 x64 HD 7770... :(
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.