madVR - high quality video renderer (GPU assisted)

[cyberbeing]

Backup your settings.bin, then try running the "restore default settings.bat". If that works, you could work forward from there trying to figure out the problem setting.

[seiyafan]

Backup your settings.bin, then try running the "restore default settings.bat". If that works, you could work forward from there trying to figure out the problem setting.

Is that for me or someone else? :D

[cyberbeing]

Is that for me or someone else? :D
For you.

[seiyafan]

Well, I just unplugged 770, put in 270x, installed 14.2 beta and can't play videos in full screen, I didn't change anything else a bit.

[cyberbeing]

Well, I just unplugged 770, put in 270x, installed 14.2 beta and can't play videos in full screen
Did you uninstall the NVIDIA driver before removing it? Can you play any 3D games in Fullscreen Exclusive without hanging?

I didn't change anything else a bit.
Okay, but you should try resetting madVR to default settings to see if that resolves it or not.

[mikecks]

I am noticing a big problem while trying to run 2 monitors. First scenario with desktop composition enabled is that madvr is inheriting the composition of the primary monitor and not the monitor which mpc-hc is playing the file on. This wouldn't be a problem if it were not for the judders/glitches I experience when the composition is on 120HZ(the refresh rate of my main monitor). I disabled desktop composition and noticed suddenly I was experiencing an extremely high amount of frame drops(800+ easily) so I unchecked that setting and tried disabling aero entirely, same result. With the setting disabled & aero turned back on, 0 frame drops on both monitor & television. However back to square one in trying to resolve my viewing problems.

So does anybody have any suggestions on how to fix this behaviour/approach to watching content through the plasma while still doing my other pc activies on my main monitor.

Thanks in advance.

[XMonarchY]

I'm not sure what Fhoech and you talked about, but what you ended up doing is very wrong.

(1) A video decoder MUST NOT clip anything. So LAV does it correctly. And if your report is true then ffdshow is buggy.

(2) madVR requires 3dluts to have video level input and output. So creating a 0-255 output 3dlut is all wrong.

(3) If you configure madVR to output 0-255 then BTB and WTW are clipped by madVR. So I can only guess that you had set madVR to 16-235 output (which is not correct if you set your display to 0-255), or that your original 3dlut was buggy.


The next official madVR builds will always use ordered dithering for madTPG, regardless of which settings you're using in madVR.

Yellow flashing bars.

If I do this:
1. Set TV to Full HDMI/0-255
2. Set nVidia 327.23 drivers to 0-255 using your tool and make sure it really is 0-255 using another tool
3. Set madVR to 0-255 in settings and set LAV Video to 0-255 (default setting)
4. Create ArgyllCMS/dispcalGUI 3DLUT with 16-235 input and 16-235 output
5. Load 3DLUT into madVR
6. Use LAV Video decoder as the active decoder running default settings

... then in the most basic "White Clipping.mp4" test pattern where only bars up to and including 234 should be flashing gray, I get yellow flashing bars up to 250....

I tried different drivers, madVR versions, etc., but all 16-235 output 3DLUTs made with ArgyllCMS 1.6.2 and 1.6.3 with or without dispcalGUI induce these flashing yellow bars... I even format my SSD and installed a different OS recently - same thing happened. I tried using K-Lite Codec Pack with MPC-HC that pre-configured LAV video in my previous OS install, but this time I installed the official and the latest LAV filter pack using the installer, which registered the filters. Then I downloaded the latest madVR and registered it using the included .bat and .exe. Then I launched JRiver, selected madVR for renderer, LAV Audio, LAV Video, and LAV Splitter. Again - I got yellow flashing bars. I'm not doing anything wrong - I've been researching and doing these things for a while now. I either used the provided dispcal, targen, dispread, colprof, collink commands from AVS madVR thread or the default dispcalGUI flow/madVR settings, aside from setting gamma curve to BT.1886 instead of sRGB.

