Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 25th January 2014, 11:08   #21761  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,732
Quote:
Originally Posted by G_M_C View Post
Is is just me, and am i wrong when i notice that most reports here are of people that are using an Nvidia card + geforce drivers ?
opencl plus nvdia is not working and well known by madshi.

using exclusive fullscreen and switching the file with page up or mouse button 4/5 in mpc-hc frezzes the image but sound is still working like using opencl with nvidia but this happens with amd and no opencl options! it is still possible to stop playback with pressing the left mouse button but to close or leave the frozen image alt f4 is needed.

a vfr file runs almost fine with 86.9 6.5 ms but is runs very very bad with 87f 11 ms i can use spline3 ar with 86.9 but 87f doesn't work with bilinear. i don't think this is related to the "high" cpu usage from the debanding+ builds.

amd 6770 13.12
phenom 2 x4 955

Last edited by huhn; 25th January 2014 at 11:42. Reason: vfr not vbr
huhn is offline   Reply With Quote
Old 25th January 2014, 11:26   #21762  |  Link
sdancer75
Registered User
 
sdancer75's Avatar
 
Join Date: Jul 2013
Posts: 90
Quote:
Originally Posted by madshi View Post

Look at "madVR\developers\mvrInterfaces.h". If you know how to use e.g. VMR9, using madVR is not that much different. madVR supports many of the VMR9 interfaces, plus all those private ones listed in the mentioned header file. You can also look at e.g. MPC-HC or MPC-BE, which are open source projects supporting madVR.
Hi,

1) IVideoWindow Interface does not support windowless mode and the interface
IVMRWindowlessControl is not supported. How to make madVR windowless ?

2) 3RD PARTY SOFTWARE RESTRICTIONS : The software "madVR" may not be distributed together with any 3rd party
software without the written consent of the "madVR" author.

So, do I have to pay license fees ?

Regards,
sdancer75 is offline   Reply With Quote
Old 25th January 2014, 11:53   #21763  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by cyberbeing View Post
And yes, the CPU load regression began in the very first deband test build. CPU load in 0.87.0 is slightly higher (+0.4%), but the significant doubling in madVR CPU usage started with this first deband test build.
Ok, can you please retest with the 87g build? If the problem is still there, please try the "madVR - cyber.ax" in the 87g rar file. Does that fix the problem? If not, how can I reproduce the problem? I've tested with DXVA2 decoding here with my AMD card, to avoid having the software decoder screw CPU consumption measurements up, and I'm getting 0.7% CPU usage in MPC-HC, both with v0.86.11 and v0.87f.

Quote:
Originally Posted by DragonQ View Post
Nope, all the new features, including debanding, are definitely off.
Ok. Can you please try 87g? If the problem still occurs, please try the "madVR - dithermod.ax" instead. Does that fix the problem? If not try setting the display to 7bit instead of 8bit. That will switch to a simpler dithering method. Does that fix the problem? If not, please try turning dithering completely off for both v0.86.11 and v0.87.0g and compare whether that makes them perform identically or not. If not, at least I'll know that the problem is not caused by the changes in the dithering pixel shader...

Quote:
Originally Posted by noee View Post
Clocked the chip to 3.5Ghz (NB @ 2.4Ghz) and everything works great, no drops, full queues. Back to bone stock BIOS (2.6Ghz), no joy.

At stock, when upload queue goes empty, CPU is at ~55-60% per ProcessExplorer. On .86, it hovers ~34%, same video, same settings.
Ok. Can you please try 87g with debanding turned *off*? Does that fix the uploading problem for you? If so, does turning debanding on - and choosing a higher setting for fades bring the problem back?

Quote:
Originally Posted by DarkSpace View Post
Thanks for the explanation. The unwanted shift is exactly why I was asking... I'm curious: What kind of interpolation pass are you running?
Lanczos3AR in only one dimension (Y, IIRC) to shift the image 0.5 pixels.

Quote:
Originally Posted by djfred93 View Post
ccc 13.12
Does 87g fix the problem? Make sure you disable all OpenCL related options, just to be safe...

