madVR - high quality video renderer (GPU assisted)

[tjcinnamon]

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.

I'm upgrading to a 4k TV in the fall and want to use MadVR to upconvert 1080p content.

[nevcairiel]

Originally Posted by madshi

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]

Originally Posted by madshi

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.

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]

Originally Posted by tjcinnamon

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.

Originally Posted by nevcairiel

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.

Originally Posted by dansrfe

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.

Originally Posted by XMonarchY

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.

Originally Posted by madshi

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]

Originally Posted by madshi

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]

@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.

[Shiandow]

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]

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

[Shiandow]

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. 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]

Originally Posted by madshi

@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]

Originally Posted by Asmodian

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]

Originally Posted by Asmodian

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]

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]

Originally Posted by dbezerra

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]

Originally Posted by dansrfe

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/V...eak-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.

Originally Posted by madshi

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/showthre...ll=1#post41448

[dansrfe]

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]

Originally Posted by madshi

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]

Originally Posted by dansrfe

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)

It looks like you're using he internal decoder/splitter.
On different occations in the past I've found subtile behaviour differences using the external versions. i.e. disable ALL the itnernall decoders/splitters etc.
It might be worth a try.