What Floarian (Fhoech) said did make most sense since he stated that LAV Video did not clip WTW, but ffdshow did, which is why he couldn't reproduce the problem when I told him about it. Then he installed LAV Video and reproduced the problem. It was then when he advised me to set madVR to 16-235, and to create a 16-235 input with 0-255 output 3DLUT using raw collink.exe commands because dispcalGUI would not allow 0-255 output for madVR at that time (because it was "wrong"). Because of this issue, the next release of dispcalGUI introduced an ability to set 0-255 output for madVR 3DLUT. When you set 0-255 for 3DLUT output in dispcalGUI, it showed a warning that madVR must be set to 16-235 if 0-255 output is used for 3DLUT or else clipping would occur. Another individual in AVS madVR thread also reproduced this exact problem many months ago, but it was kind of ignored/unsolved/not sure what was the cause.

Please don't be offended - I am not saying something is wrong with madVR, but possibly with LAV Video. Every time I used the "right" 16-235 input & output 3DLUTs I got yellow flashing bars... If I use what you consider the "wrong" way, then I get perfectly good 232-234 flashing bars and no white or black clipping. But like I said - that works great for normal 16-235 sources, but I what would happen with 0-255 sources?

I am new and I may have not contributed much to this thread and at one point did report, accidentally, something I thought fixed the OpenCL issue, which did render the credibility of my statements as highly questionable ones. However, what I am saying now really is so for me when I do everything right... I wish I could record a video or do something to show you that when I create 3DLUTs properly and apply them, I get yellow flashing bars with LAV Video decoder... I can provide screenshots, logs, files, anything...

Here is my Dropbox file that contains the following:
1. madVR settings.bin
2. LAV Video setting.jpg (sorry, no clue where settings files are)
3a. "Right" 16-235 input with 16-235 output 3DLUT log
3b. "Right" 3DLUT ICM file
3c. "Right" 3DLUT itself
4. dispcalGUI/ArgyllCMS Profile.cal file used to create the included 3DLUT
5. The latest LAV Filters.exe I use
6. White Clipping.mp4 that displays yellow flashing bars when the included files and settings are used to run it.
https://dl.dropboxusercontent.com/u/93831976/Yellow%20Bars.rar

Please let me know if anything else is needed to verify this issue

Dithering
As far ordered dithering goes - I just used it to create another 3DLUT and ran HCFR measurements while ordered dithering was enabled. dE's were super low. Then I switched to ED option 2 with 2 boxes enabled and ran measurements again to see if there was a difference. There was a difference - almost all dE's went up by 0.2-0.3. However, results were consistent.

I assume that the 0.2-0.3 dE rise should be simply ignored because ED messes with colorimeters, such i1D3? My last 3DLUT was made using ED option 2 for madTPG and all went fine, verifying with HCFR yielded low and consistent dE's across all measurements. Then I used ordered dithering with 2 boxes disabled to verify the 3DLUT results made with ED2 - some dE's went up and others went down.

The last question I guess - when ordered dithering is used - should the other 2 boxes be enabled or disabled? They do not seem to have an effect on measurement results.

[seiyafan]

Okay, problem solved. I had to uncheck "enable automatic fullscreen exclusive mode". Is it because this mode works with nVidia but not AMD?

[QBhd]

I am noticing a big problem while trying to run 2 monitors. First scenario with desktop composition enabled is that madvr is inheriting the composition of the primary monitor and not the monitor which mpc-hc is playing the file on. This wouldn't be a problem if it were not for the judders/glitches I experience when the composition is on 120HZ(the refresh rate of my main monitor). I disabled desktop composition and noticed suddenly I was experiencing an extremely high amount of frame drops(800+ easily) so I unchecked that setting and tried disabling aero entirely, same result. With the setting disabled & aero turned back on, 0 frame drops on both monitor & television. However back to square one in trying to resolve my viewing problems.

So does anybody have any suggestions on how to fix this behaviour/approach to watching content through the plasma while still doing my other pc activies on my main monitor.

Thanks in advance.



I do the same as you (roughly) so here are my settings that work:

http://i.imgur.com/7BxXwfu.png

http://i.imgur.com/p9f5O3b.png

Hope that helps

Okay, problem solved. I had to uncheck "enable automatic fullscreen exclusive mode". Is it because this mode works with nVidia but not AMD?

