View Full Version : madVR - high quality video renderer (GPU assisted)
madshi
31st December 2010, 16:16
I also get a +1" delay
What does +1" mean?
How do you know what causes this delay? log?
I've just tried to click 3 times in a row
Click on what? leeperry, *PLEASE* try to be a bit more detailed in your posts. It's really a pain that I have to ask you back 2 questions for every new posts of yours.
if SmoothL were using any kind of gamma tweak, it'd show on gray levels test patterns...and it doesn't.
You told me that what SmoothLevel does is explained here:
http://forum.doom9.org/showpost.php?p=528197&postcount=14
Read it yourself, carefully. This is gamma tweaks, nothing else. As I said before, with a properly calibrated display doing such gamma tweaks will make the image quality worse, not better.
ajp_anton
31st December 2010, 16:46
The size of the queues is currently fixed, maybe I'll make that adjustable in a future build. "7-8 / 8" means that since the last OSD update (it updates once per second, IIRC) the queue was always in the range 7-8 (out of 8). The backbuffer queue is a Direct3D queue for frames soon to be presented.Well the "-8" doesn't make much sense. Or it would if it worked correctly, but it seems it doesn't.
If I watch a 1080p movie (to maximize rendering time) and seek, it will go from "0-8" to "[1-7]-8" and then "7-8". That "-8" never changes.
The backbuffer question was badly formulated...
What does the backbuffer queue option do in the settings? It doesn't seem to change anything, it's always "/ 3" in the OSD.
leeperry
31st December 2010, 16:52
What does +1" mean?
in the audio world, " means second and ' minute. so it should have read "more than one second"...most likely one and a half second.
How do you know what causes this delay? log?
How should I know? I click on "edit settings" and it takes a second and a half before the big "madVR settings" window shows up. Sometimes it fails instantly, and I just get the error msg I captured above.
here's a log, I've clicked several times on "edit settings"(and then closed the "madVR settings" window each time), they all took more than one second to display the "madVR settings" window, the last attempt in the log failed and I got this error msg I captured above: http://www.mediafire.com/?zfxmh0rbzcbz5k9
I thought the delay was normal..it seemed to be expected behavior as far as I'm concerned.
You told me that what SmoothLevel does is explained here:
http://forum.doom9.org/showpost.php?p=528197&postcount=14
No, I never said anything like that...I said that LaTo more or less explained that his plugin boiled down to what was discussed in that thread. Reclock works wonders, yet Slysoft bought it off ogo(the original coder) to gain its secrets. Noone knows what Reclock does for sure...mostly messing w/ the graph masterclock? but how? SmoothL is the same story, what it does isn't documented as far as I can see...reason why I said I'd use some black>white gradients to see what it does IRL, and compare it against mVR and ColorYUV when going TV>PC.
janos666
31st December 2010, 17:09
http://www.pixelz.fr/a/b/9/f435aefd673b5f74437ecfcbb0700.png
As I can remember, this error message started to appear for me with this (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2730) MPC-HC build.
I forgot to report it because I waited for somebody who also has this problem.
in the audio world, " means second and ' minute.
Not only in the audio world (10˙11'12" can also mean an angle with 10 degree 11 minute 12 second) but I couldn't understand it either. :stupid:
madshi
31st December 2010, 17:19
Well the "-8" doesn't make much sense. Or it would if it worked correctly, but it seems it doesn't.
If I watch a 1080p movie (to maximize rendering time) and seek, it will go from "0-8" to "[1-7]-8" and then "7-8". That "-8" never changes.
What's wrong with that? Looks all alright to me.
What does the backbuffer queue option do in the settings? It doesn't seem to change anything, it's always "/ 3" in the OSD.
More than 3 is only supported in Vista and Windows 7. Direct3D in XP is limited to max 3 backbuffers.
How should I know? I click on "edit settings" and it takes a second and a half before the big "madVR settings" window shows up. Sometimes it crashes instantly, and I just get the error msg I captured above.
That's a totally different delay to what yesgrey and I were talking about.
I thought the delay was normal..it seemed to be expected behavior as far as I'm concerned.
Doesn't happen for me. Not sure where that delay comes from on your PC. Is your PC/CPU busy while you open up the settings dialog?
No, I never said anything like that...I said that LaTo more or less explained that his plugin boiled down to what was discussed in that thread.
Well, that thread discusses gamma tweaks, nothing else. So if LaTo says that his plugin boils down to that thread, then obviously LaTo's plugin boils down to gamma tweaks. End of story.
Reclock works wonders, yet Slysoft bought it off ogo(the original coder) to gain its secrets. Noone knows what Reclock does for sure...
I do know what it does.
SmoothL is the same story, what it does isn't documented as far as I can see...reason why I said I'd use some black>white gradients to see what it does IRL, and compare it against mVR and ColorYUV when going TV>PC.
It obviously applies gamma tweaks. Which means that it's doing different things than madVR and ColorYUV. So comparing them wouldn't make much sense - unless you can deactivate the gamma tweaks and only use the level conversion.
madshi
31st December 2010, 17:23
As I can remember, this error message started to appear for me with this (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2730) MPC-HC build.
I forgot to report it because I waited for somebody who also has this problem.
How often does it appear? Just once in a while? Or all the time? Does it only happen if you open the settings dialog through MPC HC? Or does it also happen if you open the settings dialog through the madVR tray icon menu?
madshi
31st December 2010, 17:24
madVR v0.36 released
http://madshi.net/madVR.zip
* fixed: settings changes only showed affect after reloading the video
* fixed: Ctrl+Y didn't work properly, anymore
* hopefully fixed: madVR startup delay on some PCs
leeperry
31st December 2010, 17:35
:thanks: for the new build!
Doesn't happen for me. Not sure where that delay comes from on your PC. Is your PC/CPU busy while you open up the settings dialog?
Can you see in the log I just provided why it failed the last time, and gave this error msg? Even w/ nothing in the back and the movie paused, it still takes more than one second...as if it were trying some network stuff that's being blocked or been disabled.
Well, that thread discusses gamma tweaks, nothing else. So if LaTo says that his plugin boils down to that thread, then obviously LaTo's plugin boils down to gamma tweaks.
There's several Smodes in SmoothL and you can finetune the dithering strength, I'll try to come back w/ some meaningful comparisons.
goldie
31st December 2010, 17:41
Thanks for your hard work and happy new year to you, madshi. :)
janos666
31st December 2010, 17:57
How often does it appear? Just once in a while? Or all the time? Does it only happen if you open the settings dialog through MPC HC? Or does it also happen if you open the settings dialog through the madVR tray icon menu?
It often appears when I open the settings dialog (but not always). But I could see it randomly sometimes.
Another strange thing: I start the playback, go to fullscreen (exclusive), and the playback often freezes after ~30 sec (not always but usually). If I am lucky, I can pause and resume the playback and watch a full movie without any other problems. But if I am not fast enough, I have to close the mpc-hc.exe from the task manager and try again.
Edit: 0.36 didn't solve it. I got this message 2/5 times when I tried to open the settings panel.
Edit2: Yes, it's better to open the settings panel with the try icon. I had it disabled because it's useless for me.
THX-UltraII
31st December 2010, 17:58
Well, some movies are also encoded that way. So the better way is to test with something you know is smooth by itself (like banding.png).
Just came home from work and checked the file on my pc. It seems that it s not 100% smooth. I can see some vertical lines appear that al have the same distance from one to another. There are best noticed in the area that s left to the middle. It could also be the resolution of the picture that doesn't seem so high.....
ajp_anton
31st December 2010, 18:06
What's wrong with that? Looks all alright to me.Nevermind, I still haven't really woken up.
More than 3 is only supported in Vista and Windows 7. Direct3D in XP is limited to max 3 backbuffers.
I could've sworn that it stayed at 3 when I lowered it to 1 and 2, but must've dreamt.
Hope I'm not dreaming this too, but I'm using Windows 7, and 3 is max I can get.
cyberbeing
31st December 2010, 18:27
Btw, happy to see you back on the forum. Haven't see you for a while. Have you tried the latest madVR builds yet? IIRC the last time you posted exclusive mode wasn't even implemented yet! Does exclusive mode work well for you? FWIW, I've not yet implemented the final presentation logic for exclusive mode, so there's still room for improvement.
I got overly frustrated with the 3DLUT slowdown issue so I felt a need to take a break from Doom9 for awhile... In the time since, I've pretty much given up on using madVR with a 3DLUT, since I'm unable to use it reliably. Recently, I seem to run into a new scene which causes massive frame drops at least once a week. Unless you have any new insight as to why these rendering spikes happen on NVIDIA cards, I assume the problem is still unsolvable? :(
MadVR Exclusive Mode is also completely broken with my 7800GTX 512 / WinXP / 96-120Hz CRT computer. It's kind of hard to describe, but it's like parts of a frame are being presented with parts of different frames at the same time, and multiple segments of the frame vibrate back and forth and tear whenever the frame moves. Without exclusive mode I still get near-perfect smoothness with my settings, so I've not been hung up about exclusive mode.
With the ATI 5750 / Win7 / 60Hz LCD computer, exclusive mode seems to be the only thing which plays relatively smooth. Without exclusive mode, I get tearing, no matter what the settings.
On an unrelated note, what triggers the '1 frame repeat/drop every XX.XX' in stats?
23.976 video with Reclock and a 96.00050hz refresh, it seems to bounce around between dropping or repeating between 2 days, 3 days, 6 days, and 1.#J days (infinite days?).
23.976 video without Reclock and a 96.00050hz refresh, it seems to say it will repeat 1 frame every 30-40 seconds.
23.976 video with Reclock and a 95.90409hz refresh, it seems to bounce around between dropping or repeating between 1-2 days.
23.976 video without Reclock and a 95.90409hz refresh, it seems to say it will repeat 1 frame every 8-10 minutes.
23.976 video and a 90hz refresh, nothing about dropping repeating frames appears at all. So I assume it only shows when it thinks the refresh rate is an exact multiple of the source video?
Are these stats accurate? If so, it seems Reclock is a requirement if you don't want madVR to drop or repeat frames. I would have expected a 95.90409hz (24000/1001 x 4 = 95.90409) refresh without Reclock to be better then the above.
There is also a Reclock/madVR bug with when the madVR source filter reports a frame rate of 23.810 (23.976 MKV muxed without framerate set) which exists in both 0.34 & 0.35. The problem was readily apparent in 0.34 which listed the optimal refresh rate in stats (why was this removed in 0.35? It was useful for seeing the adjusted framerate with Reclock as well as VFR video). Even though Reclock correctly detects the real framerate of 23.976 and changes the framerate to match the refresh rate, madVR isn't detecting any change and still assuming (forcing?) the video is playing back at an incorrect 23.810 fps. This causes madVR to report the same '1 frame repeat every 6.5 seconds' whether Reclock is enabled or not. For comparison, Reclock and VMR9 have no such problem. While this is somewhat an oddball issue, you may still want to fix it.
I've also run into a minor issue in recent versions of madVR where pressing CTRL-J to hide/show the stats seems to cause a couple frames drops.
madshi
31st December 2010, 22:07
Can you see in the log I just provided why it failed the last time, and gave this error msg? Even w/ nothing in the back and the movie paused, it still takes more than one second...as if it were trying some network stuff that's being blocked or been disabled.
The log is only written by the madVR renderer, not by the settings dialog nor the tray icon stuff nor by the madHcNet.dll, so the log is mostly only useful for the core renderer.
Does the delay still happen the same way with v0.36?
It often appears when I open the settings dialog (but not always). But I could see it randomly sometimes.
Edit: 0.36 didn't solve it. I got this message 2/5 times when I tried to open the settings panel.
Edit2: Yes, it's better to open the settings panel with the try icon. I had it disabled because it's useless for me.
How often does the problem occcur when you open the settings through the tray icon?
Another strange thing: I start the playback, go to fullscreen (exclusive), and the playback often freezes after ~30 sec (not always but usually). If I am lucky, I can pause and resume the playback and watch a full movie without any other problems. But if I am not fast enough, I have to close the mpc-hc.exe from the task manager and try again.
This might have been an issue with 0.34 which might have been fixed with 0.35. Does the problem still occur with 0.35+?
Just came home from work and checked the file on my pc. It seems that it s not 100% smooth. I can see some vertical lines appear that al have the same distance from one to another. There are best noticed in the area that s left to the middle. It could also be the resolution of the picture that doesn't seem so high.....
The resolution of the picture should be fine, it's exactly 1920x1080. Are you sure that you watched the image at 100% zoom with no scaling done? Maybe try two different image viewers, just to be safe. If you still see those vertical lines then something is wrong and needs to be fixed, for best image quality.
I could've sworn that it stayed at 3 when I lowered it to 1 and 2, but must've dreamt.
Hope I'm not dreaming this too, but I'm using Windows 7, and 3 is max I can get.
I think in exclusive mode it's always 3, but I'm not sure right now. The support for more than 3 backbuffers is currently broken, it will be reintroduced in a future version.
I got overly frustrated with the 3DLUT slowdown issue so I felt a need to take a break from Doom9 for awhile... In the time since, I've pretty much given up on using madVR with a 3DLUT, since I'm unable to use it reliably. Recently, I seem to run into a new scene which causes massive frame drops at least once a week. Unless you have any new insight as to why these rendering spikes happen on NVIDIA cards, I assume the problem is still unsolvable? :(
The 7800GTX is about 5 years old now. Maybe with a newer card it wouldn't occur? Anyway, I still have hope that maybe the final fullscreen exclusive presentation logic will take care of this, but I don't really know. I plan to implement the final exclusive solution soon. So if you have a couple of weeks more patience, you can try again.
MadVR Exclusive Mode is also completely broken with my 7800GTX 512 / WinXP / 96-120Hz CRT computer. It's kind of hard to describe, but it's like parts of a frame are being presented with parts of different frames at the same time, and multiple segments of the frame vibrate back and forth and tear whenever the frame moves.
That's weird, nobody else seems to have this problem. But here I also think that the final fullscreen presentation logic might fix the problem.
Do fullscreen games play without these problems, at 96-120Hz?
On an unrelated note, what triggers the '1 frame repeat/drop every XX.XX' in stats?
23.976 video with Reclock and a 96.00050hz refresh, it seems to bounce around between dropping or repeating between 2 days, 3 days, 6 days, and 1.#J days (infinite days?).
23.976 video without Reclock and a 96.00050hz refresh, it seems to say it will repeat 1 frame every 30-40 seconds.
23.976 video with Reclock and a 95.90409hz refresh, it seems to bounce around between dropping or repeating between 1-2 days.
23.976 video without Reclock and a 95.90409hz refresh, it seems to say it will repeat 1 frame every 8-10 minutes.
Are these stats accurate? If so, it seems Reclock is a requirement if you don't want madVR to drop or repeat frames. I would have expected a 95.90409hz (24000/1001 x 4 = 95.90409) refresh without Reclock to be better then the above.
The estimation of dropped/repeated frames is based on the measured refresh rate, the source framerate and the measured audio clock deviation. Since you didn't tell me which clock deviation madVR measured I can't say much right now.
With Reclock enabled it's pretty clear that madVR will report that frame drops/repeats will occur very seldomly because Reclock will adjust the audio clock so that no frame drops/repeats will be necessary. That's how Reclock works.
With Reclock disabled, obviously you need to try to match source framerate and GPU refresh rate as well as possible. You should aim to get to one frame drop/repeat every 3 hours or so.
23.976 video and a 90hz refresh, nothing about dropping repeating frames appears at all. So I assume it only shows when it thinks the refresh rate is an exact multiple of the source video?
Correct.
There is also a Reclock/madVR bug with when the madVR source filter reports a frame rate of 23.810 (23.976 MKV muxed without framerate set) which exists in both 0.34 & 0.35.
madVR is a renderer, not a source filter. The "frame rate" is simply taken from the information the decoder sent to madVR. So if madVR shows a wrong frame rate, it's the fault of the decoder (or splitter). madVR is just reporting what the decoder reported to madVR.
You can double check that yourself: In MPC HC when you get the wrong frame rate in the madVR OSD, do this:
(1) pause playback
(2) right click -> filters -> madVR
(3) go to "pin info" tab
(4) for the "input" pin look at "AvgTimePerFrame: xxx"
This information field is what madVR looks at for reporting the frame rate. This field is set by the decoder, madVR just accepts it as it is. This field should be set to "10000000 / framerate". So for 23.976 it should be "10000000 / (24 / 1.001) = 417083".
deptel
1st January 2011, 01:52
Not sure if this is a new error from this version.
I just upgraded my HD 6870 to crossfire, and it seems to cause a huge issue with 0.26, (never got to test with xfire on 0.24 or less, and cant find any DL links to check), basicly making a huge jittery mess of anything in fullscreen exlusive mode (every frame seems to jitter, some artifacts and skipping.
Totally fine if I change from madVR to EVR custom or any other renderer, also the problem goes away if I disable crossfire.
I tried disabling everything one by one, enabling everything one by one, changing between all scaling algorhythmns, but only one that changed anything was Number of BackBuffers, when lowered to 1, makes the problem much lesser (only jitters every few seconds), but I didnt belive it effected fullscreen exclusive. It's also caused my system to hard lock when entering fullscreen exclusive a few times.
First time ive ever had a issue with madVR after a long time of using.
leeperry
1st January 2011, 01:58
The log is only written by the madVR renderer, not by the settings dialog nor the tray icon stuff nor by the madHcNet.dll, so the log is mostly only useful for the core renderer.
No change w/ 0.36, still 1.5 second between clicking the "edit settings" button and getting the "madVR settings" window to show up.
What happens exactly when you click this button? because my XPSP3 box is really stripped to the bone network connectivity-wise...besides I have yet to understand the point of all that network stuff, like who cares about changing the language of the soundtrack/subs from a distant computer? but well, you're the boss http://forum-images.hardware.fr/images/perso/5/oh-la-vache-eh.gif
mark0077
1st January 2011, 02:48
Madshi. Is it correct for madvr to take the incoming framerate information from the decoder because many filters between the decoder and renderer can change the frame rate. Eg I'm now using avisynth scripts and yadif in ffdshow. Both of which change the frame rate so reading from the last filter seems more accurate / correct than reading from the decoder? What do you think.
robpdotcom
1st January 2011, 04:34
like who cares about changing the language of the soundtrack/subs from a distant computer?[/IMG]
I thought that at first too, but there are some cool things you can do with it:
Changing algorithms/levels/subs/etc without from a laptop > no exiting FSE mode, and without bringing up any menus on the screen. It came in handy just a few nights ago when watching "Salt" with some friends: I realized I had forgotten to set the forced subs to auto-load, and was able to turn them on from my laptop without interrupting the movie.:cool:
I've even been able to exit a frozen MPC-HC via madHcCtrl, when in FSE mode, and otherwise only CTRL+ALT+DELETE would work.
pie1394
1st January 2011, 05:03
0.36 finally gives me better and stable seeking experience again since any previous 0.3x came out. Good job! :thanks:
With 0.35 on my C2D P8600 + Ion 9300M + WIn7 x64 + Forceware 260.99, it is randomly unable to play the 1080p24 film contents (H.264 in MKV) stably at 60Hz monitor output. Went back to 0.34 or advance to 0.36, and it just works fine.
The "madVR instance didn't reply properly." dialog still happens on 0.36 randomly. I found it is easy to reproduce this. Just click the "Edit Settings" button quickly after the setting menu is closed. Repeat it several times, and it will get the chance to show this result.
But I didn't have the experience of 1.5 second delay to open the setting dialog which happens to some guys.
cyberbeing
1st January 2011, 07:03
The 7800GTX is about 5 years old now. Maybe with a newer card it wouldn't occur? Anyway, I still have hope that maybe the final fullscreen exclusive presentation logic will take care of this, but I don't really know. I plan to implement the final exclusive solution soon. So if you have a couple of weeks more patience, you can try again.
Yeah, when I tested a GTX 470 awhile back, it still got the rendering spikes in the same problem areas, but it was powerful enough to muscle through them. I'm somewhat doubtful it has anything to do with presentation logic, but you never know. As a mentioned previously, the rendering lag seems to be triggered when only when there are a lot of out-of-gamut pixels on a HD frame scaled/displayed around 1920x1080 or so (displaying at lower resolutions can fix the slowdown). Such occurrence usually only happen for few seconds, and always repeatable on the problem sections of videos.
That's weird, nobody else seems to have this problem. But here I also think that the final fullscreen presentation logic might fix the problem.
Do fullscreen games play without these problems, at 96-120Hz?
No clue why it's so broken on my card. Fullscreen games do play fine, so that is not at issue. It's not related to high refresh rates either, as the same thing happens at 60hz. I guess I could try updating my nvidia driver and see if that makes any difference.
Edit: madVR Fullscreen exclusive is still broken after updating drivers.
The estimation of dropped/repeated frames is based on the measured refresh rate, the source framerate and the measured audio clock deviation. Since you didn't tell me which clock deviation madVR measured I can't say much right now.
With Reclock enabled it's pretty clear that madVR will report that frame drops/repeats will occur very seldomly because Reclock will adjust the audio clock so that no frame drops/repeats will be necessary. That's how Reclock works.
For 23.976 video at 95.90409Hz and a clock deviation of around -0.00600 it reports frame repeats every ~10 mins. With Reclock the clock deviation changes to around -0.00010 with repeats every 1-6 days.
For 23.976 video at 96.00050Hz and a clock deviation of around -0.00500 it reports frame repeats every ~40 seconds. With Reclock the clock deviation changes to around 0.10050 with repeats every ~13 hours to 6 days.
With Reclock disabled, obviously you need to try to match source framerate and GPU refresh rate as well as possible. You should aim to get to one frame drop/repeat every 3 hours or so.
I'm a bit confused by this statement. Isn't a madVR reported refresh rate of 95.90409 a perfect match for 23.976 video? You can't get any more perfect then that, yet it still reports frame repeats every few minutes. Is this being caused by clock deviation alone? If so, what could I do to fix it without using Reclock?
madVR is a renderer, not a source filter. The "frame rate" is simply taken from the information the decoder sent to madVR. So if madVR shows a wrong frame rate, it's the fault of the decoder (or splitter). madVR is just reporting what the decoder reported to madVR.
In madVR 0.34, how was the ideal refresh rate being calculated then? If my refresh rate was 96.000Hz without Reclock it would report 23.97500, with Reclock it would report 24.00010, detecting the adjusted framerate.
You can double check that yourself: In MPC HC when you get the wrong frame rate in the madVR OSD, do this:
(1) pause playback
(2) right click -> filters -> madVR
(3) go to "pin info" tab
(4) for the "input" pin look at "AvgTimePerFrame: xxx"
This information field is what madVR looks at for reporting the frame rate. This field is set by the decoder, madVR just accepts it as it is. This field should be set to "10000000 / framerate". So for 23.976 it should be "10000000 / (24 / 1.001) = 417083".
Yes, the AvgTimePerFrame reported by the splitter indicates 23.810, but the video is actually 23.976 and Reclock adjusts the framerate to match refresh. Usually madVR has no issues with things like VFR, and framerates different then the what the splitter reports, but this time it does. All in all it's not that big of deal since you can easily fix it by re-muxing the video and specifying the framerate.
webs0r
1st January 2011, 09:40
the rendering lag seems to be triggered when only when there are a lot of out-of-gamut pixels on a HD frame scaled/displayed around 1920x1080 or so (displaying at lower resolutions can fix the slowdown). Such occurrence usually only happen for few seconds, and always repeatable on the problem sections of videos.
Hey cyberbeing can you tell whether these sections are "on average" higher bitrate than others sections that work fine? Are you streaming off a networked computer?
cyberbeing
1st January 2011, 09:54
Problem sections don't have a significantly higher bitrate then surrounding video and playback is done off a local drive. Everything seems to point towards Nvidia cards applying madVR 3DLUT adjustments on a pixel-by-pixel basis, instead of the whole frame at once, which is why it only has issues on large frame sizes like 1920x1080 (or smaller frames resized to such resolutions), but not so much 1280x720. For whatever reason it seems NVIDIA cards must have a limitation on the number of pixels which the lut can be applied, and it hits a processing bottleneck.
I'd be somewhat interested if this is just an issue with 16 bit buffers and high-precision processing or something.
THX-UltraII
1st January 2011, 10:28
The resolution of the picture should be fine, it's exactly 1920x1080. Are you sure that you watched the image at 100% zoom with no scaling done? Maybe try two different image viewers, just to be safe. If you still see those vertical lines then something is wrong and needs to be fixed, for best image quality.
i opended it with paint and media center also. still the same problem. one thing i should note:
i test it on a jvc rs20 projector where things are a lot larger than on a tv or pc monitor. are you sure there are no vague vertical lines that can be seen?
madshi
1st January 2011, 10:57
I just upgraded my HD 6870 to crossfire, and it seems to cause a huge issue with 0.26, (never got to test with xfire on 0.24 or less, and cant find any DL links to check), basicly making a huge jittery mess of anything in fullscreen exlusive mode (every frame seems to jitter, some artifacts and skipping.
"0.26"? You mean 0.36, I guess?
What happens if you disable the exclusive mode? Does it work fine in fullscreen windowed mode?
Madshi. Is it correct for madvr to take the incoming framerate information from the decoder because many filters between the decoder and renderer can change the frame rate. Eg I'm now using avisynth scripts and yadif in ffdshow. Both of which change the frame rate so reading from the last filter seems more accurate / correct than reading from the decoder? What do you think.
Well, my reply wasn't technically correct. I said madVR takes the info from the decoder because the decoder is usually the last filter. Actually madVR takes the info from the madVR input pin's media type, which is what the last filter tells madVR.
FWIW, currently this frame rate information is only used informationally, it is not used to make any rendering decisions. In a future version I might add code to analyze the timestamps of the incoming frames in order to figure out myself which frame rate the video has, instead of relying on the input pin's media type info.
who cares about changing the language of the soundtrack/subs from a distant computer?
I do. I use it every day. I'm writing madVR for my own needs just as much as for everyone else.
0.36 finally gives me better and stable seeking experience again since any previous 0.3x came out. Good job! :thanks:
With 0.35 on my C2D P8600 + Ion 9300M + WIn7 x64 + Forceware 260.99, it is randomly unable to play the 1080p24 film contents (H.264 in MKV) stably at 60Hz monitor output. Went back to 0.34 or advance to 0.36, and it just works fine.
Weird, I've no explanation why 0.36 should behave any different than 0.35 in these two things. But well, I won't complain.
The "madVR instance didn't reply properly." dialog still happens on 0.36 randomly. I found it is easy to reproduce this. Just click the "Edit Settings" button quickly after the setting menu is closed. Repeat it several times, and it will get the chance to show this result.
So the problem mostly only occurs if you try to open the settings dialog again very quickly, after just having closed it? Can everybody else with this problem confirm this? Or does the problem also sometimes occur when you open the settings dialog for the first time?
I'm somewhat doubtful it has anything to do with presentation logic, but you never know.
I don't know, either, but currently madVR always waits for the GPU to finish work before doing the next step. With the final presentation logic, I should be able to no longer wait for the GPU. That should get rid of a lot of bottlenecks and might allow madVR to finally push the GPU to 100% usage.
No clue why it's so broken on my card. Fullscreen games do play fine, so that is not at issue. It's not related to high refresh rates either, as the same thing happens at 60hz. I guess I could try updating my nvidia driver and see if that makes any difference.
Edit: madVR Fullscreen exclusive is still broken after updating drivers.
Hmmmm... I've found that fullscreen exclusive is more sensitive about multi threaded rendering. madVR uses multiple threads to do the rendering. It seems to work well for windowed mode, but exclusive mode seems to prefer single thread rendering. The final presentation logic will mostly use single thread rendering, so that's why I hope that the problem will go away with the final presentation logic.
For 23.976 video at 95.90409Hz and a clock deviation of around -0.00600 it reports frame repeats every ~10 mins. With Reclock the clock deviation changes to around -0.00010 with repeats every 1-6 days.
For 23.976 video at 96.00050Hz and a clock deviation of around -0.00500 it reports frame repeats every ~40 seconds. With Reclock the clock deviation changes to around 0.10050 with repeats every ~13 hours to 6 days.
I'm a bit confused by this statement. Isn't a madVR reported refresh rate of 95.90409 a perfect match for 23.976 video? You can't get any more perfect then that, yet it still reports frame repeats every few minutes. Is this being caused by clock deviation alone? If so, what could I do to fix it without using Reclock?
I'm not sure how much you know about DirectShow clocks. There must be a "master clock", which controls everything. In a typical DirectShow graph the audio renderer provides the master clock. Now if the audio clock runs 1% faster than it should, video must also be rendered 1% faster than it should, or else audio/video sync would be lost. Which means that if the audio clock runs 1% faster, the refresh rate must be 1% "faster", too, to allow the video to be rendered faster. So the audio clock deviation has a direct effect on the optimal refresh rate.
That said, it's quite hard to accurately measure the audio clock deviation, because the audio clock is so jittery (jumps back and forth). In order to get the most accurate measurement you should let a full movie run and take the audio clock deviation measurement from the end of the movie. But even then I wouldn't rely on the madVR measurement to 100%. I'd suggest that you try both: (1) The current perfect match you have for 23.976 playback. And (2) A perfect match taking audio clock deviation into account. Then play a movie with both settings and check which appears more fluid/smooth to you. It might be difficult to see for you, though, because with such a high refresh rate you're using, frame drops/repeats are much less noticeable than with e.g. 24Hz, where one frame drop/repeat is always 42ms.
In madVR 0.34, how was the ideal refresh rate being calculated then? If my refresh rate was 96.000Hz without Reclock it would report 23.97500, with Reclock it would report 24.00010, detecting the adjusted framerate.
It was calculated by applying the clock deviation to the perfect refresh rate match (96.000Hz / 1.001).
Yes, the AvgTimePerFrame reported by the splitter indicates 23.810, but the video is actually 23.976 and Reclock adjusts the framerate to match refresh. Usually madVR has no issues with things like VFR, and framerates different then the what the splitter reports, but this time it does. All in all it's not that big of deal since you can easily fix it by re-muxing the video and specifying the framerate.
As said above, madVR only uses the movie frame rate for the OSD, it's not actually used in madVR anywhere. So AvgTimePerFrame being wrong should have no negative effect on madVR, except for the OSD.
Everything seems to point towards Nvidia cards applying madVR 3DLUT adjustments on a pixel-by-pixel basis, instead of the whole frame at once, which is why it only has issues on large frame sizes like 1920x1080 (or smaller frames resized to such resolutions), but not so much 1280x720. For whatever reason it seems NVIDIA cards must have a limitation on the number of pixels which the lut can be applied, and it hits a processing bottleneck.
I still think it is probably a cache problem. The 3dlut is really big and probably the 7800 GPU cache somehow runs into trouble with it, when "exotic" pixel values are asked, so that the 3dlut reading can't be accelerated through the cache, but most be read again and again from GPU RAM. Of course I'm only guessing, here.
madshi
1st January 2011, 11:00
i opended it with paint and media center also. still the same problem. one thing i should note:
i test it on a jvc rs20 projector where things are a lot larger than on a tv or pc monitor. are you sure there are no vague vertical lines that can be seen?
Ah, I've had an HD350 myself and I never got it to be 100% smooth. I think the HD350 is not capable of drawing a banding-free grayscale. FWIW, I now have the JVC X3 projector and it's perfectly smooth / banding-free.
Razoola
1st January 2011, 11:10
Yeah, when I tested a GTX 470 awhile back, it still got the rendering spikes in the same problem areas, but it was powerful enough to muscle through them. I'm somewhat doubtful it has anything to do with presentation logic, but you never know. As a mentioned previously, the rendering lag seems to be triggered when only when there are a lot of out-of-gamut pixels on a HD frame scaled/displayed around 1920x1080 or so (displaying at lower resolutions can fix the slowdown). Such occurrence usually only happen for few seconds, and always repeatable on the problem sections of videos.
I personally feel there could be a problem with the presentation logic in exclusive mode based on what I see here with a 240gt. Basically it can easily run 1080p movie with full render queues in full screen windowed mode. As soon as you try the same video in fullscreen exclusive mode (identical settings etc) it sometimes (but not always) fails to run smoothly due to the queues not filling. I have to resort to restarting the clip until it runs with full queues.
I soppose it could be a driver issue but madshi has said exclusive mode work is not yet completed. I can wait for that.
madshi
1st January 2011, 11:13
Have you tried replacing all "flush & wait"s with simple "flush"s in exclusive mode?
Razoola
1st January 2011, 11:32
Have you tried replacing all "flush & wait"s with simple "flush"s in exclusive mode?
Yes, you did actually suggested playing with the flush settings when I first mentioned this issue a while back. It did help a little when the situation happened but did not solve it. Its a weird one for sure.
THX-UltraII
1st January 2011, 11:47
Nevermind, I still haven't really woken up.
I could've sworn that it stayed at 3 when I lowered it to 1 and 2, but must've dreamt.
Hope I'm not dreaming this too, but I'm using Windows 7, and 3 is max I can get.
Ah, I've had an HD350 myself and I never got it to be 100% smooth. I think the HD350 is not capable of drawing a banding-free grayscale. FWIW, I now have the JVC X3 projector and it's perfectly smooth / banding-free. i have the hd750 so that could explain it. But i also just found out that it becomes more smooth when switching from 4:4:4 to RGB (full and limited gives me the same result).
It this the reason btw that you dumped the 350 or isn't it noticeable that much in a actual movie playback when using the 350/750
madshi
1st January 2011, 11:54
i have the hd750 so that could explain it. But i also just found out that it becomes more smooth when switching from 4:4:4 to RGB (full and limited gives me the same result).
Well, why were you using YCbCr 4:4:4? I always said that RGB Full would be the correct setting for madVR... ;)
It this the reason btw that you dumped the 350 or isn't it noticeable that much in a actual movie playback when using the 350/750
Not sure how noticeable it is in an actual movie. The problem for me was when I saw banding in a movie I never knew if it was caused by the projector or if the Blu-Ray encoding was at fault. The main reasons for upgrading to the X3 were:
(1) The X3 has better contrast than the HD350.
(2) The X3 is 3D capable (might need that for future madVR development).
(3) The X3 was supposed to be a bit sharper, can't confirm that, though.
(4) The X3 has a number of other improvements, being banding-free is one of them.
noee
1st January 2011, 16:21
madshi, .36 is solid here in windowed mode on old, old ATI h/w and new CCC drivers, with both HD (low bitrate) and SD material. I'm seeing frame drop/repeat stats in the >3hrs to days. No freezes, very smooth as expected.
I decided to try FSX mode again and for whatever reason (new CCC, new MPC-HC, madVR?), I now get extremely smooth playback (all my playback is on my secondary monitor -> LG HDTV) all the way thru a complete movie. Less than 5 frame drops the entire session.
However, still having the refresh rate change issue in FSX mode. If I set the refresh rate on my playback monitor to 60Hz, then start a video or film, regardless of frame rate, the refresh rate on the playback monitor gets set back to 24Hz. This does not happen with Windowed mode. I have all of the fullscreen settings in MPC-HC turned off.
I think you said before you were calling ChangeDisplaySettingsEx() with "0" as the refresh, so it appears to be a bug in either CCC drivers or WinAPI. I have a log for this, I'm trying to find a place to put it now.
HD2600XT, CCC10.12, Win7 x64, Aero OFF, dual-mon (primary 60Hz, sec 24Hz, both 1920x1080)
HMS/FFDshow/ReClock/madVR/MPC-HC
3Dlut OFF|lumaDOWN=Spline3|lumaUP=Spline4|chroma=SoftCubic70
flush|flush|don't|don't
iSunrise
1st January 2011, 17:10
Hi madshi, great seeing you in action again, thanks for 0.35 and 0.36. Good new year and keep well!
So the problem mostly only occurs if you try to open the settings dialog again very quickly, after just having closed it? Can everybody else with this problem confirm this? Or does the problem also sometimes occur when you open the settings dialog for the first time?
Personally, I´ve never encountered any of this. I have absolutely no delay at all, when I press "edit madVR settings" either for the first time or about a dozen times in a row and close the dialog afterwards. To be sure about that, I just tried to open/close the dialog about a 100 times, and as fast as I am able to click on it. The dialog opens and can be closed instantly without any delay.
I have a router and static DHCP configured on it and only 3 clients on the network with static IPs (only mine is active at the moment), not sure about the others who are having this kind of problem. I´m also using Vista x64 and it seems everyone who has reported this problem is using XP (SP3)?
Hmmmm... I've found that fullscreen exclusive is more sensitive about multi threaded rendering. madVR uses multiple threads to do the rendering. It seems to work well for windowed mode, but exclusive mode seems to prefer single thread rendering. The final presentation logic will mostly use single thread rendering, so that's why I hope that the problem will go away with the final presentation logic.
Having used madVR for countless hours already, I can confirm that FSE is a lot more sensitive to everything. Windowed mode works flawless and I´ve not had any problems with it so far. With your recent fixes, FSE should be more stable now*, but I did not test 0.36 enough to give you any helpful feedback just yet.
*It rarely happened, that when I switched between movies or skipped through them, the "creating 3d device" error was shown and the player did not respond at all. But this may also be PotPlayer´s fault. I could not log this since it happens very rarely and when it happens I always needed to kill the task completely (Potplayer_mini). This is a pain to reproduce, too.
I´m really looking forward to your new FSE mode.
leeperry
1st January 2011, 17:44
I'm experimenting w/ chroma again, and I still think that SoftCubic80 is a good compromise on details/noise w/ sharp 1080p. Anyway, The "edit settings" button opens almost instantly if I keep a "madVR instance didn't respond properly" error msg box in the back.
If I enable the tasktray icon, the first times are slow but after 4/5 times it opens instantly again.
All files are copied on a PC1066 RAMDISK, and I've got no CPU load at all...the movie's paused too.
yesgrey
1st January 2011, 18:42
So the problem mostly only occurs if you try to open the settings dialog again very quickly, after just having closed it? Can everybody else with this problem confirm this?
It used to happen to me too with previous versions, but I've tried now with 0.36 and the settings dialog always appears, and so i did not get yet the error message. For me, it seems to be fixed. I will get back to this if it happens again.
yesgrey
1st January 2011, 19:55
I will get back to this if it happens again.
It's happening again...
Here (http://www.megaupload.com/?d=1BFME7K5) are 2 logs.
Log 1: I've opened a mkv file and after playing start I've picked MPC-HC's window title bar and moved the window quickly in several circle movements (clockwise and counter-clockwise). Then, I've right clicked on the window for opening the properties dialog and when clicking the edit settings button the error message appeared.
I had another problem with madVR, a very annoying one. Whenever I opened it to watch any movie its response was very sluggish. Sometimes I had to wait several seconds just when trying to move the player's window, or when right clicking for the properties dialog. I've decided to try a clean install, so I uninstalled it and deleted madVR dir, and reinstalled it. Now it seems to be better, but sometimes the sluggish still happens. Log 2 was made with the sluggish in action. Any clues why this happens? With any other renderer it works fine, this only happens with madVR.
I'm using Win7 x64, MPC-HC v1.4.2808, and ffdshow 3712 (happens with other decoders too).
Edit: I also have a ~2 seconds delay between clicking the edit settings button and the dialog showing up. I can live with that, but would be happier without it... ;)
deptel
1st January 2011, 21:48
"0.26"? You mean 0.36, I guess?
What happens if you disable the exclusive mode? Does it work fine in fullscreen windowed mode?
Yeah I meant 0.36 sorry. In windowed mode it is totally fine, the issue is only from fullscreen exlusive. Although when going into fullscreen exclusive and back to windowed, the windowed mode is also messed up.
Im unsure how to run windowed mode in fullscreen without activating exclusive , to test that.
Edit: Just checked with ZoomPlayer, issue is the exact same, fine in windowed or with crossfire disabled, but when enabled in fullscreen exlusive, a jittery mess. Also figured out how to get into fullscreen without exclusive mode, and it is also fine, just like windowed.
6233638
2nd January 2011, 02:25
I'm experimenting w/ chroma again, and I still think that SoftCubic80 is a good compromise on details/noise w/ sharp 1080p.Detail/noise should be the least of your concern with chroma upsampling. Choosing an algorithm that matches chroma resolution to luma resolution well to avoid colour bleeding, and choosing an algorithm that does not desaturate chroma should be your main priority. Almost all 'detail' that you see in the picture is luma information.
pie1394
2nd January 2011, 02:39
Yeah I meant 0.36 sorry. In windowed mode it is totally fine, the issue is only from fullscreen exlusive. Although when going into fullscreen exclusive and back to windowed, the windowed mode is also messed up.
Im unsure how to run windowed mode in fullscreen without activating exclusive , to test that.
I guess you mean this like the attached picture?
Without the FS Exclusive mode, the bad thing is that sometimes you get Tearing problem if the ratio of display frame rate to content frame rate is not an integer. Since you have Aero on, it does not seem an issue.
cyberbeing
2nd January 2011, 07:12
On my 7800GTX 512, it seems that disabling all flushing in madVR reduces the Exclusive Mode constant stuttering/tearing significantly, but it's unfortunately it's still noticeable.
I've also noticed a problem where madVR Exclusive Mode seems to be hanging MPC-HC in the taskbar when I right-click (which reverts to Windowed) and close MPC-HC when in fullscreen, if I don't have the 'wait 3 seconds' setting enabled. Is there anyway to fix this without using that '3 second' option?
I think the bug where madVR gets out of sync if you leave the video paused for an extended period of time still exists as well. I've seen this happen occasionally on both computers.
madvr
2nd January 2011, 14:16
Version 0.36 is working perfectly for me! Thanks Madshi! Watched a movie last night with zero drops or repeats (I have installed reclock too now). Thanks:)
Hardware: Core2Duo 3.16Ghz, 8GB RAM, Intel 80GB G2 SSD, ATi HD5570 GFX (with passive heatsink mod)
Software: Media Player Classic HomeCinema (x86/x64), 1.4.2808, ffdshow tryouts project, svn 3710 (x86/x64), ReClock 1.8.7.3
Latest versions of MPC-HC and FFDShow for some people (use 32bit verisons): http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/
yesgrey
2nd January 2011, 15:20
On my 7800GTX 512, it seems that disabling all flushing in madVR reduces the Exclusive Mode constant stuttering/tearing significantly, but it's unfortunately it's still noticeable.
Have you tried setting all scaling options to "Nearest Neigbor"? That should give you the less GPU load. I know the image would not be very good like that, but it would be only for testing purposes...
cyberbeing
2nd January 2011, 17:59
It still happens even with all resizing set to Bilinear or Nearest-Neighbor. My rendering times and GPU load have never really been stressed with my normal resize settings. While unrelated, even that 3DLUT bug still happens with everything set to Bilinear, dithering disabled, and no resizing being done.
For reference, I don't have any issues with VMR9 & EVR Exclusive mode in MPC-HC. That said, I've been perfectly happy with madVR's windowed mode, so I'm somewhat indifferent if it gets fixed or not.
pankov
2nd January 2011, 21:46
Well, the crash appears to happen during madVR finalization. But that's about all I can see from the log. Logs aren't really too useful for crashes. Right now I don't know where the crash is coming from exactly.
If you want, I can look into this further, but I'd need from you:
(1) The MKV splitter download you're using (the exact version you're using).
(2) An explanation of how to setup ZP to make ZP use this splitter. I'm a ZP configuration noob.
I'll be really glad if you look into it.
Here is a sample you can use for testing (make two copies of the file in the same folder)
http://www.mediafire.com/?zmn2nyyrzat
but in reality it should happen with other files too.
About the splitter - I'm mainly using Haali's one(v1.10.262.12) and the error is more rare with it but with MPC's one (v1.4.2667.0) it's happening every time.
In the following archive
http://www.mediafire.com/file/5s14932rm5si6ja/madVR%20-%20log%20-%20access%20violation%20%28files%20to%20reproduce%29.rar
you'll find both .ax files for the splitters, my ZP settings (both a .reg file and and an archive of the MediaAutoGraph folder located in ZP's install folder, which contains the configuration files for media playback - source filters/splitters/decoders) and zplayer.exe (it's the latest beta build).
To get the same configuration as me (as close as possible) you'll have to replace your zplayer.exe and MediaAutoGraph folder. You'll also have to import the .reg file (you can rename HKCU\Software\VirtuaMedia to VirtualMedia_orig so you don't lose your current settings ... and the same with the MediaAutoGraph folder)
After this, start the first sample, go to fullscreen (double click on the video ... or Alt+Enter) and then pres "]" or "PgDn" (which should load the next file) and then you should, hopefully, get the access violation.
If you have any questions send me a PM or drop me an e-mail at gmail.
:thanks: in advance for your time spend on this issue and for all your work till now.
leeperry
2nd January 2011, 22:33
alright, Kazuya has been kind enough to encode a 16-235 black>white gradient in YV12 h264...available here: Banding_720p.rec709.mkv (http://www.mediafire.com/?to56a070x43dskn)
I've run all kind of comparisons between mVR/SmoothLevels/ColorYUV when going TV>PC...they're available there: dither.rar (http://www.mediafire.com/?mov7dj5pais1wa2)
I'm colorblind so I see far less gradients than "normal" ppl, but I use a LG Flatron CRT(infinite native CR) in VGA(30bit) when most ppl use a low CR LCD(1000:1 at best?) in 24bit TMDS(DVI/HDMI <1.3), so that prolly evens things out :D
few observations:
1)-no dithering in mVR doesn't equal no dithering in SmoothLevels, neither is smoother than the other but the gradients are different :confused:
2)-the default dithering strength(50) in SmoothL provides smoother gradients than the default dithering in mVR...call if oversmoothing if you like, but it does look "smoother" and does provide a more enjoyable PQ IME(and others). Besides LaTo claims that it doesn't deband per se, it only smooths the TV>PC conversion.
no dithering whatsoever: http://www.pixelz.fr/1/3/0/67e85f4a445a5ecd0d45228d91ab4t.jpg (http://www.pixelz.fr/1/3/0/67e85f4a445a5ecd0d45228d91ab4.png) / mVR dithering: http://www.pixelz.fr/2/1/4/4dd315ee0046b825cb9d416abc1b7t.jpg (http://www.pixelz.fr/2/1/4/4dd315ee0046b825cb9d416abc1b7.png)
SmoothL default dithering/no mVR dithering: http://www.pixelz.fr/6/8/f/474b5bf1d4bc40f5b71c9da491093t.jpg (http://www.pixelz.fr/6/8/f/474b5bf1d4bc40f5b71c9da491093.png)
3)-ColorYUV() fubars things up...even mVR can't do miracles, it's just fubar. Don't use this :devil:
I still would enjoy the ability to tweak the dithering strength in mVR if any possible, I hope this will be considered.
nightfly
3rd January 2011, 00:43
Using MPC-HC (tried several versions) and the Cyberlink Video Decoder results in a green video. Switch to any other video decoder (say Arcsoft) results in a normal picture. Noticed that this was reported fixed with v.22. I am running the latest .36.
Thanks.
*Touche*
3rd January 2011, 01:01
I've been trying to set up madVR (tried 0.32 and 0.36) and MPC-HC on my friend's laptop with Nvidia 210M GPU and had some problems:
Win7 x64 AeroON, 23.976 movies
1) full screen exclusive is much slower than windowed mode. I have to turn it off to avoid stuttering. I thought FSE should provide better performance. Rendering times go from ~30-35 to ~45 ms and that causes stuttering on 1080p 24Hz (23.971xxx Hz reported by CRTL+J) TV.
2) 1 frame repeat is listed as every couple of minutes. If I use ReClock it improves to more than 4 hours, but that introduces regular stutter every few seconds. ReClock is green, madVR CTRL+J shows good values, but this phantom stutter appears and I have no idea what causes it. I have to remove ReClock but then get the 1 frame repeat every 3-4 minutes. Any ideas why the regular hiccup occurs.
scoz
3rd January 2011, 02:03
no dithering whatsoever: http://www.pixelz.fr/1/3/0/67e85f4a445a5ecd0d45228d91ab4t.jpg (http://www.pixelz.fr/1/3/0/67e85f4a445a5ecd0d45228d91ab4.png)
mVR dithering: http://www.pixelz.fr/2/1/4/4dd315ee0046b825cb9d416abc1b7t.jpg (http://www.pixelz.fr/2/1/4/4dd315ee0046b825cb9d416abc1b7.png)
SmoothL default dithering/no mVR dithering: http://www.pixelz.fr/6/8/f/474b5bf1d4bc40f5b71c9da491093t.jpg (http://www.pixelz.fr/6/8/f/474b5bf1d4bc40f5b71c9da491093.png)
Your amazing SmoothL screenshot is full of nasty looking banding. It looks even worse than the no dithering screenshot.
Maybe you should try opening them up in an image editor that you can fiddle with the contrast so you can see the bands, maybe your having issues with your color blindness? This experiment has only shown me that SmoothL manages to mangle a gradient.
Also, I'm not sure if you realize this, but your posts come off as extremely condescending. The fact that your touting this amazing filter while having no idea what it does or any way to actually describe how it is "better" pretty much makes your posts pointless to read, so I wouldn't blame madshi or anyone else if they simply ignored your posts. Maybe you should step back and consider what it is you want to accomplish posting in this thread and start over with a clear concise idea.
leeperry
3rd January 2011, 02:36
For what we know, you're using an uncalibrated 6bit dithered LCD screen...strangely, Kazuya sees the same things I do, and my real world experiments (http://forum.doom9.org/showpost.php?p=1454344&postcount=96) gave the same results too. Dither is enabled by default in SmoothL for a reason :rolleyes:
Now I won't deny that mVR might be more mathematically accurate, and SmoothL overdithering...
PS: I've notified the mods about your meaningless personal attacks(that I didn't bother reading).
Thunderbolt8
3rd January 2011, 03:25
you guys should quit your kindergarden games. that was hardly a personal attack as much as it was worth reporting.
scoz
3rd January 2011, 04:03
no dithering whatsoever: http://www.pixelz.fr/1/3/0/67e85f4a445a5ecd0d45228d91ab4t.jpg (http://www.pixelz.fr/1/3/0/67e85f4a445a5ecd0d45228d91ab4.png)
mVR dithering: http://www.pixelz.fr/2/1/4/4dd315ee0046b825cb9d416abc1b7t.jpg (http://www.pixelz.fr/2/1/4/4dd315ee0046b825cb9d416abc1b7.png)
SmoothL default dithering/no mVR dithering: http://www.pixelz.fr/6/8/f/474b5bf1d4bc40f5b71c9da491093t.jpg (http://www.pixelz.fr/6/8/f/474b5bf1d4bc40f5b71c9da491093.png)
Grabbed a 200px square with top-left corner (400,100) in all 3 pics, labeled correctly. Contrasted it so that a 5.3bit dithered peon like myself can see the difference between images.
http://www.pixelz.fr/d/c/8/7e326143681f143e96d54752860f6t.jpg (http://www.pixelz.fr/d/c/8/7e326143681f143e96d54752860f6.png)
It looks like SmoothL actually under-dithers. Zooming in, it also seems to use sort of a diamond dithering pattern. Maybe its the noise generated from madvr's dithering thats bothering you?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.