View Full Version : madVR - high quality video renderer (GPU assisted)
drew_afx
18th February 2014, 16:43
Nvidia WHQL driver - 334.89 released today
http://www.nvidia.com/download/driverResults.aspx/73218/en-us
Unfortunately, OpenCL problem with madvr is still not resolved.:(
edit: https://forums.geforce.com/default/topic/690370/geforce-drivers/official-nvidia-334-89-whql-display-driver-feedback-thread-released-2-18-14-/
official driver thread for links
nevcairiel
18th February 2014, 16:44
Would really wish they would finish their articles before posting them. :p
DragonQ
18th February 2014, 16:57
Nvidia WHQL driver - 334.89 released today
http://www.nvidia.com/download/driverResults.aspx/73218/en-us
Unfortunately, OpenCL problem with madvr is still not resolved.:(
Broken link, doesn't appear in searches. Perhaps it was pulled?
wanezhiling
18th February 2014, 17:00
http://www.nvidia.com/download/driverResults.aspx/73245/en
DragonQ
18th February 2014, 17:08
Not sure I want a Chinese nVidia driver...
leeperry
18th February 2014, 17:08
Where's the openCL benchmark?
The last paragraph at anandtech isn't worded very well and missing some information. To me it sounds like it can do Jinc3AR chroma and image upscaling and nnedi3 chroma and luma doubling on a 1080p display with source resolutions up to 1080p. Even if it can do that with 720p source it's pretty impressive for the price. Would be nice if they fixed their tables and used a more comparable nvidia card for madvr tests, like a 650ti.
Here (http://www.anandtech.com/show/7764/the-nvidia-geforce-gtx-750-ti-and-gtx-750-review-maxwell/22). Apparently there are several OCL benchmarks results actually, but I was talking about Luxmark 2.0 that was also used in that article (http://www.extremetech.com/computing/153467-amd-destroys-nvidia-bitcoin-mining/2).
Nvidia would still appear to very much lag behind on the OCL front, I can kiss CUVID deinterlacing goodbye.
Nvidia WHQL driver - 334.89 released today
http://www.nvidia.com/download/driverResults.aspx/73218/en-us
Unfortunately, OpenCL problem with madvr is still not resolved.:(
Last time they promised me a fix, it took ages to make it in the WHQL drivers.
DragonQ
18th February 2014, 17:12
Nvidia would still appear to very much lag behind on the OCL front, I can kiss CUVID deinterlacing goodbye.
I wonder where newer cards stand on deinterlacing. I don't think proper comparisons have been made recently between AMD, Intel and nVidia deinterlacing algorithms, and it would be nice to know for people buying newer cards for MadVR.
leeperry
18th February 2014, 17:14
I wonder where newer cards stand on deinterlacing. I don't think proper comparisons have been made recently between AMD, Intel and nVidia deinterlacing algorithms, and it would be nice to know for people buying newer cards for MadVR.
Nev said that AMD's deinterlacer would be totally unusable in LAV :(
wanezhiling
18th February 2014, 17:17
All Nvidia offical drivers include multiple languages, not only chinese :p
cyberbeing
18th February 2014, 17:20
There's a bug report in the last paragraph that I haven't seen in this thread.
Anandtech's bug sounds like it occurred when using NNEDI3 chroma upscaling from how it was worded, and subsequently crashed the driver. I would disregard it, since drew_afx just stated the 334.89 driver is still broken with madVR OpenCL.
All Nvidia offical drivers include multiple languages, not only chinese :p
Only the "International" drivers contain multiple language. They also have smaller sized "English" drivers which do not include additional languages. US English is the only language they do that for though.
The OpenCL benchmark result doesn't look too good, sub-HD7790 territory.
Overall a nice improvement compared to Kepler though, as the 750Ti is beating the GTX 660 overall in compute.
DragonQ
18th February 2014, 17:22
Nev said that AMD's deinterlacer would be totally unusable in LAV :(
I think that only applies to actually applying deinterlacing within LAV Video, which isn't always necessary. MadVR and EVR can do it later on.
turbojet
18th February 2014, 17:33
Would really wish they would finish their articles before posting them. :p
They've been twitterversed.
Here (http://www.anandtech.com/show/7764/the-nvidia-geforce-gtx-750-ti-and-gtx-750-review-maxwell/22). Apparently there are several OCL benchmarks results actually, but I was talking about Luxmark 2.0 that was also used in that article (http://www.extremetech.com/computing/153467-amd-destroys-nvidia-bitcoin-mining/2).
Nvidia would still appear to very much lag behind on the OCL front, I can kiss CUVID deinterlacing goodbye.
In Luxmark 2.0 it looks pretty competitive to the 260X which is a faster rebadge 7790 afaik. CLcompute's are concerning though. Not sure if that has anything to do with madvr's opencl performance. It seems higher end nvidia gpus are competitive with the higher end ati cards in this thread though, while nnedi3ocl.dll thread shows ati should be dominating.
Anandtech's bug sounds like it occurred when using NNEDI3 chroma upscaling from how it was worded, and subsequently crashed the driver. I would disregard it, since drew_afx just stated the 334.89 driver is still broken with madVR OpenCL.
This is the quote I'm talking about "4K to 1080p downscaling results in greenish screens intermittently, finally ending up with a resetting Direct 3D Device failure. The downscaling path seems to be buggy, either due to driver issues or bugs in madVR v0.87.4." logically there shouldn't be any nnedi3 but it's unknown how nnedi3 was setup.
leeperry
18th February 2014, 17:34
I think that only applies to actually applying deinterlacing within LAV Video, which isn't always necessary. MadVR and EVR can do it later on.
When it comes to double frame rate, CUVID looks quite a bit better than YADIF. It's really great to get very clean looking 50/59.94fps content in mVR without any CPU load...and because it's not done behind Reclock's back, it works as is. I've tried to convince James to make Reclock play nice with mVR but he would appear to have better things to do, I suspect that ogo(the original coder of Reclock)'s source code looks pretty nightmarish.
DragonQ
18th February 2014, 17:36
When it comes to double frame rate, CUVID looks quite a bit better than YADIF. It's really great to get very clean looking 50/59.94fps content in mVR without any CPU load...and because it's not done behind Reclock's back, it works as is. I've tried to convince James to make Reclock play nice with mVR but he would appear to have better things to do, but I suspect that ogo(the original coder of Reclock)'s source code looks pretty nightmarish.
I dunno about Reclock but telling MadVR to do deinterlacing gives you the same deinterlacing as enabling CUVID deinterlacing at highest quality.
cyberbeing
18th February 2014, 17:45
This is the quote I'm talking about "4K to 1080p downscaling results in greenish screens intermittently, finally ending up with a resetting Direct 3D Device failure. The downscaling path seems to be buggy, either due to driver issues or bugs in madVR v0.87.4." logically there shouldn't be any nnedi3 but it's unknown how nnedi3 was setup.
Yes, and right before that they say NNEDI3 Chroma Upscaling (4:2:0 YCbCr -> 4:4:4 RGB) was causing the green tinge. It's very likely that downscaling with NNEDI3 Chroma broken in the driver caused the lost D3D device error. I remember seeing the same lost D3D device error when I enabled OpenCL features in >327.23 drivers where the OCL<->D3D9 interop was borked. I guess we'll find out for sure once someone on Doom9 gets a GTX 750 or 750 Ti.
Not sure if that has anything to do with madvr's opencl performance. It seems higher end nvidia gpus are competitive with the higher end ati cards in this thread though, while nnedi3ocl.dll thread shows ati should be dominating.
Higher-end NVIDIA GPUs become competitive in madVR NNEDI3 because their OpenCL<->D3D9 interop only requires +1-2ms render times, while AMD's requires +10-15ms. madVR requires use of the D3D9 interop, while the Avisynth plugin does not. madVR also uses a smaller/faster custom modified 8x4 NNEDI3 OCL kernel, while the Avisynth plugin uses a larger/slower 8x6 NNEDI3 OCL kernel, so any performance scaling results are likely not directly comparable.
leeperry
18th February 2014, 17:49
I dunno about Reclock but telling MadVR to do deinterlacing gives you the same deinterlacing as enabling CUVID deinterlacing at highest quality.
Well, not really (http://forum.doom9.org/showpost.php?p=1649687&postcount=16243)(hopefully even James Freeman will see the difference http://forum-images.hardware.fr/images/perso/2/harley_quinn.gif).
In Luxmark 2.0 it looks pretty competitive to the 260X which is a faster rebadge 7790 afaik. CLcompute's are concerning though. Not sure if that has anything to do with madvr's opencl performance. It seems higher end nvidia gpus are competitive with the higher end ati cards in this thread though, while nnedi3ocl.dll thread shows ati should be dominating.
I'm completely lost in the whole AMD renaming crapola but apparently the 260X is a very slightly faster 7790 indeed (http://www.hardware.fr/medias/photos_news/00/42/IMG0042951.png).
They prolly have no way to drastically improve GPGPU performance without major changes and sales are doing great so who cares.
madshi
18th February 2014, 18:40
http://www.anandtech.com/show/7764/the-nvidia-geforce-gtx-750-ti-and-gtx-750-review-maxwell/9
Given this is an 'entry level' card that may see see some passive models and can do just about everything with madvr, nnedi3 TBD, maxwell may be very nice for madvr.
Maybe those of you who reported the OpenCL problem to NVidia could forward the link to this article to your NVidia contact? Maybe it could help speeding the bug fix up a little... :)
iSunrise
18th February 2014, 19:12
Yes, and right before that they say NNEDI3 Chroma Upscaling (4:2:0 YCbCr -> 4:4:4 RGB) was causing the green tinge. It's very likely that downscaling with NNEDI3 Chroma broken in the driver caused the lost D3D device error. I remember seeing the same lost D3D device error when I enabled OpenCL features in >327.23 drivers where the OCL<->D3D9 interop was borked. I guess we'll find out for sure once someone on Doom9 gets a GTX 750 or 750 Ti.
Actually the same thing happened to me, if you played with e.x. NNEDI on anything higher than 327.23, the driver sometimes doesn´t react very well to it and you suddenly get all kinds of different errors, which I reported as a warning, since we were still testing at that time. Only a system restart made madVR completely usable again.
Maybe those of you who reported the OpenCL problem to NVidia could forward the link to this article to your NVidia contact? Maybe it could help speeding the bug fix up a little... :)
We seem to think alike, I´ve done just that right after I read the review today, Blaire is now up-to-date.
If there´s any hope, NV will realize that madVR is now part of some major sites' review arsenal and since they also market the 750/750 Ti as a HTPC card, they should think about what this means if AMD works and NV doesn´t, because that´s what it comes down to.
kache
18th February 2014, 19:18
Updated to latest MadVR.
Tried NNEDI3 chroma upscaling on my Intel HD3000 integrated GPU, but when sending the videos in fullscreen the green tinge appears, and rendering times skyrockets above 200ms.
Back to Lanczos, I guess.
Oh, small question: why does DXVA scaling on both upscaling and downscaling gives (far) better performance and comparable if not better quality than Lanczos 3 taps?
James Freeman
18th February 2014, 19:25
It seems that the latest Nvidia driver did something to OpenCL...
With the latest beta driver the picture was Green, but when switching to full screen, a transparent frozen frame of different primary color (blue or red) appeared (of that frame), and the green video continued to play.
With the latest WHQL driver there is no red/blue frozen frames when going full screen, its basically just green video (looks like when disconnecting the CbCr cables with component).
madshi
18th February 2014, 19:53
If there´s any hope, NV will realize that madVR is now part of some major sites' review arsenal
Some? I only know about Anandtech. Are there others?
Updated to latest MadVR.
Tried NNEDI3 chroma upscaling on my Intel HD3000 integrated GPU, but when sending the videos in fullscreen the green tinge appears, and rendering times skyrockets above 200ms.
Back to Lanczos, I guess.
Oh, small question: why does DXVA scaling on both upscaling and downscaling gives (far) better performance and comparable if not better quality than Lanczos 3 taps?
No chance to run NNEDI3 at real time with a HD3000 (or even HD4000, I think).
Intel DXVA scaling has reasonably good image quality, better than AMD or NVidia. It's not as good as madVR's Lanczos AR algorithm, but not *much* worse. It has one key disadvantage, though: Input has to be 8bit NV12, and output is 8bit (IIRC) RGB. So there can be some banding problems.
iSunrise
18th February 2014, 20:07
Some? I only know about Anandtech. Are there others?
The really big one is Anandtech, there are smaller ones like missingremote (http://missingremote.com/review/intel-hd-4600-madvr-performance). Maybe I shouldn´t have used the word "major" in the same sentence though. ;)
I think the problem for review sites in general is that they are not sure how to integrate madVR within their tests, because they also need something like GPU-Z / MSI Afterburner and know some basics about madVR benchmarking. Was there actually talk between you and Anand when he started to use madVR in his reviews?
pirlouy
18th February 2014, 20:08
madshi, to help these reviewers, and to help having better GPU, maybe you should create a benchmark application (you could even sell it at some point). With such a benchmark, it would make madVR more popular.
kache
18th February 2014, 20:24
Some? I only know about Anandtech. Are there others?
No chance to run NNEDI3 at real time with a HD3000 (or even HD4000, I think).
Intel DXVA scaling has reasonably good image quality, better than AMD or NVidia. It's not as good as madVR's Lanczos AR algorithm, but not *much* worse. It has one key disadvantage, though: Input has to be 8bit NV12, and output is 8bit (IIRC) RGB. So there can be some banding problems.
An acceptable tradeoff for me, since it more than halves the rendering times.
Another question: is there any other less GPU-intensive way to apply the MPC-HC sharpen shader (or anything else that does a comparable job) to the image without the heavy performance tradeoff (currently increases rendering from 9ms to 19-20ms)?
Thanks for the answers. :D
pirlouy
18th February 2014, 21:21
James Freeman has already been told to stop trolling about that.
You want to know the truth ? I have no need for NNEDI, Jinc, Debanding, calibration tools. Did I spam this thread that "because I don't see differences, I want you to stop talking about it and let madshi implements stuff that really cares to me" ?
You don't see the differences ? Then do like me, you just let debate those who see differences. If madshi thinks there's no differences, he'll end the discussion himself.
James Freeman
18th February 2014, 21:33
As I already said, that's why more than 4 people should SEE & vote for the future of madVR best looking builds.
I think guys like bacondither, cyberbeing, Ver Greeneyes and madshi of cours, know their dithering math much better than anyone on this board.
So the heaviest most significant votes should be theirs, for our own good.
XMonarchY
18th February 2014, 21:36
What is the main difference between dither and Error Diffusion? Isn't ED also a dithering method?
What is the theory as to how dithering improves video playback fidelity?
madshi
18th February 2014, 21:49
You want to know the truth ? I have no need for NNEDI, Jinc, Debanding, calibration tools. Did I spam this thread that "because I don't see differences, I want you to stop talking about it and let madshi implements stuff that really cares to me" ?
You don't see the differences ? Then do like me, you just let debate those who see differences. If madshi thinks there's no differences, he'll end the discussion himself.
:goodpost:
leeperry
18th February 2014, 21:53
To this I agree.
As I already said, that's why more than 4 people should SEE & vote for the future of madVR best looking builds.
1 placebo out of 4 is 25% of voting power...
The Cable Elevator thingy, cracked the hell out of me.
There's a truckload of audiophool magical thinking around the internet, it can't be helped......as long as there'll be ppl willing to pay there'll be ppl ready to sell. I haven't used CD's in ages and I've never believed in magical thinking for that matter.
It's really too bad you feel so raw about not being able to see any difference but you have shared your opinion multiple times and your wunderbar homebrew screenshots too, TYVM. I think you made your point. BTW:
A4 works for me and my 799.00 Mitsubishi HC7900. I am an end user and this build seems to have it all. Just when I think I am happy the bar is raised even higher.
I'm all over AD4.
At this point, I'll only say that the A4 is a major improvement
Many ppl can see differences. Mods have been notified BTW, thank you for your cooperation.
Shiandow
18th February 2014, 21:53
What is the main difference between dither and Error Diffusion? Isn't ED also a dithering method?
What is the theory as to how dithering improves video playback fidelity?
They both solve the same problem, that is to represent colours that can't be displayed by intelligently picking similar colours. The main reason that ED is preferable is that it achieves this but with far less noise. Random dithering tries to do this by randomly choosing the colours with the right probability, error diffusion does this by making surrounding pixels compensate for losses in accuracy. In theory RD is exact but you'd need to average it over a huge amount of pixels to get any kind of accuracy, I'm not sure if error diffusion is exact but it averages far more quickly to the right colour.
Devrim
18th February 2014, 22:27
Guys
When do we use NNEDI, how do we use NNEDI?
Ver Greeneyes
18th February 2014, 22:38
http://www.nvidia.com/download/driverResults.aspx/73245/enNot sure I want a Chinese nVidia driver...Oddly, it looks like the US version was pulled (at least, I couldn't find it by editing the link). But the UK version is here (32-bit) (http://www.nvidia.com/download/driverResults.aspx/73232/en) and here (64-bit) (http://www.nvidia.com/download/driverResults.aspx/73250/en).
Edit: Though, I can only find the 32-bit version of that so far.
Edit2: Ah, found the 64-bit version.
MistahBonzai
18th February 2014, 23:35
8bit processing a big no-no, it will increase both banding and noise-floor. You are throwing away quite a lot of useful data that mVR could put to good use.
.
.
.
Every optical filter in the light path will temper with sharpness, even the TOTL multi-coated ones AFAIK.
I'm well aware of both points. In the case of ffdshow/interframe2 processing the 'damage' inflicted on the 'source' goes far beyond 8 bit processing. You are adding interpolated images into the mix... Nonetheless that (increased fluid motion) is the ends to which I strive. All the while keeping an eye on injecting the minimum of artifacts while working toward my perception of maximum viewing pleasure. You see I have my own subjective versions of pop and clarity :-)
In any case I disable the whole ffdshow/avisynth chain (along with any other extraneous processing) while evaluating and adjusting 'base level' modifications.
As for the blurriness introduced by the ND filters, they are temporally inserted to balance brightness while subjectively adjusting color temperature against a target. They are not part of the post calibration viewing experience. I seriously doubt that the slight bluing of either source or target color temperature has any effect on a subjective adjustment procedure.
As previously stated I'm after achieving specific effects but firmly believe that I need to build on a solid (reproducible) foundation. To that end I strive to make the best of the resources at hand while being in the position to recreate my starting point, if necessary, when I encounter obstacles. Your observations (and the effort expended to voice them) are greatly appreciated. Thanks.
mindbomb
19th February 2014, 01:15
Maybe those of you who reported the OpenCL problem to NVidia could forward the link to this article to your NVidia contact? Maybe it could help speeding the bug fix up a little... :)
While we're talking to nvidia, can someone also ask for 0-255 output options for hdmi in the nvidia control panel.
turbojet
19th February 2014, 03:26
Yes, and right before that they say NNEDI3 Chroma Upscaling (4:2:0 YCbCr -> 4:4:4 RGB) was causing the green tinge. It's very likely that downscaling with NNEDI3 Chroma broken in the driver caused the lost D3D device error. I remember seeing the same lost D3D device error when I enabled OpenCL features in >327.23 drivers where the OCL<->D3D9 interop was borked. I guess we'll find out for sure once someone on Doom9 gets a GTX 750 or 750 Ti.
4K 4:2:0 chroma is already at 1080p isn't it? Which is the display resolution. Does madvr really double 4K chroma then downsize back to the original resolution? Seems like a lot of unnecessary work if it does. Logically chroma shouldn't be resized in this situation.
Higher-end NVIDIA GPUs become competitive in madVR NNEDI3 because their OpenCL<->D3D9 interop only requires +1-2ms render times, while AMD's requires +10-15ms. madVR requires use of the D3D9 interop, while the Avisynth plugin does not. madVR also uses a smaller/faster custom modified 8x4 NNEDI3 OCL kernel, while the Avisynth plugin uses a larger/slower 8x6 NNEDI3 OCL kernel, so any performance scaling results are likely not directly comparable.
That explains it well but also means nvidia vs amd is an apple to oranges comparison when it comes to opencl benchmarks and madvr.
XMonarchY
19th February 2014, 05:39
Can anything that madVR does, other than Smooth Motion, increase the amount of trails/trailing? Smooth motion is turned off, but lately, several videos I watched had crazy trails that ruined the experience. I know I only have an SPVA with a rather high 6ms response time, but I've never noticed these trails before in movies or in games. Now I see them only in some rips, but high quality ones. Could bad rips introduce such trails? Something specific, like a setting? Not all rips have them, but some have little, and others have a lot. Could it be that random dithering was hiding this effect from me and now that the image is clear with ED I can see them? I'm only asking - I don't mean to spread mis-information about madVR, especially false/unrelated one.
6233638
19th February 2014, 05:48
Can anything that madVR does increase the amount of trails/trailing? Lately, several videos I watched have crazy trails that ruin the experience. I know I have an SPVA with a rather high 6ms response time, but I've never noticed these trails before in movies or games. Now I see them in some rips, but high quality ones. Can the ripping process introduce such trails? Not all rips have them, but some have little, and others have a lot. Could it be that random dithering was hiding this effect from me and now that the image is clear with ED I can see them? I'm only asking - I don't mean to spread mis-information about madVR, especially false/unrelated one.Disable Smooth Motion.
XMonarchY
19th February 2014, 06:26
Disable Smooth Motion.
Its off, but I still see trails... I just tried using different decoders, turning off acceleration, VideoClock, even trying WMP and still see trails in those rips. Its definitely the rips because trails happen only in some of them. Others are perfectly fine without a single trail even during heavy action. In which forum section should I ask about this and about rip settings that may be the cause this? Googling "movie rip trail/s" or anything trail-related brings up completly different information. There's got to be a different term/name for this effect.
jkauff
19th February 2014, 08:30
Its off, but I still see trails... I just tried using different decoders, turning off acceleration, VideoClock, even trying WMP and still see trails in those rips. Its definitely the rips because trails happen only in some of them. Others are perfectly fine without a single trail even during heavy action. In which forum section should I ask about this and about rip settings that may be the cause this? Googling "movie rip trail/s" or anything trail-related brings up completly different information. There's got to be a different term/name for this effect.
What program are you using for ripping? Can you experiment with other ripping programs to make sure the video files aren't being damaged, and that copy protection is being removed completely?
annovif
19th February 2014, 08:58
Thenk you, again a good shot, Madshi:)
someone has updated this table? 6233638 how are your tests? have You reached a conclusion on the best new setting for the best quality ?
http://tweakvideo.altervista.org/blog/wp-content/uploads/2013/10/HLv1qmj.png
Thank you, Fabio
cyberbeing
19th February 2014, 08:59
4K 4:2:0 chroma is already at 1080p isn't it? Which is the display resolution. Does madvr really double 4K chroma then downsize back to the original resolution? Seems like a lot of unnecessary work if it does. Logically chroma shouldn't be resized in this situation.
The way current madVR versions function, 4:2:0 & 4:2:2 chroma are always upscaled to RGB at original video resolution before any additional scaling required takes place. Old versions of madVR (<=0.61) did the opposite, and resized chroma resolution directly to output resolution as you're suggesting. I remember change occurring quite clearly, as it caused both 6233638 and myself to do a massive re-test of all the chroma algorithms. The changelog seems to suggest this was done to increase the performance of chroma scaling, since exact 2x scaling could be optimized to be considerably faster than something like 1.9x scaling. I cannot remember at this time if there were any additional reasons.
Though now that 4K is on the horizon, maybe it would be worth considering a special rule in madVR for when the video is downscaled to equal or below native chroma resolution.
That explains it well but also means nvidia vs amd is an apple to oranges comparison when it comes to opencl benchmarks and madvr.
Well in regular OpenCL-only compute benchmarks, AMD certainly has a trend of being faster then NVIDIA. You just cannot easily interpolate AMD's raw compute performance to madVR's intermingling of OpenCL & D3D9. As was shown earlier in this thread with the OpenCL error-diffusion, the D3D9 interop had a higher render time cost than the actual AMD OpenCL compute time. When madshi ported the error-diffusion routine to DirectCompute, AMD's handycap was removed and they saw a massive performance increase. NNEDI3 on the other hand is looking like it will be stuck with OpenCL, and permanently handicapped on AMD. Even though NNEDI3 is considerably more computationally expensive than error-diffusion, the D3D9 interop penalty will act as a static performance cap as AMD GPUs become faster. The unknown question is if the interop penalty is a driver design issue or a hardware design issue.
At the end of the day, this just means madVR NNEDI3 performance will have a somewhat unfavorable non-linear relationship with raw compute performance increases on AMD. And assuming NVIDIA gets off their ass and fixes their driver regression sometime this year, NNEDI3 performance with this next generation of Maxwell GPUs should scale more linearly with NVIDIA's compute performance increases.
Could bad rips introduce such trails? Something specific, like a setting? Not all rips have them, but some have little, and others have a lot.
On interlaced and telecined content, yes it's possible if not deinterlaced or IVTC + decimated properly before encoding.
If you are using some kind of temporal denoising before encoding, it's also possible.
leeperry
19th February 2014, 10:25
That explains it well but also means nvidia vs amd is an apple to oranges comparison when it comes to opencl benchmarks and madvr.
Humm, where does that quote come from? Some older post from madshi?
If OCL benchmarks cannot be fully trusted, it would be nice to know what nvidia GPU it takes to do 64x NNEDI 720p@1080p / CR AR LL downscaling / J3AR chroma with low debanding & ED. A 1Ghz HD7850 does all that but if it doesn't cost $500 to do the same with nvidia, I'd consider switching boats due to CUVID deinterlacing.
As for the blurriness introduced by the ND filters, they are temporally inserted to balance brightness while subjectively adjusting color temperature against a target.
I strongly suspect that a ND filter would mess with the color temperature and any semi-decent colorimeter can measure the latter using Argyll more accurately than your eyes IMHO.
ryrynz
19th February 2014, 10:59
someone has updated this table? 6233638 how are your tests? have You reached a conclusion on the best new setting for the best quality ?
http://tweakvideo.altervista.org/blog/wp-content/uploads/2013/10/HLv1qmj.png
There's so many options now that this table would need about twice the presets, many of them would come down to the amount of neurons you could use for NNEDI.
I think that the top quality config would just specify that you should select as many neurons as your GPU allows without frame drops..
But really it's all about what content you play.
6233638
19th February 2014, 11:15
The changelog seems to suggest this was done to increase the performance of chroma scaling, since exact 2x scaling could be optimized to be considerably faster than something like 1.9x scaling. I cannot remember at this time if there were any additional reasons.If you only scale chroma 2x so that it matches the luma resolution, you will always have the same results regardless of the source resolution and output resolution.
If you scale chroma resolution directly to the final output resolution, the results could differ depending on how much the image is being scaled.
It's just a happy coincidence that it also allowed for the chroma scaling performance to be optimized when Madshi later implemented optimized 2x and 3x scaling for 4K displays. (1080p x2 = 4K, 720p x3 = 4K)
Though now that 4K is on the horizon, maybe it would be worth considering a special rule in madVR for when the video is downscaled to equal or below native chroma resolution.I suspect that it would be a bad idea to downscale luma to 1080p and display chroma 1:1, rather than upscale chroma to 4K and downscale luma & chroma using the same algorithm.
It might be a worthwhile "trade quality for performance" option, though I suspect you might see a lot of chroma aliasing.
cyberbeing
19th February 2014, 12:18
Humm, where does that quote come from? Some older post from madshi?
That particular quote was mine, but madshi has also stated similar things in this thread. Though at this point, there really haven't been enough tests with identical settings and across AMD/NVIDIA line-ups to draw firm conclusions. The only thing for sure at this point seems to be that the OpenCL<->D3D9 interop is very expensive on AMD GPUs, and not so on NVIDIA. This allows the possibility of NVIDIA finishing OpenCL computation slower than AMD, but still having lower render times in madVR because of the cheaper interop.
If OCL benchmarks cannot be fully trusted, it would be nice to know what nvidia GPU it takes to do 64x NNEDI 720p@1080p / CR AR LL downscaling / J3AR chroma with low debanding & ED. A 1Ghz HD7850 does all that but if it doesn't cost $500 to do the same with nvidia, I'd consider switching boats due to CUVID deinterlacing.
If you are talking about the following:
1280x720 23.976fps Video
1920x1080 @23.976hz display (Smooth Motion disabled)
Low Debanding
Error-Diffusion Dithering
NNEDI3 Luma Doubling (64 neurons)
Jinc3-AR Image Upscaling
Jinc3-AR Chroma Upscaling
Catmull-Rom-LL-AR Image Downscaling
My GTX 770 ($330 USD) can handle that at ~70% GPU load & 30ms render times. It can just barely handle the above with NNEDI3 Chroma Upscaling (64 neurons) added on as well at ~95% GPU load & 40ms render times. With NNEDI3 Chroma Upscaling (32 neurons) you instead have ~80% GPU load & 35ms render times. With higher frame rate content or smooth motion, certain settings would need to be scaled back though.
Seeing the preliminary compute results from little Maxwell (more registers, better caches, etc.), I'd be hopeful that big Maxwell will produce such performance at much lower price point than my GPU. Current rumor seems to be 2H 2014, but for all we know that could be December or something. At least it gives NVIDIA time to fix their drivers...
I suspect that it would be a bad idea to downscale luma to 1080p and display chroma 1:1, rather than upscale chroma to 4K and downscale luma & chroma using the same algorithm.
Keeping chroma at 1:1, only shifting it for chroma positioning, and resizing luma-only to match actually increases chroma quality quite a bit. There just has never been a viable reason before 4K that someone would be forced to watch a video at exactly half size.
annovif
19th February 2014, 12:27
There's so many options now that this table would need about twice the presets, many of them would come down to the amount of neurons you could use for NNEDI.
I think that the top quality config would just specify that you should select as many neurons as your GPU allows without frame drops..
But really it's all about what content you play.
Thank you for your answer. For example, with bluray material in chroma settings, i can't decide if it is better jinc3+AR or Needi3:confused: . I can't decide if it is better jinc3+ar+image doubling or Needi3 too :( Have I to think that the sharpest is the best? ehhhmmmm, for me there is a lot of confusion and i'm waiting for a seriuos testing. Has someone the answer?
Thank you, Fabio
6233638
19th February 2014, 12:50
My GTX 770 ($330 USD) can handle that at ~70% GPU load & 30ms render times. It can just barely handle the above with NNEDI3 Chroma Upscaling (64 neurons) added on as well at ~95% GPU load & 40ms render times. With NNEDI3 Chroma Upscaling (32 neurons) you instead have ~80% GPU load & 35ms render times. With higher frame rate content or smooth motion, certain settings would need to be scaled back though.Hmm, maybe I should be waiting until the new generation of cards is out before upgrading then. All of my 720p content is 60fps. (16.67ms)
Keeping chroma at 1:1, only shifting it for chroma positioning, and resizing luma-only to match actually increases chroma quality quite a bit. There just has never been a viable reason before 4K that someone would be forced to watch a video at exactly half size.That's surprising, I would have expected aliasing to be a real problem when displaying chroma 1:1.
leeperry
19th February 2014, 13:11
My GTX 770 ($330 USD) can handle that at ~70% GPU load & 30ms render times.
OK, sounds good!
What remains to be seen is the performance/watt ratio as that BTC study I mentioned earlier made rather clear that nvidia not only costs more for the same OCL performance but also increases the electric bill drastically, but I see that Maxwell would improve on that point.
Oh well, computer stuff is going so fast that one or two years from now, the BTC madness will have more than likely kept growing and we'll be able to get OCL monsters for cheap. Time is on our side, I always feel conned when I buy electronics that end up losing 70% of their value over such a short time span.
DragonQ
19th February 2014, 13:21
I looked into BTC mining a year or so back and back then, even the most cost-efficient AMD GPU (including electricity costs) wasn't worth it. It'd pay for itself in under a year I think, but that assumed that the BTC difficulty wouldn't increase, which was unlikely considering all the new dedicated BTC mining hardware being released. The day of GPU mining may be behind us.
*Touche*
19th February 2014, 13:48
Have you seen AMD prices lately? It is far from over as there are no ASICs for other coins.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.