I can assure you FSE works with AMD and is actually better than windowed mode

QB

[mikecks]

Thank you, I tried your settings but I get a lot of screen tearing with them on the plasma, no frame drops though

[QBhd]

Thank you, I tried your settings but I get a lot of screen tearing with them on the plasma, no frame drops though

Screen tearing? Do you have any 3D settings in your graphics card that are not default? Screen tearing?

QB

[mikecks]

I do apologise, I forgot I had turned off vsync as i've not had a use for it in a long time. all good now and thank you for the help my man.

[seiyafan]

I just finished testing the 270x, I am very surprised with the results:


Please see updated result in the next page

[JarrettH]

Put Intel on its DXVA2 upscaling mode for massive performance gains :D

[Asmodian]

5.5 ms seems fine, no need for faster than that. :)
DXVA2 upscaling will not help NNEDI3 or ED dither.

[Asmodian]

Yellow flashing bars.

I can confirm this odd behavior on my system as well.

I did find a way to get a correct white point and level using the same 3DLUT which gives me yellow flashing bars up to 252 when in FSE or Windowed mode. In Windowed or FSE I also get incorrect whites, 255 looks almost like my uncalibrated white point but it isn't quite.

- Use the 3DLUT as created by collink, no odd options 16-235 in and out. (collink.exe -v -3m -qh -et -Et -Ib:2.4 -ila -a dispcal-1.cal -G Rec709.icm X270OC-1.icm 3DLUT-1.icm)
- Use Windowed Overlay with "disable GPU gamma ramps" unchecked or checked (it will not change the image as the ramps are linear as attached to the 3DLUT)

If I use my "trick" of removing the linear GPU gamma ramps and using "disable GPU gamma ramps" when in Windowed Overlay I get the same image as I get using the above settings in standard Windowed or FSE modes. If I do not check "disable GPU gamma ramps" when using my trick and in Windowed Overlay mode I get correct levels (no flashing >234) but the white point is double corrected and tan.

So the only way I can get a correct white point and level when bypassing the GPU gamma ramps is by leaving the 3DLUT as madVR expects it to be so madVR sets the GPU ramps to linear and have madVR in control of everything (Windowed Overlay mode).

I do not understand why my trick gives the same incorrect image I get in Windowed & FSE modes, the only difference is that Windows doesn't lose calibration. :confused:

@XMonarchY Does using Windowed Overlay also give you a correct white point and level?

Edit: It is quite embarrassing I never noticed this after spending the last two weeks playing with calibrations. :o
I finally got a good black point but upper whites were looking a little washed out. Using my new "correct" settings the video looks better but Windows goes uncalibrated.
Edit2: The black clipping test looks the same in overlay and windowed modes, maybe because I turned off black point correction when calibrating?
Edit3: I am using DVI and a standard DVI only monitor using a custom refresh rate (72Hz) so I would expect all level and other processing to be off (and they all are off as far as I can see in the Nvidia control panel).

[Mangix]

I just finished testing the 270x, I am very surprised with the results:

You should have used the DirectCompute builds. It's known that the OpenCL <> Direct3D interop is very slow on AMD hardware.

[seiyafan]

You should have used the DirectCompute builds. It's known that the OpenCL <> Direct3D interop is very slow on AMD hardware.

I wasn't aware that there are other variations of MadVR (new to this place), where can I download it?

[James Freeman]

http://madshi.net/madVRfinalDither4.rar

Rendering - Dithering

[seiyafan]

Okay, back to square one, :D
Will post the result tomorrow.

[THX-UltraII]

http://madshi.net/madVRfinalDither4.rar

Rendering - Dithering

I have a AMD 280x with the latest 14.2 beta driver installed. What do you recommend at the dithering options for this setup? Option 2 with both checkboxes enabled for highest PQ? I m running a 4K display device and play 1080p blu-ray content that is upscaled by madVR.

Do you also recommend to use the OpenCL option in the settings of madVR looking at my config?

[cyberbeing]

Highest PQ is subjective, and unfortunately both of the dithering 'options' are rather controversial in that regard.