Quote:
Originally Posted by livache View Post
.87 with smooth motion turned on returns black image when playing videos with mod2 height in normal window (100% - unresized). After resizing the window or turning to full screen, the image appears. > mod2 seem to play fine with smooth motion on.
GPU: GTX560Ti.
Quote:
Originally Posted by Q-the-STORM View Post
also, some files give a black screen, until i resize them (doesn't matter if up or down)... what these files have in common is that they are 1280x718 with DAR set to 16:9 according to mediainfo...
so it's black until i resize the window, but when I resize the window back to the original size, the frame is black again...
1280x720 content is working fine, so there might to be an issue with DAR... but 960x720 content with DAR set to 16:9 is also working fine, so it's not a universal problem with DAR...

9MB sample file

//just disabled smooth motion and there is no more black frame with the 1280x718 file.... it might have nothing to do with DAR... might be the mod2 problem livache is talking about...
Thanks guys, yes, same problem. Was a bug in the modified frame cropping logic, in combination with Smooth Motion FRC. Should be fixed in 87g.

Quote:
Originally Posted by Q-the-STORM View Post
there is a issue with deinterlacing... when I play 1080i MBAFF interlaced content or telecined NTSC DVDs (basically content that has some kind of interlacing), I get a black screen when having deinterlacing enabled (if in doubt, deactivate deinterlacing)... works fine when I disable deinterlacing in madVR...
Does it still occur with 87g? If so, can I have a small sample, just to make sure I'm testing with the same stuff? This is with video mode deinterlacing, not forced film mode, right? Does the problem also occur with forced film mode? Does it have anything to do with Smooth Motion FRC?

Quote:
Originally Posted by noee View Post
madshi, to follow up on your question regarding the impact of "use OpenCL to process DXVA NV12 surfaces...", yes, this has quite an impact here on my setup (HD6570). With that option enabled, I get dropped and repeated frames, video is not quite a slideshow, but close. All is well with that option disabled (default).
Ok, interesting. Seems the 6570 doesn't like this option. It has pretty much zero impact on my 7770.

Quote:
Originally Posted by Deim0s View Post
Except OpenCL, stopped working algorithms "image downscaling" (...or something else).
While playing content UHD (4k):
in windowed mode slideshow (madVR output),
when switching to full screen - black screen

In version 0.86.11 worked perfectly.

latest nightly MPC-HC, latest LAV Filters
Win7 32bit, i7-2600K, ASUS GTX770 2GB, ASUS VG278 27" 120Hz
Does the problem still occur with the 87g test build, if you disable all OpenCL related options and if you disable debanding? (Make sure the "use random dithering..." option in the "trade quality..." section is checked/enabled.)

Quote:
Originally Posted by kasper93 View Post
I have a problem with DXVA deinterlacing. "DXVA processing fail" when I open interlaced content. Log from latest test build https://dl.dropboxusercontent.com/u/16282309/madVR/madVR_deint.7z

I can manually enable deinterlacing later, but initially it fails.
Does it still occur with 87g? Which GPU, which OS?

Quote:
Originally Posted by truexfan81 View Post
even a simple rule such as:
if (srcFps == 60) "Profile 2" else "Profile 1" fails to use the correct profile
The FPS information is coming from the decoder in a weird format. After convertion to something we humans can make sense of, it's not perfectly exact, anymore. Furthermore, it's likely to be around 59.940 and not 60.000. Your check "if (srcFps == 60)" would only work as intended if the FPS information coming from the decoder were exactly 60.000000000, without the slighest deviation. That's not going to happen. So it's better to use ">" or "<" instead of "==". E.g. use "if (srcFps > 59)" to give it a bit of safety margin.

Quote:
Originally Posted by Nachbar View Post
Same here. All i did was copy the new madvr over the previous version. I tried the uninstall and install.bat after mpc-hc crashed and that did not fix it. Weird thing is even though it will display a window that mpc-hc crashed unexpectedly the video still plays in the background fine.

My system: Intel Core i5 3570k, Nvidia Geforce 560 Ti, Windows 7, MPC-HC 1.7.1, madvr 1.8.8.1 (also tried 1.8.8.0 since it recently updated but the problem still occurs), LAV 60.1, xy-vsfilter 3.0.0.211
Does it still happen with 87g? Even with all OpenCL related options turned off ("use random dithering..." turned *on* in the "trade quality" section)?

Quote:
Originally Posted by SecurityBunny View Post
Figured I'd report my findings to help narrow down bugs.

Using MadVR 0.87.1, according to control panel. (AKA 0.87f)
MPC-HC 1.7.1.383 (Latest nightly.)

Nvidia GTX 780 graphics card. Quadro Driver 334.67.
Intel 3770k @ 4.2 GHZ

Tested with lav hardware acceleration 'none' and 'dxva2 (native)'. Tested in windowed mode.

No 'trade quality for performance' options checked with smooth motion enabled, black screen.

Only 'use random dithering instead of OpenCL error diffusion' under 'trade quality for performance' checked with smooth motion enabled, flashing screen between picture and black until completely black.

Only 'use random dithering instead of OpenCL error diffusion' under 'trade quality for performance' checked with smooth motion disabled, video plays back normally.
Can you please retest with 87g?

Quote:
Originally Posted by TheProfileth View Post
Have you considered adding in a upscale/downscale gaussian resize kernel, it just happens to my favorite blurring kernel so I thought I would ask.
Do you really want to blur things for realtime playback? Why?

Quote:
Originally Posted by za222 View Post
I had the same problem in 0.87.

But for me the problem is not fixed in test build 0.87f.
Instead, when opening a video file the whole screen flickers very shortly, and then i get a *green* video screen with some weird artifacts on the top-left:
http://i.imgur.com/CstoDBp.png

Windows 7 x64 / MPC-HC x86 / LAV / Geforce 8800GTS
Weird. Does this still happen with 87g? If so, does it happen with *all* videos or just with some? Is it related to Smooth Motion FRC or not?

Quote:
Originally Posted by AngelGraves13 View Post
Playback freezes when dragging the window to another monitor or to the TV. Dragging it back does not fix it.

MPC-BE and latest 0.87f. all 0.87 versions do this...going back to old version.
Does it still happen with 87g?

Quote:
Originally Posted by ryrynz View Post
Have had this happen on the c as as f builds, bringing up the OSD and then using CTRL-J again doesn't make the OSD disappear on the black bars of the window (4:3 image on 6:10 screen)
This is exactly the Intel driver problem everyone is talking about. The "BorderColor" tweak mentioned in the v0.87.0 release notes should fix this.

Quote:
Originally Posted by pie1394 View Post
Test 0.87f build + MPC-BE 1.3.0.3 + XySubFilter 3.1.0.546 + GeForce driver 320.49 and 332.32 with IonLE(GF9300) on Win7 x64 SP1. The most ordinatory options available in 0.86.x build + debanding option work fine except following:

1. P10 contents shows nothing on the video window.
2. SmoothMotion option causes black rectangle box on ASS sub-title text. (this time it always presents no matter what option or configuration reset operation...)
3. Chroma NNEDI3 scaling option causes GREENish video
4. Any other option which requires OpenCL causes BSOD... @_@
OpenCL not working is currently to be expected, sadly. Will work on that later. BSOD is very very bad, of course. I kind of hate NVidia right now...

P10 and SmoothMotion making problems: Does this still occur with 87g? Even with debanding turned off?

Quote:
Originally Posted by G_M_C View Post
Is is just me, and am i wrong when i notice that most reports here are of people that are using an Nvidia card + geforce drivers ?
It's not just you. It's the pretty bad NVidia OpenCL support which is causing a lot of trouble. For now I'd advise all NVidia users to stay away from the new OpenCL options, until I found some time to investigate a proper workaround. Some problems are not related to OpenCL/NVidia, though.

Quote:
Originally Posted by huhn View Post
using exclusive fullscreen and switching the file with page up or mouse button 4/5 in mpc-hc frezzes the image but sound is still working like using opencl with nvidia but this happens with amd and no opencl options! it is still possible to stop playback with pressing the left mouse button but to close or leave the frozen image alt f4 is needed.

a vfr file runs almost fine with 86.9 6.5 ms but is runs very very bad with 87f 11 ms i can use spline3 ar with 86.9 but 87f doesn't work with bilinear. i don't think this is related to the "high" cpu usage from the debanding+ builds.
Does this still happen with 87g, even with debanding disabled? If so, please try the "madVR - dithermod.ax" file with the other related things I suggested somewhere above. Thanks.

Quote:
Originally Posted by sdancer75 View Post
1) IVideoWindow Interface does not support windowless mode and the interface
IVMRWindowlessControl is not supported. How to make madVR windowless ?
madVR currently does not support windowless, unfortunately. This is planned for a future version. But not any time soon.

