madVR - high quality video renderer (GPU assisted) [Archive] - Page 538

dansrfe

10th July 2014, 02:41

Did it add a key to the registry with your GPU model, or is that still missing?

What do you have configured in madVR for your settings (chroma upscaling, image doubling, image upscaling, image downscaling, general settings, smooth motion, dithering, etc)

It didn't add a key under OpenCL.

Reduce banding artifacts - low/high
Chroma/Image upscaling - Jinc 3 AR
Image doubling - none checked
Image downscaling - CR AR LL

Enable windowed overlay - checked
use separate device for presentation - checked

CPU queue - 16
GPU queue - 12

Windowed - 8 frames, all flushes off
Exclusive - 8 frames, no 3s delay, all flushes off

SmoothMotion - only if judder without it
Dithering - ED 2, use colored, change dither per frame
Trade quality/performance - none checked

The system has a 4712HQ and GT 750M.

Anime Viewer

10th July 2014, 03:10

It didn't add a key under OpenCL.

Reduce banding artifacts - low/high
Chroma/Image upscaling - Jinc 3 AR
Image doubling - none checked
Image downscaling - CR AR LL

Enable windowed overlay - checked
use separate device for presentation - checked

CPU queue - 16
GPU queue - 12

Windowed - 8 frames, all flushes off
Exclusive - 8 frames, no 3s delay, all flushes off

SmoothMotion - only if judder without it
Dithering - ED 2, use colored, change dither per frame
Trade quality/performance - none checked

The system has a 3770K and GT 750M.

All of those settings look pretty standard. If any of them were the cause of the conflict I'd think it might be the overlay or use separate device for presentation options. You could try with those unchecked and see if it makes a difference.

I'm kind of surprised that it didn't add the registry key (I doubt madshi removed the coding for that option).