My top 2 are:
Error Diffusion 1' 'colored' disabled & 'change' disabled
Error Diffusion 2' 'colored' disabled & 'change' enabled

And I believe leeperry's top 2 are:
Error Diffusion 2' 'colored' disabled & 'change' disabled
Error Diffusion 1' 'colored' disabled & 'change' disabled

There are a few others as well which prefer 'colored' to be disabled, but the majority seem to prefer both 'colored' & 'change' enabled, which is why madshi currently has them set as the defaults. madshi has done a decent enough job with his labels, so it shouldn't be hard to pick whichever trade-off sounds most acceptable to you. If you are unable to see a difference, it won't matter much. I imagine at 4K error diffusion becomes rather costly, so you'll need to decide if it's worthwhile or not from a performance perspective.

[madshi]

Ok, 270x is here, but when I enter full screen mode MPC would just froze, what's the issue here?
I don't know. It doesn't seem to happen for anybody else. As cyberbeing has asked: Have you uninstalled the NVidia drivers? They should not interfere, but since this problem seems to be specific to your PC, it might be worth a try. You could also try installing the official AMD driver version instead of the beta to check whether that helps. If neither of that helps, you can upload a debug log for me to look at, maybe I can see something in there...

Okay, problem solved. I had to uncheck "enable automatic fullscreen exclusive mode". Is it because this mode works with nVidia but not AMD?
That's not solving the problem, just avoiding it. Fullscreen exclusive mode is the preferred way to watch movies with madVR.

I am noticing a big problem while trying to run 2 monitors. First scenario with desktop composition enabled is that madvr is inheriting the composition of the primary monitor and not the monitor which mpc-hc is playing the file on. This wouldn't be a problem if it were not for the judders/glitches I experience when the composition is on 120HZ(the refresh rate of my main monitor). I disabled desktop composition and noticed suddenly I was experiencing an extremely high amount of frame drops(800+ easily) so I unchecked that setting and tried disabling aero entirely, same result. With the setting disabled & aero turned back on, 0 frame drops on both monitor & television. However back to square one in trying to resolve my viewing problems.
You didn't say which GPU and which OS you're using.

Generally, madVR has no control over the composition rate. Windows chooses that. It's a known problem that when playing video on a secondary monitor, the composition rate of the primary monitor is often (always?) used. There's nothing I can do about it. There are several possible workarounds for the problem, though:

(1) The recommended solution for this problem is to use fullscreen exclusive mode, which works for all GPUs and fully solves this problem.

(2) You could try overlay mode. But that only works for NVidia & Intel. AMD doesn't support it.

(3) You could try disabling desktop composition completely. But you say you get tons of dropped frames then. So this seemingly doesn't work for you.

(4) You could adjust the refresh rate of the primary so that it matches the playback framerate. This way the composition rate of both monitors should fit to the video.

(5) You could make the secondary monitor primary for the duration of video playback.

What Floarian (Fhoech) said did make most sense since he stated that LAV Video did not clip WTW, but ffdshow did, which is why he couldn't reproduce the problem when I told him about it. Then he installed LAV Video and reproduced the problem. It was then when he advised me to set madVR to 16-235, and to create a 16-235 input with 0-255 output 3DLUT using raw collink.exe commands because dispcalGUI would not allow 0-255 output for madVR at that time (because it was "wrong").
I understand what he suggested and why he suggested it, but I'm still convinced that the whole approach is totally wrong. All he's doing is giving you a way to hide/mask the real problem.

It seems that the 3dlut created by ArgyllCMS moves some WTW colors back into the "valid" range, which then produces those yellow bars. This is probably a side effect of trying to extrapolate the calibration into the WTW range. But I think ArgyllCMS should take special care not to move WTW data back into the visible/valid range. This is something that should be brought to Graeme's attention. It's for him to fix, IMHO. Or maybe there is already an option there for that in ArgyllCMS? I don't know, to be honest...

Please don't be offended - I am not saying something is wrong with madVR, but possibly with LAV Video.
I'm not offended. But it's slightly going on my nerves that I have to tell you now for the 3rd time that a decoder MUST NOT clip. This is not open up for discussion. It's a fact. You can safely rule out LAV as the cause of the problem. ffdshow hides the problem, but that's not because what ffdshow does is better. It's actually worse/wrong.