Quote:
Originally Posted by sdancer75 View Post
2) 3RD PARTY SOFTWARE RESTRICTIONS : The software "madVR" may not be distributed together with any 3rd party
software without the written consent of the "madVR" author.

So, do I have to pay license fees ?
Don't stop reading there. Read to the end of the "3RD PARTY SOFTWARE RESTRICTIONS" section.

-------

So here's 87g:

http://madshi.net/madVR87g.rar

NVidia users, please stay away from all OpenCL related options for now. Also make sure the "use random dithering..." option in the "trade quality..." section is checked/enabled. I'll look into making OpenCL work for NVidia once all the other problems (introduced by v0.87) are solved.
madshi is offline   Reply With Quote
Old 25th January 2014, 11:57   #21764  |  Link
PixelH8
Registered User
 
Join Date: Dec 2012
Posts: 5
Nvidia user here. Let me start by saying that I do NOT have any black screen issues when using the OpenCL error diffusion instead of random dithering. Instead, I get swapped red and blue channels.
This happens on two systems I've tried the new main 0.87 build on.
The primary system has a GTX 560 Ti w/driver 306.97
The second system has a GTX 460 w/driver 310.90
Both are running Windows 7 64-bit with MPC-HC 1.7.1.220, LAV filters 0.59.1 and XySubFilter 3.1.0.546.

