View Full Version : madVR - high quality video renderer (GPU assisted)
GCRaistlin
30th January 2014, 11:54
Why the picture with madVR is so dark compared to other renderers?
VMR9 renderless (http://i60.tinypic.com/33u9x0l.png)
madVR (http://i60.tinypic.com/28ur90l.png)
Ver Greeneyes
30th January 2014, 12:14
Do you have 13.12 drivers installed? As I wrote in the v0.87.0 announcement post, OpenCL only works with AMD GPUs if you update to the latest drivers.
Ah sorry, I missed this. Unfortunately my laptop's card falls under legacy support, so it is stuck on the 13.9 Legacy Driver. This comes with OpenCL driver version 10.0.937.2 (regular driver 13.12 comes with OpenCL driver version 10.0.1348.5). Enabling error diffusion on my laptop doesn't seem to cause any problems, I just don't know if it's doing anything.
James Freeman
30th January 2014, 12:18
Why the picture with madVR is so dark compared to other renderers?
VMR9 renderless (http://i60.tinypic.com/33u9x0l.png)
madVR (http://i60.tinypic.com/28ur90l.png)
MadVR "stretches" a 16-235 (video) shades of grey to 0-255 (PC).
In video format 16 is the black, in PC 0 is.
What you see in the "VMR9 renderless" picture is black that is not truly black (not equal to 0), while in MadVR its true black.
If you think the blacks are actually clipped (or madvr did not guess correctly),
you can change the input range by pressing Ctrl+Alt+Shift+I while watching your film.
huhn
30th January 2014, 12:38
Why the picture with madVR is so dark compared to other renderers?
VMR9 renderless (http://i60.tinypic.com/33u9x0l.png)
madVR (http://i60.tinypic.com/28ur90l.png)
is the file name something like black 1970 ? are you using 87.4? the black number didn't work in 87.4 only black=number
MadVR "stretches" a 16-235 (video) shades of grey to 0-255 (PC).
In video format 16 is the black, in PC 0 is.
VMR 9 is doing this too
DragonQ
30th January 2014, 13:03
Why the picture with madVR is so dark compared to other renderers?
VMR9 renderless (http://i60.tinypic.com/33u9x0l.png)
madVR (http://i60.tinypic.com/28ur90l.png)
The MadVR output looks correct, the VMR9 one is not using the correct output range.
MSL_DK
30th January 2014, 14:42
OpenCL > 334.67
http://www.avsforum.com/t/1471169/madvr-argyllcms/1440#post_24278588
GCRaistlin
30th January 2014, 14:48
is the file name something like black 1970 ? are you using 87.4? the black number didn't work in 87.4 only black=number
It's "The Seventh Seal" Blu-Ray. I can see the same difference for other videos, too:
http://tinypic.com/m/i2j4tf/4
http://tinypic.com/m/i2j4te/4
And the result is the same for 0.86.1.
The MadVR output looks correct, the VMR9 one is not using the correct output range.
All I can say is the details are lost in madVR picture (see links in the post).
fairchild
30th January 2014, 14:53
Has anybody noticed if there is a visible quality difference between using 32 neurons vs 64 neurons to double Luma resolution with NNEDI3, since in several of my media files it's the difference between increasing/decreasing the rendering times to prevent frame drops.
I guess it would overall be better using NNEDI3 with 32 neurons + Lanczos 3 AR is better than just using Lanczos 3 AR by itself. ;)
Thunderbolt8
30th January 2014, 14:53
OpenCL > 334.67
http://www.avsforum.com/t/1471169/madvr-argyllcms/1440#post_24278588someone should slap them for this.
one thing regarding the trade quality for performance window: maybe it would be more newbie friendly to rename those functions that way that in general always ticking or always unticking the checkbox has the same effect, meaning either lower or higher quality for all options.
James Freeman
30th January 2014, 15:33
OpenCL > 334.67
http://www.avsforum.com/t/1471169/madvr-argyllcms/1440#post_24278588
EDIT:
No It does not work.
nevcairiel
30th January 2014, 15:46
At least should be easy for NVIDIA to fix then. Someone should post that info to the NVIDIA reps.
andybkma
30th January 2014, 15:51
THANK YOU !!!
OpenCL works for NVIDIA now.
I don't think so. I renamed the nvopencl.dll file per the instructions above, unchecked the "use random dithering instead of openCL error diffusion" in the trade quality for performance settings and still get a black screen. Note: Image Doubling options checed or unchecked
asmo42
30th January 2014, 15:58
Hi, as a long time madVR user and lurker here I'd first like to thank Madshi for his work. The new debanding feature is amazing!
While playing around with different image doubling/quadrupling and scaling settings I think I've discovered a bug, unless I'm misunderstanding how it's supposed to work.
If I use NNEDI3 to double a 1280x720 video for output at 1080p it's my understanding that since the doubled resolution is higher than the output resolution no further image upscaling should be necessary. Only the image downscaling algorithm should scale it down to output resolution. However I noticed that the image upscaling setting still affects render times pretty much in the same way as if I didn't do any doubling before. If I switch between two extreme settings like Jinc 8 tap AR and Bicubic the rendering times change dramatically from something like 40 to 60 ms which should be way beyond any margin of error.
I see the same behavior quadrupling a 720x576 PAL DVD to 1080p. Here I further checked with a sharpness test pattern on the Digital video essentials dvd where you normally would easily see the change of scaling algorithms. However while I have NNEDI3 quadrupling active I can't see any change in the picture when I switch image upscaling setting even though it clearly affects the rendering times.
So it seems there might be some unnecessary image scaling going on in combination with the NNEDI3? Again unless I'm misunderstanding how it's supposed to work.
Thunderbolt8
30th January 2014, 15:59
renaming worked for be, but also for me there wasnt a change in gpu load
bjd
30th January 2014, 16:06
Can anyone elaborate what MadVR currently does with 720x576 to produce 1920x1080 using NNEDI - Does NNEDI produce 1440x1152 which then has to be downscaled and then upscaled to fit 1080p ?
andybkma
30th January 2014, 16:25
You need to have two files in C:\Windows\SysWOW64.
1. OpenCL.dll from C:\Program Files\NVIDIA Corporation\OpenCL.
2. nvopencl32.dll which you rename from nvopencl.dll
I have those two files. As reported, doesn't work.
Simply renaming that one file is not going to be the magic opencl fix for nvidia users unfortunately....
huhn
30th January 2014, 16:32
It's "The Seventh Seal" Blu-Ray. I can see the same difference for other videos, too:
http://tinypic.com/m/i2j4tf/4
http://tinypic.com/m/i2j4te/4
And the result is the same for 0.86.1.
All I can say is the details are lost in madVR picture (see links in the post).
no details lost when i watch the "dark" picture with a 3dlut and madvr.
what type of gpu are you using. looks like a this is a simple mismatch with hdmi tv settings and gpu settings.
most likely madvr does nothing wrong.
can you try these samples to make sure? https://www.wuala.com/alluringreality/Public/MP4-2c.7z
source: http://www.avsforum.com/t/948496/avs-hd-709-blu-ray-mp4-calibration
non calibrated display normally always clip black!
nevcairiel
30th January 2014, 16:35
Yeah renaming is bogus. All it does is break OpenCL completely, so that madVR doesn't even try using it anymore - thats why you get an image. But still no OpenCL features.
huhn
30th January 2014, 16:47
Yeah renaming is bogus. All it does is break OpenCL completely, so that madVR doesn't even try using it anymore - thats why you get an image. But still no OpenCL features.
reproduce i inform them in avs...
mimi123
30th January 2014, 18:56
That sounds like you don't need any of the more "expensive" algorithms. So the limiting factor might be the debanding. I guess a budget GPU should do the trick for you. E.g. look at gaming benchmarks and choose the cheapest GPU which has GDDR5 and which has a good performance per price ratio. Of course choosing a more powerful GPU never hurts madVR playback. But that's your decision, really. If you choose an AMD GPU, I would definitely choose a GCN model (7xxx), though, not an older model.
If you ask for a specific model, well I don't know your exact budget. Given your needs, I guess a 7570 or 7670 should probably be fast enough. A 7750 or 7770 would be awesome, probably too fast for your needs, but with some performance headroom left for future algorithms. Of course you can also go with NVidia. If you need a silent GPU, I'd suggest that you read some reviews, so you pick a good/silent model from a specific manufacturer. In any case, pick one with GDDR5, and make sure the price/performance ratio is good.
Very thanks and sorry for the delay in responding. I have been unable to see this forum in the last days. Don't know what was the problem.
Well I'm thinking to buy an AMD HD7750 or similar and I have a question:
It's best new series of ATI R7 and R9 or is the same as HD7000?
I do not want to buy now one card and having to buy another one next year?
I'm reading reviews but this point is not clear for me. They says R7 and R9 series are manufactured with the same chips of HD7000 but have more functions. I don't understand.
Well to the question...
Did I lose any function buying and "old" HD7000? or can I look dollar-performance ratio only?
flashmozzg
30th January 2014, 19:04
Very thanks and sorry for the delay in responding. I have been unable to see this forum in the last days. Don't know what was the problem.
Well I'm thinking to buy an AMD HD7750 or similar and I have a question:
It's best new series of ATI R7 and R9 or is the same as HD7000?
I do not want to buy now one card and having to buy another one next year?
I'm reading reviews but this point is not clear for me. They says R7 and R9 series are manufactured with the same chips of HD7000 but have more functions. I don't understand.
Well to the question...
Did I lose any function buying and "old" HD7000? or can I look dollar-performance ratio only?
AFAIK, R9 290(x) is completely new. 260X is renamed 7790, but they are both built on newer platform (with TrueAudio), and all other R's are rebranded and OC'd versions of 7xxx.
If 7750/70 will be enough for your needs when why bother with newer cards? They'll always come eventually (although probably in more than 1 year from now).
noee
30th January 2014, 19:08
I might be a little off here, but Cape Verde+ (77xx) is GCN. HD7xxx (http://en.wikipedia.org/wiki/Ati_gpu#Southern_Islands_.28HD_7xxx.29_Series)
Bonaire (R7+) is GCN (2.0?), all else is rebrand. Rx 200 (http://en.wikipedia.org/wiki/Ati_gpu#Volcanic_Islands_.28Rx_200.29_Series)
More general naming table (http://xorg.freedesktop.org/wiki/RadeonFeature/#index5h2)
One of the Bonaire versions might be a sweet spot $/perf/watt
leeperry
30th January 2014, 19:22
Can anyone elaborate what MadVR currently does with 720x576 to produce 1920x1080 using NNEDI - Does NNEDI produce 1440x1152 which then has to be downscaled and then upscaled to fit 1080p ?
I agree that some sort of info in the OSD regarding NNEDI scaling would be most welcome.
BTW, I presume that "always - if upscaling is needed" should read "if scaling is bigger than 1.0 and lower than 2.0" for 2X luma and "if scaling is bigger than 2.0" for X4 luma? That's how I'd like to have them set :o
Soukyuu
30th January 2014, 19:28
I kind of don't see any difference between openCL dither and random dither, except for dropped frames :P
Tried dark and light scenes and both seem identical both when paused and playing. Looking at cyberbeing's post back here (http://forum.doom9.org/showthread.php?p=1664757#post1664757), I expected more. Is it only relevant for real-world footage (aka not anime?). I'm restarting the player after a setting change because I notice sometimes the settings don't get applied (image/chroma scaling = yes, openCL -> no openCL = yes, no openCL -> openCL = no).
Also, my screen does not get blank as reported by turbojet here (http://forum.doom9.org/showthread.php?p=1664750#post1664750).
sgraves66
30th January 2014, 19:31
As of v0.87.4, I've been experiencing issues with IVideoWindow::SetWindowPosition(). v0.86.11 and prior have been working fine. It appears that madVR does not consistently respond to each request to set position - video no longer displays, although playback continues, leaving artifacts in the child area as if no painting has occurred. The main window has to be re-sized a few times for it to display again.
Have these implementations changed or should I be using another method for positioning madVR child window?
dansrfe
30th January 2014, 19:40
Assuming infinite GPU resources, what profiles should be created?
DragonQ
30th January 2014, 19:51
I might be a little off here, but Cape Verde+ (77xx) is GCN. HD7xxx (http://en.wikipedia.org/wiki/Ati_gpu#Southern_Islands_.28HD_7xxx.29_Series)
Bonaire (R7+) is GCN (2.0?), all else is rebrand. Rx 200 (http://en.wikipedia.org/wiki/Ati_gpu#Volcanic_Islands_.28Rx_200.29_Series)
More general naming table (http://xorg.freedesktop.org/wiki/RadeonFeature/#index5h2)
One of the Bonaire versions might be a sweet spot $/perf/watt
So only the HD7790, R7 260, and R9 290 are actually using latest generation parts? If so, R7-260 seems great value.
Assuming infinite GPU resources, what profiles should be created?
With infinite GPU resources you shouldn't really need profiles since you can just shove everything on "best" (i.e. NNEDI3 always, plus Jinc3 AR for luma and chroma upscaling, CR AR for downscaling, all quality/performance trade-offs disabled). Profiling is surely to help people whose GPUs can't handle preferred settings all the time. For example, interlaced videos often eat up more GPU juice so require less than optimal settings.
leeperry
30th January 2014, 20:01
CR AR for downscaling
so this will provide the best PQ for downscaling NNEDI? That's what I set during my tests earlier today and I would agree that it looked spectacular.
DragonQ
30th January 2014, 20:12
To a certain extent it depends on personal preference but the consensus is that Jinc3 AR is best for upscaling and CR AR is best for downscaling. NNEDI3 changes things a bit though!
The 8472
30th January 2014, 20:14
Assuming infinite GPU resources, what profiles should be created?
Given infinite GPU resources you run NNEDI with enough neurons so it can start thinking for itself and re-draw the scene for you on a quantum level, in realtime. :p
pirlouy
30th January 2014, 20:56
Which Sammy TV is that? Can it do 4:4:4? I might be looking into getting a new monitor for my development PC. I'm tempted with misusing a TV for that. But 40" does sound a bit large. 30" would be ideal...
As Leeperry said, if you really care about 4:4:4, you have to use specific settings (http://forum.doom9.org/showthread.php?t=169928), then your TV will be in monitor mode, but you'll lose quite all options (including BFI which Leeperry really appreciates :P). In all other modes, you'll be in 4:2:2.
Yep, personally I find 27" too small and 32" a tad too big
Do you mean 32" is too big to watch a movie, or it's just for occasional events ? :eek:
Because in my case, all these shaders settings are nothing compared to watching on a bigger size. I plan on going from 40" to 55".
cyberbeing
30th January 2014, 21:05
I kind of don't see any difference between openCL dither and random dither, except for dropped frames :P
Tried dark and light scenes and both seem identical both when paused and playing. Looking at cyberbeing's post back here (http://forum.doom9.org/showthread.php?p=1664757#post1664757), I expected more.
In my post back there, I took a magnifying glass to each dither to see what they were doing. As madshi mentioned earlier in the thread, with real-world viewing the most he could notice on his projector setup was the lower noise-floor of the OpenCL error-diffusion. If you are unable to notice less temporal noise when you enable OpenCL error-diffusion, you probably aren't getting any realistic benefit from it. madVR random dither has crosstalk by nature, while the OpenCL error-diffusion essentially doesn't yet produces a pattern.
I've personally not yet decided the fate of the OpenCL dither on my setup, but I will say if we didn't have profiles in madVR I'd consider the OpenCL dither worthless. On high resolution displays, high framerate content, and/or Smooth Motion frc enabled, the cost:benefit becomes horrible quite quickly.
Out of all these cases, I believe madVR really could use a trade-quality-for-performance option to disable OpenCL dither when Smooth Motion is active, which is set as the default. Otherwise madshi, you really need to consider modifying the workflow so OpenCL dither is applied before Smooth Motion at original video framerate rather than after at double framerate w/ blended frames.
mindbomb
30th January 2014, 21:10
is error diffusion essentially free if you are already using opencl for nnedi3?
XMonarchY
30th January 2014, 21:17
Hello. I was the one who thought renaming OpenCL .dll files would do the trick because the working OpenCL drivers had a different name and renaming made my black and green screens go away. I still think it may be a naming problem.
New broken-OpenCL 344.67 driver package includes compressed .dl_ files that are actually:
OpenCL32.dll
OpenCL64.dll
NVOpenCL32.dll
NVOpenCL64.dll
nvdisp.inf lists OpenCL.dll and NVOpenCL.dll which are not actually present in driver package, but are simply other .dll files renamed during installation:
OpenCL32.dll --> OpenCL.dll
NVOpenCL64.dll --> NVOpenCL.dll
Older 327.23 working OpenCL driver package includes:
OpenCL.dll
OpenCL64.dll
NVOpenCL32.dll
NVOpenCL.dll
But I have not installed them, so I do not know if those files change their names to something else.
I think its specifically the SysWOW64 NVOpenCL.dll that is being used as its the only one that actually creates a difference when being manipulated. In theory, replacing broken NVOpenCL.dll from a newer set with NVOpenCL.dll from an older working set would do the trick.
How would I know that its working? Would my CPU or GPU utilization sky-rocket? I know it does when I use new drivers and I get a black screen - is that a normal effect for working OpenCL drivers? Its at about 14-16% with GTX 770 when using NVOpenCL.dll from 327.23 drivers. Are you sure that 327.23 driver package does work 100%? I read that the issue has been acknowledged by nVidia - when was that?
It just sucks having to use older drivers since some of us also play games and want the latest drivers. I hope I can eventually get the latest 344.67 drivers to work with OpenCL...
cyberbeing
30th January 2014, 21:43
is error diffusion essentially free if you are already using opencl for nnedi3?
No, it's an added cost.
About NNEDI3 cost in particular, I've noticed that it is actually bottlenecked by the default 224GB/s memory bandwidth @1.2Ghz Core on the GTX 770 when pushed above ~80% GPU load. I need to overclock to ~238GB/s memory bandwidth before the core clock becomes the bottleneck again.
I still think it may be a naming problem.
It's not. The correct name for the OpenCL kernel driver for the system directories on Nvidia is nvopencl.dll. They have different names in the driver package since one is for 64bit applications (System32 dir) and the other is for 32bit applications (SysWoW64 dir). Since Nvidia packages them in the same Display.Driver folder, they would have naming conflict otherwise.
The nvopencl.dll also contains a version compatibility check, and will not function with libraries from other driver versions. (I actually tested this last week).
How would I know that its working?
Open GPU-Z. If OpenCL is not checked, then you've broken OpenCL support in the driver.
The more time consuming way to test this, is to do the following:
Disabled OpenCL features
Close madVR
Open RegEdit
Delete HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL if it exists
Play video with madVR
Enabled OpenCL features
Refresh HKEY_CURRENT_USER\Software\madshi\madVR key.
If OpenCL driver support does not exist, the HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL key will not be re-created with a Binary OpenCL kernel, Driver Version, and Checksum under a subkey with your GPU name.
Gagorian
30th January 2014, 22:05
Is it normal that OpenCL error diffusion increases average rendering time 3x? My GPU is a r9 270 (basically a 7870?) and using latest madVR.
I tried playing a few 1080p24 standard x264 blu-ray movies presented at 23.976 Hz.
Average rendering time (using Jinc 3 AR for both Luma and Chroma, Debanding low, all trade quality for performance options except OpenCL error diffusion disabled) was around 8-10 ms. The rendering time is about the same for 720p movies, so scaling for instance is rather cheap even with Jinc 3 AR.
With OpenCL error diffusion the average rendering time was raised to around 28-30 ms.
Should it really be that demanding?
DragonQ
30th January 2014, 22:08
Reports so far suggest that OpenCL Error Diffusion is indeed very demanding. Can't imagine most people can even use it.
leeperry
30th January 2014, 22:32
Reports so far suggest that OpenCL Error Diffusion is indeed very demanding. Can't imagine most people can even use it.
Madshi said that it wasn't all that demanding on his 7770(or was it 7790?) and I can confirm that it's a breeze on my factory overclocked 7850.
Do you mean 32" is too big to watch a movie, or it's just for occasional events ? :eek:
Because in my case, all these shaders settings are nothing compared to watching on a bigger size. I plan on going from 40" to 55".
32" for a monitor when you stand like 80 cm away is a tad too big to my taste and as yesgrey said a long time ago vision is very demanding to the human brain, I happen to care as much for audio as I care for video so I prefer a display that's on the small side. The biggest and cheapest tweak to audio nirvana is to shut your eyes: http://www.mymusicmask.com/en/home.html :D
I've tried a few 50 inchers but defects became way too visible from a 2 meters distance and my brain was simply unable to focus on audio anymore. I remember that when I used to own a videoprojector it took me a lot of concentration to equally enjoy audio and video.
bjd
30th January 2014, 22:45
I agree that some sort of info in the OSD regarding NNEDI scaling would be most welcome.
BTW, I presume that "always - if upscaling is needed" should read "if scaling is bigger than 1.0 and lower than 2.0" for 2X luma and "if scaling is bigger than 2.0" for X4 luma? That's how I'd like to have them set :o
Yeah, I would like to see the res after NNEDI3 shown say below the movie resolution.
The more I think about it, I assume to get 576P -> 1080P without downscale/upscale you need to quadruple the image size to 2880x1152 (assuming the height is only doubled twice as it is over the target resolution) and then downscale (CR AR LL) to 1080p.
cyberbeing
30th January 2014, 22:53
Madshi said that it wasn't all that demanding on his 7770(or was it 7790?) and I can confirm that it's a breeze on my factory overclocked 7850.
It's partially a matter of perspective I believe. madshi's numbers showed it increased his relative render times by 400% when he enabled OpenCL dither compared to his previous settings. This could likely be interpolated into 400% higher GPU load and power draw. That said, I have no doubt it will perform well on AMD Southern Islands based GPUs, since that's what he optimized it for. madshi's numbers for the absolute render time cost of enabling openCL dither on his AMD 7770 (80W TDP, 1.3 TFLOP) @1680x1050, seems nearly identical to the numbers of my much higher powered GTX 770 (230W TDP, 3.2 TFLOP) @1680x1050, assuming he tested with smooth motion disabled.
I see madshi's argument of it not being *that* demanding, as more of a statement that it should still be usable based on absolute render time increases, which I'd agree with. If you want to use NNEDI3 as well, or have a weaker GPU already being pushed very hard before the OpenCL stuff, all bets are off.
pirlouy
30th January 2014, 23:11
http://www.mymusicmask.com/en/home.html :D
Very funny link ! :D
I though people always wanted a bigger image, but you proved me wrong. :eek:
iSunrise
30th January 2014, 23:45
madshi, I have a bug to report with 0.87.4 (yes, finally, the week end nears, so I have more time to test):
Thereīs something wrong with chroma upscaling, even when using the Nvidia 327.23 drivers, as I get a yellow/greenish image instead of levels of grey (not sure if this is only NV related, donīt have an AMD at my disposal atm) when you enable chroma upscaling and you choose NNEDI3.
Steps to reproduce is pretty easy, just enable chroma upscaling NNEDI3 and it should show in windowed mode or in FSE. It also doesnīt matter how many neurons. I really hope this isnīt exclusively NV-related again, because this is using OpenCL.
For some reason, this is only happening on some files, example:
http://www.w6rz.net/filmrez.zip
This is with a GTX580 with the last working OpenCL drivers as of today (327.23).
nevcairiel
30th January 2014, 23:45
Otherwise madshi, you really need to consider modifying the workflow so OpenCL dither is applied before Smooth Motion at original video framerate rather than after at double framerate w/ blended frames.
Didn't this question come up just a few pages back already, possibly also by you? :)
You simply cannot do dithering any earlier, it HAS to be the very last step in the rendering pipeline, after any and all image processing. Doing dithering at any other time will do two things: Make dithering less effective, and reduce the quality of any following rendering steps - both things you definitely do not want.
iSunrise
30th January 2014, 23:54
Iīve made some simple profiles to test various settings on my GPU, but for some reason, madVR always selects one particular profile irregardless of the source. madVR always shows the active profile "1080p LowFPS" (with bold black characters) on all sources.
if (srcHeight <= 576) "576p"
else if (srcHeight = 720) "720p"
else if ((srcHeight > 720) and
(srcHeight <= 1080) and
(srcFps <= 50)) "1080p LowFPS"
else if ((srcHeight > 720) and
(srcHeight <= 1080) and
(srcFps > 50)) "1080p HighFPS"
Is there an error in my code somewhere, because madVR tells me itīs ok (green arrow).
EDIT:
Found the problem, for some reason, I needed to edit that to:
else if ((srcHeight > 720) and
(srcHeight <= 1080) and
(srcFps < 50)) "1080p LowFPS"
else if ((srcHeight > 720) and
(srcHeight <= 1080) and
(srcFps >= 50)) "1080p HighFPS"
I still cannot see an error in my code though, does anyone see a problem? If not, is this a bug madshi?
cyberbeing
31st January 2014, 00:00
Didn't this question come up just a few pages back already, possibly also by you? :)
You simply cannot do dithering any earlier, it HAS to be the very last step in the rendering pipeline, after any and all image processing. Doing dithering at any other time will do two things: Make dithering less effective, and reduce the quality of any following rendering steps - both things you definitely do not want.
I did ask something like this earlier, but I'm not fully understanding. I thought madVR dithered the video much earlier during TV->PC levels conversion, YCbCr -> RGB conversion, and 3DLUT processing, which I would have thought came before Smooth Motion FRC takes place. It seems like for the frame blending to be most effective, it would need to occur on final post-processed video frames. What exactly is being dithered after frame blending occurs? It certainly can't be all dithering procedures required by madVR, and is probably only the dithering down to 8bit?
DragonQ
31st January 2014, 00:13
Madshi said that it wasn't all that demanding on his 7770(or was it 7790?) and I can confirm that it's a breeze on my factory overclocked 7850.
Maybe it's best on AMD GPUs. Intel ones certainly aren't good enough to do it, but obviously they're lower-end.
The biggest and cheapest tweak to audio nirvana is to shut your eyes: http://www.mymusicmask.com/en/home.html :D
True but $45 for a blindfold? Hahahaha.
nevcairiel
31st January 2014, 00:17
I did ask something like this earlier, but I'm not fully understanding. I thought madVR dithered the video much earlier during TV->PC levels conversion, YCbCr -> RGB conversion, and 3DLUT processing, which I would have thought came before Smooth Motion FRC takes place. It seems like for the frame blending to be most effective, it should need to occur on final post-processed video frames. What exactly is being dithered after frame blending occurs? It certainly can't be all dithering procedures required by madVR, and is probably only the dithering down to 8bit?
There should only be one dithering process, which reduces the internal 16-bit floating point pixels down to 8-bit integer, and this should be done as the very last step, because the output of this process is in much lower bitdepth, namely 8-bit pixels.
Everything before dithering should use a higher internal precision, so that no data accuracy is ever lost. Dithering destroys data. It destroys less data then pure rounding, but it still destroys data (but you need to destroy some data if you go 16->8 bit). You don't want to do it multiple times, or too early, or you lose more data then you would want.
Why would you dither after RGB conversion? Why not simply keep high precision pixels around? :)
If you dither once with random dither, the additional image noise is already in the image. If you then even upscale that image, you also upscale the noise, that could result in rather obvious noise artifacts.
iSunrise
31st January 2014, 00:19
I did ask something like this earlier, but I'm not fully understanding. I thought madVR dithered the video much earlier during TV->PC levels conversion, as well as YCbCr -> RGB conversion, which I would have thought would come before Smooth Motion FRC takes place. What exactly is being dithered after frame blending occurs?
Why would you do this? You should only process the final (16bit) image to your RGB output bitdepth (display), otherwise you would lose a lot of accuracy, which then would be processed again. Or do I not understand your question correctly?
When you work in a DAW, everything should be a itīs highest bitrate possible before the final dithering (mastering), since every processing step reduces your headroom.
DragonQ
31st January 2014, 00:21
I wonder if dither is used twice when you tick the options to use 10-bit buffers rather than 16-bit?
nevcairiel
31st January 2014, 00:23
I wonder if dither is used twice when you tick the options to use 10-bit buffers rather than 16-bit?
More likely all calculations are just only done in 10-bit, which loses a bit of precision. Since its a option also meant to speed up rendering, its doubtful extra dithering steps would be involved.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.