As far ordered dithering goes - I just used it to create another 3DLUT and ran HCFR measurements while ordered dithering was enabled. dE's were super low. Then I switched to ED option 2 with 2 boxes enabled and ran measurements again to see if there was a difference. There was a difference - almost all dE's went up by 0.2-0.3. However, results were consistent.

I assume that the 0.2-0.3 dE rise should be simply ignored because ED messes with colorimeters, such i1D3? My last 3DLUT was made using ED option 2 for madTPG and all went fine, verifying with HCFR yielded low and consistent dE's across all measurements. Then I used ordered dithering with 2 boxes disabled to verify the 3DLUT results made with ED2 - some dE's went up and others went down.

The last question I guess - when ordered dithering is used - should the other 2 boxes be enabled or disabled? They do not seem to have an effect on measurement results.
Interesting. Graeme said that he preferred ordered dithering for calibration, so that's what madTPG now always uses with the latest madVR test build, no matter which algorithm you selected in madVR. The option "change dither for every frame" should still have an effect on madTPG, though. Could you please check if you can measure a difference with "change dither for every frame" disabled/enabled? Which produces better results for you? That's one thing Graeme wasn't sure about himself.

Do you also recommend to use the OpenCL option in the settings of madVR looking at my config?
I don't know, just try out which works faster for you. Probably when using an AMD GPU you should not use that option, but that's just a guess on my part...

[Asmodian]

It seems that the 3dlut created by ArgyllCMS moves some WTW colors back into the "valid" range, which then produces those yellow bars. This is probably a side effect of trying to extrapolate the calibration into the WTW range.

I do not think this is it, I get a correct white point and level when using Windowed Overlay and not when using FSE. It is really easy to notice, play the white clipping test video in a window -> looks fine, go full screen -> yellow flashing up to 253.

[madshi]

You're right, the problem doesn't seem to occur in Overlay mode. Not sure why, but that's probably a different issue. Maybe the 3dlut is not applied to Overlay mode at all? In both windowed mode and FSE mode the problem occurs, so I think it's most probably a problem with the 3dlut.

[Asmodian]

I am also doing my white point correction with the 3DLUT so it would be very obvious if the white matched my desktop white.

[James Freeman]

Asmodian,
Try generating a 3DLUT with "Luminance Matched Appearance" (collink -ila) and report.

That's what solved the yellow/blue whites for me.
Apparently because the original white point is not exactly 6500k.

[madshi]

I am also doing my white point correction with the 3DLUT so it would be very obvious if the white matched my desktop white.
Ok, just found out that the linear gamma ramps I'm applying in Overlay mode clip away WTW. That's why it looks alright in Overlay mode. The real problem is still the 3dlut.

[Asmodian]

Ok, just found out that the linear gamma ramps I'm applying in Overlay mode clip away WTW. That's why it looks alright in Overlay mode. The real problem is still the 3dlut.

Great! Thanks, makes a lot more sense now. :)
And there is still hope for my evil hack to work.

Asmodian,
Try generating a 3DLUT with "Luminance Matched Appearance" (collink -ila) and report.

That's what solved the yellow/blue whites for me.
Apparently because the original white point is not exactly 6500k.