The swapped colors are easy to correct, as I simply use the ffdshow raw video filter's built-in avisynth module and add the line: "SwapUV" and voila, problem solved.
This was even easier since I was already using the ffdshow raw avisynth filter to decimate 29.97 fps video to 23.976 fps on-the-fly to eliminate that annoying judder on some old videos.

On average, toggling OpenCL error diffusion adds 10% GPU load to whatever the base load is. Though for me that's not an issue as the GTX 460 never reaches even 50% load with all the trade-quality-for-performance options disabled.

Never tried any of the NNEDI3 stuff as I see no need. Same with smooth motion conversion. That said, I really like the new deband filters. They work well.
PixelH8 is offline   Reply With Quote
Old 25th January 2014, 12:03   #21765  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by PixelH8 View Post
Nvidia user here. Let me start by saying that I do NOT have any black screen issues when using the OpenCL error diffusion instead of random dithering. Instead, I get swapped red and blue channels.
This happens on two systems I've tried the new main 0.87 build on.
The primary system has a GTX 560 Ti w/driver 306.97
The second system has a GTX 460 w/driver 310.90
Both are running Windows 7 64-bit with MPC-HC 1.7.1.220, LAV filters 0.59.1 and XySubFilter 3.1.0.546.

The swapped colors are easy to correct, as I simply use the ffdshow raw video filter's built-in avisynth module and add the line: "SwapUV" and voila, problem solved.
This was even easier since I was already using the ffdshow raw avisynth filter to decimate 29.97 fps video to 23.976 fps on-the-fly to eliminate that annoying judder on some old videos.

On average, toggling OpenCL error diffusion adds 10% GPU load to whatever the base load is. Though for me that's not an issue as the GTX 460 never reaches even 50% load with all the trade-quality-for-performance options disabled.

Never tried any of the NNEDI3 stuff as I see no need. Same with smooth motion conversion. That said, I really like the new deband filters. They work well.
Now this is weird. Why is it working for you - and for me, too. But not for everyone else? I'm quite confused. BTW, I've already fixed the swapped color channels in the latest test build...
madshi is offline   Reply With Quote
Old 25th January 2014, 12:10   #21766  |  Link
MSL_DK
Registered User
 
Join Date: Nov 2011
Location: Denmark
Posts: 137
Is there any way to check an mkv for faults resulting in dropped frames and presentation glitches?

Thanks for the new release!
MSL_DK is offline   Reply With Quote
Old 25th January 2014, 12:14   #21767  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
0.87g has essentially resolved the CPU load issue. It's now close enough that the remaining difference can be chalked up to new features added.

madVR 0.86.11 = 1.52% +/- 0.02% CPU load

madVR 0.87g = 1.63% +/- 0.02% CPU Load