Have you changed any of the Nvidia Global or (renamed mpc-hc) Program settings (aside from graphics processor selection) from their default settings? (If you're not sure you can click on the restore button in those manage 3d settings screens).

What version of mpc-hc is running on your system?

ryrynz

10th July 2014, 03:11

Just had a play with the buffer settings.. after ticking use separate device and then increasing and then later decreasing the CPU and GPU buffers I had MadVR crash, it gave me the option to submit a log.. not sure if that did anything though. Can't seem to reproduce it.. fairly sure I've had this happen before a long time ago.

If any of them were the cause of the conflict I'd think it might be the overlay or use separate device for presentation options.

True, I think Dan shouldn't have either of those enabled to avoid possible issues. Also not having any flushing is almost asking for problems too, set full defaults and play from there, standard troubleshooting practice.

dansrfe

10th July 2014, 04:52

All of those settings look pretty standard. If any of them were the cause of the conflict I'd think it might be the overlay or use separate device for presentation options. You could try with those unchecked and see if it makes a difference.

I'm kind of surprised that it didn't add the registry key (I doubt madshi removed the coding for that option).

Have you changed any of the Nvidia Global or (renamed mpc-hc) Program settings (aside from graphics processor selection) from their default settings? (If you're not sure you can click on the restore button in those manage 3d settings screens).

What version of mpc-hc is running on your system?

Latest nightly MPC-HC (7/6/14). I clicked Restore on Nvidia Global and Program settings just in case. I've also tried disabling overlay and use separate device for presentation and still the same problem persists.

I initially thought it was due to ED 2 dithering however the MPC-HC screen remains black even with that set to Ordered dithering.

EDIT: Forgot to mention that this is on a laptop using a 4712HQ.

ryrynz

10th July 2014, 05:33

the same problem persists.

restore default settings.bat

dansrfe

10th July 2014, 05:37

restore default settings.bat

Tried it, still same problem.

Soukyuu

10th July 2014, 12:17

I expect pretty much zero difference because (with a few exceptions) all the work is done on the GPU and the GPU doesn't care whether the CPU code is running in 32bit or 64bit.Maybe instead of porting madvr to 64-bit you could somehow make a wrapper to load the 32-bit version into a x64 program? Seeing how Microsoft insists on dragging the whole 32-bit baggage along in form of wow64 makes me think that could be possible.

huhn

10th July 2014, 16:54

Maybe instead of porting madvr to 64-bit you could somehow make a wrapper to load the 32-bit version into a x64 program? Seeing how Microsoft insists on dragging the whole 32-bit baggage along in form of wow64 makes me think that could be possible.

i think is more about how to spend time.

madshi

10th July 2014, 17:06

I don't think they are doing something wrong. I think that doing half the processing in linear light for only one of the channels is just asking for trouble. Not only that but hoping that an upscaling algorithm yields the same result as a different upscaling algorithm combined with a downscaling algorithm might just be a bit too optimistic.

The reason that linear light is especially bad could probably be explained by considering the way edges are treated in gamma light and linear light:

To leave edges intact it's probably important that the line running exactly through the middle of an edge should remain at the same location. But in gamma light and linear light there's a difference between what value is halfway between the colours on the opposing sides, in linear light it's close to the lighter side, and you'd expect that the middle of the edge should have a value close to this average.

So if you have an image with white text on top of a red background you'd expect that doing the processing in linear light would make the letters slightly smaller than doing this processing in gamma light (since in linear light the line midway an edge is close to the lighter side, hence the letters seem smaller). This creates a small region around the letters where the image is neither white nor red, hence black.
You make it sound as if any pixel where the different luma <-> chroma channels produce slightly different results automatically resulted in black pixels. That doesn't make much sense. The luma channel is the most important. For a white/red image, the luma channel is relatively bright for every pixel. It doesn't matter much whether the chroma channels align perfectly to the luma channel or not, the chroma channels don't have the power to turn the overall pixel to black, because the luma channel alone defines the pixel brightness. The chroma channel can turn a pixel gray or colored, but it can't do much to the pixel brightness, so the chroma channels can't turn a pixel which has a mid gray luma value into a black pixel. That's mathematically totally impossible. If you think about it, if the whole YCbCr logic required a perfect edge match between the luma and chroma channels, the whole concept of 4:2:0 chroma subsampling wouldn't work. The only reason 4:2:0 works is because the chroma channels are allowed to slightly differ from the luma channel without producing dramatic artifacts. You do get some artifacts like color bleeding - but most definitely *not* unexpected black pixels on a red/white image.

For some reason madVR still doesn't render the video. I did a fresh update of the drivers, added the OpenCL key and forceVendor string exactly as described and MPC-HC just plays the audio when the file is opened.

If I attempt to close the player then MPC-HC and madVR processes freeze and need to be killed.
Try installing/updating Direct3D9 by using the Direct3D9 web installer. Newer OSs might not have D3D9 fully installed. Do all the other renderers work perfectly?

Maybe instead of porting madvr to 64-bit you could somehow make a wrapper to load the 32-bit version into a x64 program?
Technically not possible.

tjcinnamon

10th July 2014, 17:15

nevcairiel

10th July 2014, 17:15

Technically not possible.

And probably also quite a bit more work than spending an afternoon making sure the existing code builds in x64 and the build system is up to snuff... :)

dansrfe

10th July 2014, 17:53

Try installing/updating Direct3D9 by using the Direct3D9 web installer. Newer OSs might not have D3D9 fully installed. Do all the other renderers work perfectly?

Ah, I should have tested other renderers as well. The problem is in the selection of the "High-performance NVIDIA processor" on the renamed mpc-hc. If I remove the entry from Nvidia's control panel then it works with madVR fine but still uses the integrated gpu. I installed D3D9 from the web installer but that didn't work either. :(

I'm not sure why I'm having this problem since this is on Windows 8.1 and using the latest beta Nvidia driver.

XMonarchY

10th July 2014, 18:52

I suddenly have many dropped frames when I playback any video. Could it be nVidia 340.43 drivers? I can't even use NNEDI3 any neurons or Jinc or other options without without many dropped frames... No doubling or quadrupling is enabled. I use latest MPC-HC, LAV, ReClock, and madVR. I set my vdieocard to stock clocks and it doesn't produce any issues in games even when its overclocked, so that can't be the issue...

I don't get it - I haven't changed a thing since the times when I had 0 dropped frames.., except for the drivers. Anyone else having issues with 340.43?

madshi

10th July 2014, 18:52

How well does MadVR upconvert 1080p to 4k. Is this incredibly processor intensive? Is it dual or quad upconvert (seems that it wouldn't need to down-convert because 1080p and 2160p are divisible by each other.
madVR does this just fine and in very good quality. With 1080p sources it's "simple" resolution doubling. With movie sources (24fps) already a mid range GPU might be able to do this with NNEDI3 when using 16 neurons. If you want to use more neurons, or if you need support for higher fps then you may need a performance or high-end GPU. Or you could make do with Jinc3 AR upscaling which is not as good as NNEDI3, but probably still better than all anything out there in the consumer electronics world.

And probably also quite a bit more work than spending an afternoon making sure the existing code builds in x64 and the build system is up to snuff... :)
FWIW, it would probably cost 2-3 days, maybe more. I have some hand written SSE2 ASM (intrinsics didn't cut it in some cases) which would have to be converted to external x64 compatible ASM files, and I have some Delphi dlls which have to be carefully converted to x64.

Ah, I should have tested other renderers as well. The problem is in the selection of the "High-performance NVIDIA processor" on the renamed mpc-hc. If I remove the entry from Nvidia's control panel then it works with madVR fine but still uses the integrated gpu. I installed D3D9 from the web installer but that didn't work either. :(

I'm not sure why I'm having this problem since this is on Windows 8.1 and using the latest beta Nvidia driver.
Well, I don't know how to make the NVidia driver work for madVR. madVR doesn't get to pick the GPU used for D3D9. The OS/driver decides which GPU serves which monitor/display. madVR has no way to choose that. So you'll have to find a way to convince the OS or the GPU driver to use the NVidia GPU for MPC-HC/madVR. For most other users it seems that renaming the MPC-HC EXE file does the trick. If that doesn't work for you, then I don't know how to make it work. I don't have access to a shared NVidia/Intel laptop, so I've no experience with this.

I suddenly have many dropped frames when I playback any video. Could it be nVidia 340.43 drivers? I can't even use NNEDI3 any neurons or Jinc or other options without without many dropped frames... No doubling or quadrupling is enabled. I use latest MPC-HC, LAV, ReClock, and madVR. I set my vdieocard to stock clocks and it doesn't produce any issues in games even when its overclocked, so that can't be the issue...

I don't get it - I haven't changed a thing since the times when I had 0 dropped frames.., except for the drivers. Anyone else having issues with 340.43?
Changing drivers isn't that hard. Just go back to the previous driver version to double check. Since the driver version is the only thing you changed, it's by far the most probable cause of the problem.

XMonarchY

10th July 2014, 18:57

Changing drivers isn't that hard. Just go back to the previous driver version to double check. Since the driver version is the only thing you changed, it's by far the most probable cause of the problem.

I checked further and it appears its just a couple of specific rips I made, so that's solved I guess, although I have no idea why or how a video would do that... to itself?

Shiandow

10th July 2014, 19:04

You make it sound as if any pixel where the different luma <-> chroma channels produce slightly different results automatically resulted in black pixels. That doesn't make much sense. The luma channel is the most important. For a white/red image, the luma channel is relatively bright for every pixel. It doesn't matter much whether the chroma channels align perfectly to the luma channel or not, the chroma channels don't have the power to turn the overall pixel to black, because the luma channel alone defines the pixel brightness. The chroma channel can turn a pixel gray or colored, but it can't do much to the pixel brightness, so the chroma channels can't turn a pixel which has a mid gray luma value into a black pixel. That's mathematically totally impossible. If you think about it, if the whole YCbCr logic required a perfect edge match between the luma and chroma channels, the whole concept of 4:2:0 chroma subsampling wouldn't work. The only reason 4:2:0 works is because the chroma channels are allowed to slightly differ from the luma channel without producing dramatic artifacts. You do get some artifacts like color bleeding - but most definitely *not* unexpected black pixels on a red/white image.

The luma for a red/white image isn't that uniform, pure red only has a luma of 0.299. If for whatever reason the luma doesn't rise fast enough then you will see a dark outline around the white regions. What I tried to argue is that bright letters look ever so slightly smaller in linear light, which might explain why downscaling in linear light could cause the letters to become slightly smaller in the luma channel than in the chroma channel.

FWIW 4:2:0 chroma upscaling does exhibit some of the same problems, although it is barely noticeable with most algorithms. Unfortunately I recently discovered that the chromaNEDI algorithm is particularly bad at this.

Also, color bleeding is not the only possible artefact that can be caused by 'bad' scaling of the chroma channel. If you accept that chroma can be too high in some regions then you must also accept that chroma can be too low in some regions. And this does seem to decrease the brightness of those pixels. A few possible explanations for why it looks darker are: YCbCr is not a perfect model of human sight, YCbCr only models human sight when used in linear light, chroma and luma are not orthogonal.

madshi

10th July 2014, 19:15

Shiandow

10th July 2014, 19:52

I think I was probably mistaken to call it "black", you're right that what I described can't cause anything close to black. But if you look at the images in the linear light scaling thread you'll see that the pixels around those letters aren't black either, more of a dark red. This just happens to look like there is a very thin (less than 1 pixel wide) black line around those letters.

But I just realised that using a (linear) downscaling algorithm should give higher values in linear light, not lower, so at this point I'm no longer sure what's causing the dark ringing.

madshi

10th July 2014, 20:03

I'm not sure, either, will need to have a look at it, when I find some time...

Shiandow

10th July 2014, 20:20

Well, not sure if it is any help, but it should be impossible for any linear downscaling algorithm to give lower values in linear light than in gamma light because of Jensen's inequality (http://en.wikipedia.org/wiki/Jensen%27s_inequality). This holds for any algorithm that takes some kind of weighted average of the surrounding pixels and where these weights do not depend on the pixel values, which I think includes all downscaling algorithms used by MadVR. So it seems that it is not just a bad combination of algorithms as I originally thought.

Asmodian

10th July 2014, 20:35

@Shiandow, I can agree with some/most of what you say, but I definitely disagree with your earlier comment: "This creates a small region around the letters where the image is neither white nor red, hence black". There's no way a luma/chroma edge misalignment can cause anything near to black, if the original image is pure red/white. If you still think you're right about that, please give me a numerical example. I think the only reasonable explanation for those black pixels is ringing - or a simple bug in the processing chain.

It is a special case for Red and White. For 255 red (RGB) Y = 72, V = 255, U = 84, For White Y = 255, U & V = 128. So if you display Red's luma with White's chroma you get dark gray.

Shiandow's description is a bit over simplified, it isn't the lack of a value leaving a default black but rather a result of displaying a pixel with red's luma but white's chroma. Even this is over simplified because it isn't the exact color pixel's luma and chroma but the small position differences due to the different resamplers that are interpolating/scaling differently along the edges.

I guess you can think of the black in the red as the white letters' chroma bleeding?

Edit: Blue and white should give the same effect with an even darker black but it might be harder to notice tiny black edges on blue.

Shiandow

10th July 2014, 21:07

Shiandow's description is a bit over simplified, it isn't the lack of a value leaving a default black but rather a result of displaying a pixel with red's luma but white's chroma. Even this is over simplified because it isn't the exact color pixel's luma and chroma but the small position differences due to the different resamplers that are interpolating/scaling differently along the edges.

That's what I originally thought, but I realised that it is mathematically impossible for the downscaling algorithm to give a lower luma when it outputs in linear light instead of gamma light, so something somewhere is not mathematically correct.

madshi

10th July 2014, 21:09

It is a special case for Red and White. For 255 red (RGB) Y = 72, V = 255, U = 84, For White Y = 255, U & V = 128. So if you display Red's luma with White's chroma you get dark gray.
Ok, but it's not black, but darkish gray (RGB value 54,54,54, which is some distance away from black). Furthermore this can only happen with Nearest Neighbor interpolation, which no sane person would ever use. With any sort of linear interpolation this won't happen. Instead you'll get a softly blended Luma and Chroma channel. So it will not be Red's luma exactly, but a mixture of Red's and White's luma, and it will also be a mixture of Red's and White's chroma, which should make the resulting color quite a bit brighter.

dbezerra

10th July 2014, 21:50

Is there a consensus on Luma Doubling vs quadrupling for 480p source, 1080p target?

Basically, is it better to do
480p -> 1920 -> 1080 via quadrupling and downscaling
480p -> 960 -> 1080 via doubling and upscaling (lanczos AR)

michkrol

10th July 2014, 22:18

Is there a consensus on Luma Doubling vs quadrupling for 480p source, 1080p target?

In my opinion quadrupling in this case seems like a complete overkill.
Scale factor for 960->1080 is 1.125, so doubling and downscaling it seems pointless.
If you can use doubling with 128 neurons or quadrupling with 32+32 neurons (random numbers, not sure how the performance actually scales), you might actually get better results from more neurons with "only" doubling and perhaps Jinc3+AR instead of Lanczos+AR.
If you have power to spare and can max both doubling and quadrupling, consider the crazy power consumption/heat you'll be getting.

Anyway, that's just my opinion. Consider running some tests to see for yourself both the image quality and performance/power consumption implications.

Anime Viewer

10th July 2014, 23:03

Ah, I should have tested other renderers as well. The problem is in the selection of the "High-performance NVIDIA processor" on the renamed mpc-hc. If I remove the entry from Nvidia's control panel then it works with madVR fine but still uses the integrated gpu. I installed D3D9 from the web installer but that didn't work either. :(

I'm not sure why I'm having this problem since this is on Windows 8.1 and using the latest beta Nvidia driver.
I'm using Windows 8.1, and the latest Nvidia beta driver (340.42) as well, so I don't think those are the problem. Are you using Windows 64-bit or 32-bit OS?

If you can get to a point where you can pause, right click on a video, and hover over filters - what does it list?

Lets try this to make your registry key. Open a blank text file (notepad or wordpad preferably) and type or paste:

[HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL]
"forceVendor"="Nvidia"

save it as a .reg file, and try importing it into your registry.

I'm also thinking you might want to try using a codec/filter repair tool in case you have broken or incorrectly associated codec.

You could try using the codec tweak tool linked below to check for broken filters/codec, and re-associate filters to types of files.

http://www.softpedia.com/get/Tweak/Video-Tweak/K-Lite-Codec-Tweak-Tool.shtml

After opening the program select:

General: fixes
put a check in detect and remove broken VFW/ACM codecs and detect and remove broken DirectShow filters. (If you want you could also check the re-register base DirectShow filters).

Under Win7DSFilterTweaker Preferred decoders I also recommend settings everything to recommended if given the option.

Well, I don't know how to make the NVidia driver work for madVR. madVR doesn't get to pick the GPU used for D3D9. The OS/driver decides which GPU serves which monitor/display. madVR has no way to choose that. So you'll have to find a way to convince the OS or the GPU driver to use the NVidia GPU for MPC-HC/madVR. For most other users it seems that renaming the MPC-HC EXE file does the trick. If that doesn't work for you, then I don't know how to make it work. I don't have access to a shared NVidia/Intel laptop, so I've no experience with this.

Something that perplexes me about his attempts to get it working is the fact that the system isn't adding the the GPU in the OpenCL part of the madVR registry even after adding the force vendor key we used to use. You didn't disable that did you? (does it only add the OpenCL directory if someone enables an OpenCL feature like using NNEDI3 for doubling or chroma upscaling?)
Oddly he doesn't seem to be the only one encountering this type of problem right now. Its also been reported by someone else here:
http://haruhichan.com/forum/showthread.php?7545-KCP-Kawaii-Codec-Pack&p=41448&viewfull=1#post41448

dansrfe

11th July 2014, 00:04

I added the reg key again, just to make sure. I ran the fixes in the codec tweak tool as well as selected the recommended preferred decoders. I also had previouly disabled Media Foundation and MS Codec Tweaks in Win7DSFilterTweaker.

Upon selecting NNEDI3 for image upscaling, the graphics card key was added under OpenCL, "GeForce GT 750M" with Binary (binary), DriverVersion (string), and KernelCRC (DWORD) inside.

However, the same problem remains as pointed out by the other thread up there as well. Black screen, madVR OSD frozen, audio working. However now I can close the player and MPC-HC and madVR exit gracefully without the need to manually kill the processes.

Filters currently loaded:
- DirectSound: Speakers (Realtek High Defi...
- madVR
- LAV Audio Decoder (internal)
- LAV Video Decoder (internal)
- LAV Splitter Source (internal)

Asmodian

11th July 2014, 00:38

Ok, but it's not black, but darkish gray (RGB value 54,54,54, which is some distance away from black). Furthermore this can only happen with Nearest Neighbor interpolation, which no sane person would ever use. With any sort of linear interpolation this won't happen. Instead you'll get a softly blended Luma and Chroma channel. So it will not be Red's luma exactly, but a mixture of Red's and White's luma, and it will also be a mixture of Red's and White's chroma, which should make the resulting color quite a bit brighter.

I am only thinking about how the artifacts are created in the first place, why AR and/or LL (edit: with downscaling) exaggerate them I cannot explain.

But when using a very sharp resize for luma (like NNEDI) and a softer resize for chroma (anything else) it makes sense the chroma would blur more. Luma isn't blurred very much while chroma is so the border red pixels don't get their luma lightened as much as they get their chroma whitened. I hope that made sense.

Of course the border white pixels get their chroma reddened more then their luma darkened too but that is a light pink so it is not very noticeable.

Neeto

11th July 2014, 06:45

ajp2k11

11th July 2014, 10:00

I've had a problem with MadVR for quite some time now (not sure when it started, maybe with upgrade to Win8) where most files have trouble playing. Most files just play the sound with a black screen, somtimes after quite a while (up to a minute) the picture appears but most of the time the audio hangs too after a while. If I try to go full screen or fast forward MPC-HC hangs.

I'm not sure it's the exact problem though because my system is much more modest and based on AMD graphics (6650M). It sounds similar enough though....

I added the reg key again, just to make sure. I ran the fixes in the codec tweak tool as well as selected the recommended preferred decoders. I also had previouly disabled Media Foundation and MS Codec Tweaks in Win7DSFilterTweaker.

Upon selecting NNEDI3 for image upscaling, the graphics card key was added under OpenCL, "GeForce GT 750M" with Binary (binary), DriverVersion (string), and KernelCRC (DWORD) inside.

However, the same problem remains as pointed out by the other thread up there as well. Black screen, madVR OSD frozen, audio working. However now I can close the player and MPC-HC and madVR exit gracefully without the need to manually kill the processes.

Filters currently loaded:
- DirectSound: Speakers (Realtek High Defi...
- madVR
- LAV Audio Decoder (internal)
- LAV Video Decoder (internal)
- LAV Splitter Source (internal)

ryrynz

11th July 2014, 10:20

Would recommend jumping on the bug tracker (bugs.madshi.net/) and creating a reporting an issue.
Having madshi look at a log would probably be the quickest way of resolving this..

Does changing the refresh rate do anything? Have you tried uninstalling and deleting the drivers in devicemanager and then reinstalling?
make sure use separate device is unchecked.

madshi

11th July 2014, 10:32

FWIW, the bug tracker is for suspected bugs in madVR. dansrfe's problem sounds more like an OS/driver problem or misconfiguration to me, to be honest. These NVidia Optimus systems seem to be a bitch to get to work sometimes, it seems. Although most users seem to have it running fine. It's ridiculous that you have to rename the MPC-HC exe file to have any chance to use the NVidia GPU in the first place. None of this is madVR's fault, from what I can see. That said, I can of course look at a log. Maybe I can see something...

ryrynz

11th July 2014, 13:27

These NVidia Optimus systems seem to be a bitch to get to work sometimes

I've found a number of reports of the same issue over the years with nobody having reported resolving it, with two people having the issue could be good to finally sort it out I guess.

Anime Viewer

11th July 2014, 14:42

However, the same problem remains as pointed out by the other thread up there as well. Black screen, madVR OSD frozen, audio working. However now I can close the player and MPC-HC and madVR exit gracefully without the need to manually kill the processes.

I can't recall if you've already been asked and answered this questions before, but does the same problem occur regardless of if you are playing the video(s) in its/their native resolution window size as well as fullscreen? If it occurs at the video(s) normal window size then we can probably rule out the scaling algorithms as a factor.

Likewise try changing MPC to EVR custom preset from madVR to see if that can rule out both madVR and/or LAV as being related to the issue.

I've found a number of reports of the same issue over the years with nobody having reported resolving it, with two people having the issue could be good to finally sort it out I guess.

There is a driver bug that has existed for a long time, and you may be seeing past reports related to that as opposed to this specific issue being discussed now. I used to have that NNEDI3 driver related issue, but madshi found a work around for the driver bug. I have an Optimus system, and don't currently have any of the types of problems discussed so its not necessarily an Optimus system issue since its not occurring on all systems at this point.

dansrfe

11th July 2014, 15:05

I uninstalled the device driver from Device Manager and re-installed the latest beta Nvidia driver with clean installation selected. I also tried setting Auto-Zoom to 100% to prevent any Image scaling and the same black screen with audio persists.

Here is an attached log: https://www.sendspace.com/file/dij2vd. For some reason I'm still having to manually kill both MPC-HC and madVR again when I need to exit.

Also, madVR is reporting that Overlay is not supported on this GPU in the OSD when Overlay mode is selected. Because of that the above log is in Windowed mode. If I attempt to FSE then madVR's OSD freezes, becomes blurred and extra large.

This seems like an MPC-HC or OS/Driver level problem to me. I can manually select High-performance NVIDIA processor for any other application (including Chrome) and the selected app works as expected including any Flash/HTML5 players. However the fact that madVR detected the GPU and stored the key under OpenCL when I had temporarily selected NNEDI3 under image doubling (any scale) makes me believe that MPC-HC is probably the culprit.

madshi

11th July 2014, 15:43

Two strange things in that log: (1) VSync position information doesn't seem to be coming from the GPU driver. (2) For some reason the decoder doesn't seem to send more than 1 frame.

Don't know, maybe (2) is a consequence of (1) somehow, although I don't know why it would. In any case, (1) seems to be a GPU driver problem.

dansrfe

11th July 2014, 16:56

FWIW, when I manually switch to Integrated Graphics in Nvidia's Control Panel for the renamed mpc-hc, madVR and MPC-HC work as expected.

However if I set it to Auto (Integrated graphics) or High-performance NVIDIA processor, MPC-HC/madVR/all other renderers freeze. The decoder only gives one frame as madshi mentioned as well.

Another interesting observation, when I run madLevelsTweaker, it only lists the GPU as Intel HD Graphics 4600. I'm not even sure how to force 0-255 on the Nvidia output.

clsid

11th July 2014, 17:23

Also re-install the Intel drivers.

Have you tried any games or other Direct3D applications?

dbezerra

11th July 2014, 17:34

In my opinion quadrupling in this case seems like a complete overkill.
Scale factor for 960->1080 is 1.125, so doubling and downscaling it seems pointless.
If you can use doubling with 128 neurons or quadrupling with 32+32 neurons (random numbers, not sure how the performance actually scales), you might actually get better results from more neurons with "only" doubling and perhaps Jinc3+AR instead of Lanczos+AR.
If you have power to spare and can max both doubling and quadrupling, consider the crazy power consumption/heat you'll be getting.

Anyway, that's just my opinion. Consider running some tests to see for yourself both the image quality and performance/power consumption implications.

Thanks. I will play with it during the weekend.

Another question - Looking back at this thread I saw debates over PCI-E version for AMD cards, but what about NVidia? Would an old PCI-E 1.1 impact performance? Or even 1.1 is fine for NVidia based cards?

dansrfe

11th July 2014, 18:14

Also re-install the Intel drivers.

Have you tried any games or other Direct3D applications?

Uninstalled the Intel HD Graphics 4600 device driver from the Device Manager and installed the latest beta driver from Intel. The Intel driver control panel interface got upgraded but aside from that, same problem. :(

I haven't tried any games or Direct3D applications yet. Is there a test application I can run that would determine if the everything is working as expected on the driver side?

huhn

11th July 2014, 18:17

Thanks. I will play with it during the weekend.

Another question - Looking back at this thread I saw debates over PCI-E version for AMD cards, but what about NVidia? Would an old PCI-E 1.1 impact performance? Or even 1.1 is fine for NVidia based cards?

1.1 should be fine for nvidia and MadVR usage.
this issue has something to do how AMD handle d3d <-> opencl (for nnedi/error diffusion) data transfer

Anime Viewer

11th July 2014, 20:11

Uninstalled the Intel HD Graphics 4600 device driver from the Device Manager and installed the latest beta driver from Intel. The Intel driver control panel interface got upgraded but aside from that, same problem. :(

Checking that your Intel gpu driver was updated was going to be my next recommendation, but I see you've now done that with out it making a difference.

Do you have all the available Windows critical updates (detected by Windows Update) installed? Are you using 64-bit Windows, or 32-bit Windows?

Since madshi pointed out v-sync issues based on the log it may be worth experimenting with those settings in Nvidia control panel. The default should be "Use global settings (Use the 3D application to settings)". First try it with that configured to off for the mpc file under program settings. If that doesn't work try forcing it as on (even though mpc/madVR usually doesn't listen to Nvidia's instructions for v-sync). Also check your Intel V-sync setting(s). On my system its listed under Intel HD Control Panel -> 3d, and Vertical Sync is set to driver settings (but you can try with application settings selected and see if that makes a difference).

madshi

11th July 2014, 20:24

I think discussion about dansrfe's problem should be moved to another thread - unless there are indications that it's really a madVR specific problem, which currently doesn't seem to be the case, as far as I can see.

This thread should not be used for general PC support problems.

QBhd

11th July 2014, 23:00

AMD Driver update:

With Windows 8.1 and an R9 270X, Catalyst 13.12 is still the best driver to use to get the most out of your GPU.

I again had to roll-back from the latest RC driver since it couldn't handle the profiles I use to maximize performance.

Just an FYI for those interested in trying the latest RC drivers from AMD

QB

innocenat

12th July 2014, 13:59

Hmmmm... Try disabling the options "use a separate device for presentation" and "use a separate device for DXVA processing". Does that help? If not, try reducing the size of the GPU queue and the number of pre-presented frames.

It's already disabled, and GPU queue and pre-presented is at 8 -- should I lower it?

Also I typo'd. I am using madVR 0.87.10

James Freeman

12th July 2014, 17:05

Just to clarify,

Blu-Ray is encoded and stored on the disc as Ycbcr 4:2:0, then madVR converts YCbCr to RGB and does all the processing and output in RGB, correct?
I have read on AVSForums that most TVs convert incoming RGB signal back to YCbCr for processing unless we choose a special option to tell the TV to skip the conversion and output pure RGB.
On a Panasonic this option called "1080 Pixel Direct".

An easy indicator would be if the Color/Saturation slider is still working if we feed RGB signal into the TV, then the TV converts incoming RGB to YCbCr for processing and back again to RGB for the panel.
So basically we get another conversion step which may (or may not) degrade the signal.

What I want to say is:
People who use HDMI to connect madVR to your TV, make sure you use the "PC/RGB/Pixel Direct" mode on the TV for one less conversion step.