Thanks but that is what I used, I have also tried absolute (-ia) and relative (-ir) intentents. I wonder what I could be doing wrong with the 3DLUT. Generating good 3DLUTs is hard. :(

[James Freeman]

Thanks but that is what I used, I have also tried absolute (-ia) and relative (-ir) intentents. I wonder what I could be doing wrong with the 3DLUT. Generating good 3DLUTs is hard. :(

Try this:
collink.exe -v -qu -G -ila -r65 -n -3m -et -Et -Ib:2.2

[Asmodian]

I wonder if it is something wrong with the way a calibration file is included in the 3DLUT when Argyll is generating a TV range 3DLUT? If I use exactly the same calibration files but use -H instead of -a in collink I get the expected colors in any mode, windowed, FSE, or overlay. I will poke around in Argyll forums. ;)

Since madVR is doing the math for the gamma ramps when in overlay mode I think I will stick with appending the calibrated gamma ramps and let madVR use them, no luck with all-in-one 3DLUTs.

Try this:
collink.exe -v -qu -G -ila -r65 -n -3m -et -Et -Ib:2.2
I used:

collink.exe -v -3m -qh -r256 -et -Et -Ib:2.4 -ila -a monitor.cal -G

which looks very odd in FSE and:

collink.exe -v -3m -qh -r256 -et -Et -Ib:2.4 -ila -H monitor.cal -G

Which looks fine, great even. :confused:

edit: I gave this a try:
collink.exe -v -3m -qh -n -et -Et -Ib:2.4 -ila -a monitor.cal -G
and it looks almost identical to the other "-a", "-n" didn't seem to change much.

[THX-UltraII]

I don't know, just try out which works faster for you. Probably when using an AMD GPU you should not use that option, but that's just a guess on my part...

Thanks for your reply. Does it only affect speed or also PQ?

[sajara]

madshi,


I have a problem using Ordered dither. Everytime i go to full screen image freezes. It works alright in MPC in windowed mode. It makes no difference if it is FSE or FS window. If I go out of full screen the clip does not play anymore on MPC-HC. It works without any problem in other dithering modes.

I've made a desktop video that illustrates the problem, for your analysis. https://www.dropbox.com/s/w23x1lou1t09w6i/20140301_1154_35_HEVC.mp4

Problem for me started with Finaldither2. I'm using latest version you released.

System is: i7 2630QM, Radeon 6570M, 13.12 drivers, Win 8.1 64bit, MPC-HC 1.7.3, internal LAV 0.60.1.5

Before I was to send that message i remembered to try resetting the settings and it worked. Now the problem is that it only works in FSE mode as soon i revert back to FS windowed mode problem repeats every single time.

The odd thing is that the freeze only surfaces in Ordered dithering, with other dithering algorithms there is no problem at all.

Tell me if a madVR dump log helps and intructions in how to do it. Thanks

[madshi]

Thanks for your reply. Does it only affect speed or also PQ?
For AMD GPUs it should only affect speed.

I have a problem using Ordered dither. Everytime i go to full screen image freezes. It works alright in MPC in windowed mode. It makes no difference if it is FSE or FS window. If I go out of full screen the clip does not play anymore on MPC-HC. It works without any problem in other dithering modes.

I've made a desktop video that illustrates the problem, for your analysis. https://www.dropbox.com/s/w23x1lou1t09w6i/20140301_1154_35_HEVC.mp4

Problem for me started with Finaldither2. I'm using latest version you released.

System is: i7 2630QM, Radeon 6570M, 13.12 drivers, Win 8.1 64bit, MPC-HC 1.7.3, internal LAV 0.60.1.5

Before I was to send that message i remembered to try resetting the settings and it worked. Now the problem is that it only works in FSE mode as soon i revert back to FS windowed mode problem repeats every single time.

The odd thing is that the freeze only surfaces in Ordered dithering, with other dithering algorithms there is no problem at all.
This should be fixed in the next official build.

[sajara]

This should be fixed in the next official build.

Thanks madshi.

[seiyafan]

Just installed madVRfinalDither4, so I am guessing the new ED1 and ED2 use DirectCompute, right? Should there be performance difference between the two?

[QBhd]

Just installed madVRfinalDither4, so I am guessing the new ED1 and ED2 uses DirectCompute, right? Should there be performance difference between the two?

Not as far as I can tell, and if there is, it's so small to be negligible

Highest PQ is subjective, and unfortunately both of the dithering 'options' are rather controversial in that regard.

My top 2 are:
Error Diffusion 1' 'colored' disabled & 'change' disabled
Error Diffusion 2' 'colored' disabled & 'change' enabled

And I believe leeperry's top 2 are:
Error Diffusion 2' 'colored' disabled & 'change' disabled
Error Diffusion 1' 'colored' disabled & 'change' disabled

There are a few others as well which prefer 'colored' to be disabled, but the majority seem to prefer both 'colored' & 'change' enabled, which is why madshi currently has them set as the defaults. madshi has done a decent enough job with his labels, so it shouldn't be hard to pick whichever trade-off sounds most acceptable to you. If you are unable to see a difference, it won't matter much. I imagine at 4K error diffusion becomes rather costly, so you'll need to decide if it's worthwhile or not from a performance perspective.

LOL... been banging my head against this for days now... I think I have settled for:

Error Diffusion 2' 'colored' enabled & 'change' disabled

I am fairly sure your target screen has a lot to do with preferences. i.e. size and panel type (mine is 1024x768 Plasma).... Maybe we should do an impromptu poll to find out what people picked AND what their target screen is. It might help shed some light on why people choose what they choose.

QB

[seiyafan]

Here's the result with new ED:

http://s21.postimg.org/wnxi355f9/madvr3.png


Conclusion: 270x wins in new ED, and it was able to perform at 770 level until NNEDI3 doubling is enabled. For 1080 -> 1440 upscaling with NNEDI3/32 doubling, 270x can barely handle it without dropping frame (~40 ms rendering time), I also had to turn off S.M and ED.

If I were given a choice I would definitely keep the 270x because it runs cooler and noticeably quieter than the 770. (50C at 25% fan speed vs. 70C at 55% fan speed in the 770)

[XMonarchY]

madshi,

I was only relaying information provided to me by someone who does know more about 3DLUTs and decoders than I do. You're right - I don't know enough to argue with either you or Florian. I can only hope you can see where I thought the problem was coming from. I'm sorry I brought it up - its no biggie to have this problem... - I am not sure it even affects 16-235 content. I'll refrain from posting any bugs unless I am certain they are coming from madVR, which is something I can never be certain about.

Originally, I assumed that the problem was coming from the fact that 0-255 .cal LUT files were integrated into 16-235 3DLUTs, but I was told that it wasn't so... It was also interesting to note that WTW were visible, but BTB were not as long as Black Point Compensation in "Show Curves" was used (its that fix that completely resolves black point rise issue).

[madshi]

Conclusion: 270x wins in new ED, and it was able to perform at 770 level until NNEDI3 doubling is enabled. For 1080 -> 1440 upscaling with NNEDI3/32 doubling, 270x can barely handle it without dropping frame (~40 ms rendering time), I also had to turn off S.M and ED.
I just wish AMD wouldn't have the high OpenCL <-> D3D9 interop costs. That problem eats away so much of the raw speed advantage AMD has in OpenCL... :(

I was only relaying information provided to me by someone who does know more about 3DLUTs and decoders than I do. You're right - I don't know enough to argue with either you or Florian. I can only hope you can see where I thought the problem was coming from. I'm sorry I brought it up - its no biggie to have this problem... - I am not sure it even affects 16-235 content. I'll refrain from posting any bugs unless I am certain they are coming from madVR, which is something I can never be certain about.
It's ok to post bug reports. I'd just prefer if you would believe me when I reply to you... ;) Florian probably has lots more knowledge about calibration than I have. But I know more than he does about which component in a DirectShow graph is reponsible for which task.