The special 'cyber' build seems slightly worse with 1.67% +/- 0.02% CPU load.
cyberbeing is offline   Reply With Quote
Old 25th January 2014, 12:29   #21768  |  Link
noee
Registered User
 
Join Date: Jan 2007
Posts: 530
Quote:
Originally Posted by madshi
Ok. Can you please try 87g with debanding turned *off*? Does that fix the uploading problem for you? If so, does turning debanding on - and choosing a higher setting for fades bring the problem back?
Quite impressive results with .87g. Yes, it appears to be back to .86 perf levels. In fact, maybe even better, queues are all maxed full.

So, I decided to enable debanding and Error Diffusion, and it's working great with those options too. Maxed out queues, no drops, excellent perf. We'll see what happens with NNEDI, but that might be the line for this GPU (HD6570).
noee is offline   Reply With Quote
Old 25th January 2014, 12:30   #21769  |  Link
PixelH8
Registered User
 
Join Date: Dec 2012
Posts: 5
Oh goodie. I just tried the latest madVR87g build and the swapped colors are definitely gone. But the not-so-little red box that sometimes flashes in the upper left corner is supposed to be there right? To indicate that this is a test build?

I also have a third system with a GTS 250 that I'm in the middle of repairing. As soon as I'm done I'll let you know how the new build works on that system as well.
PixelH8 is offline   Reply With Quote
Old 25th January 2014, 12:34   #21770  |  Link
Siso
Registered User
 
Siso's Avatar
 
Join Date: Sep 2013
Location: Bulgaria
Posts: 389
Quote:
Originally Posted by madshi View Post
Now this is weird. Why is it working for you - and for me, too. But not for everyone else? I'm quite confused. BTW, I've already fixed the swapped color channels in the latest test build...
I can confirm the swapped color channels too.
GTX 550 ti, 326.19

MPC-BE latest stable version, lav filters 0.60.1, xy-vsfilter 3.0.0.236

I'm going to try 0.87g

Last edited by Siso; 25th January 2014 at 12:36.
Siso is offline   Reply With Quote
Old 25th January 2014, 12:34   #21771  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Ooopsi-daisy, forgot to reenable optimization in the MSVC++ compiler settings. Does this one bring 0.87g back to 1.52%, cyberbeing? Please also try enabling debanding with different settings for fade in/out detection, to see how that impacts CPU performance - because in that case madVR will fall back to my SSE2 uploading code, instead of using memcpy. Would be interesting to see how it compares...

http://madshi.net/madVRoptimized.rar (87g, only release mode madVR.ax)
madshi is offline   Reply With Quote
Old 25th January 2014, 12:36   #21772  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by PixelH8 View Post
Oh goodie. I just tried the latest madVR87g build and the swapped colors are definitely gone. But the not-so-little red box that sometimes flashes in the upper left corner is supposed to be there right? To indicate that this is a test build?
Ooops, sorry. That's a debug rectangle which indicates that madVR detected a fade in/out. I sometimes enable that so I can see whether fade in/out detection works or not. I'll disable it again for the next build.

Quote:
Originally Posted by noee View Post
Quite impressive results with .87g. Yes, it appears to be back to .86 perf levels. In fact, maybe even better, queues are all maxed full.

So, I decided to enable debanding and Error Diffusion, and it's working great with those options too. Maxed out queues, no drops, excellent perf. We'll see what happens with NNEDI, but that might be the line for this GPU (HD6570).
Good to hear! I did do some changes which I hoped would improve performance slightly.

Last edited by madshi; 25th January 2014 at 12:38.
madshi is offline   Reply With Quote
Old 25th January 2014, 12:42   #21773  |  Link
SecurityBunny
Registered User
 
Join Date: Jul 2013
Posts: 76
Quote:
Originally Posted by madshi View Post

Can you please retest with 87g?

Random dithering with smooth motion no longer flashes the screen. OpenCL error diffusion (unchecked use random dithering) still causes a black screen unfortunately. I'll take your advice and stay away from OpenCL for the time being. Thanks for the smooth motion fix.
SecurityBunny is offline   Reply With Quote
Old 25th January 2014, 12:49   #21774  |  Link
pie1394
Registered User
 
Join Date: May 2009
Posts: 212
Quote:
Originally Posted by madshi View Post
P10 and SmoothMotion making problems: Does this still occur with 87g? Even with debanding turned off?
This version is actually worse on the ION-LE platform. None of these two issues is fixed. Instead it introduces a new issue:

- Video screen becomes totally black when the 1st subtitle arrived from XySubFilter -- if SmoothMotion logic is NOT engaged. It happens to any 24-frames or 60-fields contents regardless of resolution. Debanding option ON/OFF does not matter, either.
pie1394 is offline   Reply With Quote
Old 25th January 2014, 12:52   #21775  |  Link
Soukyuu
Registered User
 
Soukyuu's Avatar
 
Join Date: Apr 2012
Posts: 169
Quote:
Originally Posted by madshi View Post
Now this is weird. Why is it working for you - and for me, too. But not for everyone else? I'm quite confused.
I smell driver issue. Everyone with failing openCL features, including me, are on one of the newest driver versions. Maybe nVidia broke something in the update?
Soukyuu is offline   Reply With Quote
Old 25th January 2014, 12:53   #21776  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by madshi View Post
Ooopsi-daisy, forgot to reenable optimization in the MSVC++ compiler settings. Does this one bring 0.87g back to 1.52%, cyberbeing?
That build is even better, ~1.26% CPU load.


Quote:
Please also try enabling debanding with different settings for fade in/out detection, to see how that impacts CPU performance - because in that case madVR will fall back to my SSE2 uploading code, instead of using memcpy. Would be interesting to see how it compares...
I'll look into this.
cyberbeing is offline   Reply With Quote
Old 25th January 2014, 12:55   #21777  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by pie1394 View Post
This version is actually worse on the ION-LE platform. None of these two issues is fixed. Instead it introduces a new issue:

- Video screen becomes totally black when the 1st subtitle arrived from XySubFilter -- if SmoothMotion logic is NOT engaged. It happens to any 24-frames or 60-fields contents regardless of resolution. Debanding option ON/OFF does not matter, either.
Hmmmm... I've tried all of this on my NVidia 9400 GPU which had problems with black rectangles when using XySubFilter in the past. But no problems here, whatsoever. How can I reproduce these issues? Maybe you can provide me with small samples to test with, in case it has something to do with the samples somehow?

Quote:
Originally Posted by cyberbeing View Post
That build is even better, ~1.26% CPU load.
Cool!

Quote:
Originally Posted by Soukyuu View Post
I smell driver issue. Everyone with failing openCL features, including me, are on one of the newest driver versions. Maybe nVidia broke something in the update?
That is quite possible. Anyone willing to downgrade to the driver versions used by PixelH8 to check if that fixes the OpenCL issues?
madshi is offline   Reply With Quote
Old 25th January 2014, 12:57   #21778  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
87g with Debanding, 4K 60fps video (downscaled to HD with Catmull-Rom) works like charm without frame skipping (although buffers not fully full).
Without Debanding the buffers completely full with this video.

"1 frame drop every t" & "clock deviation %" works better than 86.11, its a lot more stable.
Performance up to par with 86.11 or even better, Perfect.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 25th January 2014 at 13:23.
James Freeman is offline   Reply With Quote
Old 25th January 2014, 13:02   #21779  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
madVR v0.87.1 released

http://madshi.net/madVR.zip

Code:
* fixed: CPU consumption was unnecessarily high
* fixed: auto profile switching didn't fully work
* fixed: uploading was very slow, resulting in performance problems
* fixed: chroma channels were swapped when using error diffusion with NVidia
* fixed: some OpenCL crashes when using OpenCL 1.2 DLL with NVidia
* fixed: smooth motion FRC produced black image in some situations
* fixed: video mode deinterlacing was completely broken
There may still be some problems left. But there's definite improvement over v0.87.0, so I've decided to release v0.87.1 now.

Current theory is that older NVidia drivers might make OpenCL work with madVR, and that newer drivers might have broken something. Drivers 306.97 are reported to be working with GTX 560 Ti. And drivers 310.90 are reported to be working with GTX 460. This needs to be double checked.
madshi is offline   Reply With Quote
Old 25th January 2014, 13:07   #21780  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,235
I tried the MadVR optimised one, and it didn't even load! (MPC-HC used a different renderer). I then went back and realised the previous version I had was 0.87E or 0.87F, so I copied over the files from 0.87G, then used the MadVR optimised version and it works fine .
burfadel is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 06:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.