Anyway, if you look into the AVSForum "madVR + ArgyllCMS" thread, I've posted a comment there describing the problem you've run into and asking Graeme to look into it, because it's really his job to fix this, IMHO. So look out for a new ArgyllCMS build at some time in the future, which should then (hopefully) fix the yellow bars for you.

[seiyafan]

I wonder how NNEDI3 performs on Titan black. :devil:

[mzso]

test build with a fix:

http://madshi.net/madVRyuvFullrange.rar


Does this have any change that might cause potplayer to leak? Because that's what I'm experiencing since around the time I installed it. +~80MB for every new playback cycle with fullHD videos.

[*Touche*]

I just wish AMD wouldn't have the high OpenCL <-> D3D9 interop costs. That problem eats away so much of the raw speed advantage AMD has in OpenCL... :(

Is that a driver or an architecture problem?

[Procrastinating]

Pretty much the only reason I don't watch full-screen exclusive at this stage, is because the seek bar is terrible. For MPC-HC, the design is completely different(maybe a custom texture would be nice, to make it fit the given player's aesthetic?), and it neither marks or labels chapters or timestamps. If I want to skip to a timestamp or check a chapter, I have to exit full-screen, find the mark, skip, then enter full-screen again. This should not need to happen.

[XMonarchY]

I tested "ordered dithering" + "use colored noise" + "change dither for every frame" and they do not affect measurement results for me when compared against "ordered dithering"-only.

[cyberbeing]

Is that a driver or an architecture problem?
Only AMD would know. It's a problem which madshi reported to AMD back in 2012 when they initially added support for D3D9 interop, yet something they've never cared to fix in either drivers or new hardware over the last couple years. As long as madVR and DXVA remain tied to D3D9, he's stuck with it.

[Farfie]

Pretty much the only reason I don't watch full-screen exclusive at this stage, is because the seek bar is terrible. For MPC-HC, the design is completely different(maybe a custom texture would be nice, to make it fit the given player's aesthetic?), and it neither marks or labels chapters or timestamps. If I want to skip to a timestamp or check a chapter, I have to exit full-screen, find the mark, skip, then enter full-screen again. This should not need to happen.

If you're using MPC-HC, page up and page down moves you through chapters to the left and to the right respectively of the seekbar, regardless of whether the seekbar shows them. I'm sure you could also set keybinds for most players as well, though I don't know for sure.

[Asmodian]

Pretty much the only reason I don't watch full-screen exclusive at this stage, is because the seek bar is terrible. For MPC-HC, the design is completely different(maybe a custom texture would be nice, to make it fit the given player's aesthetic?), and it neither marks or labels chapters or timestamps. If I want to skip to a timestamp or check a chapter, I have to exit full-screen, find the mark, skip, then enter full-screen again. This should not need to happen.

Zoom Player has an option to draw its OSD through the madVR API which keeps FSE active while showing a full featured control bar. I can use its buttons to skip to next/prev chapters or click to seek to any spot on the timeline while in FSE.

[leeperry]

Zoom Player has an option to draw its OSD through the madVR API which keeps FSE active while showing a full featured control bar. I can use its buttons to skip to next/prev chapters or click to seek to any spot on the timeline while in FSE.
So does PotP, it's fully skinnable and does show markers for MKV/DVD chapters or files opened in seamless mode(up to 1000 simultaneously).

[madshi]

Is that a driver or an architecture problem?
I think it should be a driver issue.

Only AMD would know. It's a problem which madshi reported to AMD back in 2012 when they initially added support for D3D9 interop, yet something they've never cared to fix in either drivers or new hardware over the last couple years. As long as madVR and DXVA remain tied to D3D9, he's stuck with it.
I've not tested this, but I doubt that OpenCL interop would be faster with D3D11. Maybe I *should* test it. After all, I could do D3D9->D3D11->OpenCL->D3D11->D3D9. Ouch.

Pretty much the only reason I don't watch full-screen exclusive at this stage, is because the seek bar is terrible. For MPC-HC, the design is completely different(maybe a custom texture would be nice, to make it fit the given player's aesthetic?), and it neither marks or labels chapters or timestamps. If I want to skip to a timestamp or check a chapter, I have to exit full-screen, find the mark, skip, then enter full-screen again. This should not need to happen.
As Asmodian and leeperry already noted, it's up to the media player to draw their own GUI/seekbar in madVR's fullscreen exclusive mode. madVR offers APIs for that. Of course it means extra work for the media player devs. Because of that I've implemented that seekbar, so that there's at least *something* you can use for media players which have not implemented their own GUI in madVR's FSE mode. Yes, madVR's own seekbar is quite limited in design quality and functionality, but you'll have to live with that for now. At some point I'll probably redesign the whole madVR GUI. But it'll take some time until I get to that, because there are still several features missing in madVR, which I might more important than prettifying the seekbar.

I tested "ordered dithering" + "use colored noise" + "change dither for every frame" and they do not affect measurement results for me when compared against "ordered dithering"-only.
Ok, thanks!