madVR - high quality video renderer (GPU assisted)

[huhn]

Originally Posted by leeperry

That's a bunch of money for a <1K:1 CR IPS panel, OTOH viewing angles are wide and LG TV's usually come with a very impressive ISF certified colorimetry menu

in germany 3d displays with >32< zoll, start at 360 €

you got the philips 450x aktive rest is over 400 euro and samsung no all refresh rate 4:4:4. they most likely share the same panel.

and passive only lg. cheap or no extra glasses needed.

that's a lot of money for a 1080p display and a 3d only for dev.

you are very fast over 500 euro

I started a thread about broken OpenCL on GeForce forums and one person replied that its madVR that is the issue... - https://forums.geforce.com/default/topic/680591/opencl-has-been-broken-since-327-23-drivers-/?offset=3 but as stated earlier - it could be the D3D9 that causes the issue with OpenCL. Is there a way to tell though? Do other OpenCL applications have issues with new drivers?

BTW, I really like the whole "Random Question" thing of these forums, but does it do it for each and every single reply/post?

[cyberbeing]

Originally Posted by madshi

Simple test: Use MS Paint, light gray background. Some diagonal black lines on top. Upscale this with 16 neurons. Ouch.

Not specific enough. Created a 1280x720 light gray image, drew some random black diagonal lines ranging from 1px-5px width on it, but was unable to reproduce.

Could you post a test image?

But aside from artificial test patterns, you said you actually saw this on real videos, right?

Either way, I'm interested in what an artifact with madVR OpenCL NNEDI3 16 neurons looks like, how noticeable it was within the original scene, and how rare the occurrence is.

[iSunrise]

Originally Posted by XMonarchY

I started a thread about broken OpenCL on GeForce forums and one person replied that its madVR that is the issue... - https://forums.geforce.com/default/topic/680591/opencl-has-been-broken-since-327-23-drivers-/?offset=3 but as stated earlier - it could be the D3D9 that causes the issue with OpenCL. Is there a way to tell though? Do other OpenCL applications have issues with new drivers?

BTW, I really like the whole "Random Question" thing of these forums, but does it do it for each and every single reply/post?

I can certainly understand that you absolutely want to fix what is broken at the moment as fast as possible. You´re as frustrated as others by this, but we have to follow a certain way to get this fixed.

And as such, it doesn´t help if you post guesses or false information, as it doesn´t make our lives easier. How many times do we have to tell you that (a) it´s an NV opencl issue, because it doesn´t happen with older builds at all (b) it works with AMD and (c) it doesn´t help anyone if you suddenly post a workaround (that doesn´t even work) several times on different forums, so that NV becomes suspicious.

What´s even worse is that this one user now reports that madVR is the issue, who has no idea whatsoever, because he doesn´t know madshi´s code. Posts like that should be completely ignored or deleted.

So please, the issue itself has been reported to NV and they´re trying to reproduce it now (which is easy). Just give it some time, will you.

Even if you would find a workaround, NV would need to fix it in their drivers, anyway. So why don´t you actually wait a bit, like we all do.

Originally Posted by iSunrise

I can certainly understand that you absolutely want to fix what is broken at the moment as fast as possible. You´re as frustrated as others by this, but we have to follow a certain way to get this fixed.

And as such, it doesn´t help if you post guesses or false information, as it doesn´t make our lives easier. How many times do we have to tell you that (a) it´s an NV opencl issue, because it doesn´t happen with older builds at all (b) it works with AMD and (c) it doesn´t help anyone if you suddenly post a workaround (that doesn´t even work) several times on different forums, so that NV becomes suspicious.

What´s even worse is that this one user now reports that madVR is the issue, who has no idea whatsoever, because he doesn´t know madshi´s code. Posts like that should be completely ignored or deleted.

So please, the issue itself has been reported to NV and they´re trying to reproduce it now (which is easy). Just give it some time, will you.

Even if you would find a workaround, NV would need to fix it in their drivers, anyway. So why don´t you actually wait a bit, like we all do.

I've only provided information that was provided to me. I never said it was accurate. You say they don't know madVR code and they say you don't know nV code. I'm considering all possibilities and seeking information in an attempt to create a workaround for myself and everyone else who wants to use their GPUs for madVR OpenCL along with the latest fixes and improvements in video games.

Thanks for a warm reply - I'll make sure not to post a fix if I find one. Its better to do it the right way - wait 6 more driver releases before nVidia fixes this issue and creates another one.

[pirlouy]

No need for quoting all post when just posting after...

The most regrettable thing is to give credits to a random guy who obviously is not a developer.

Originally Posted by XMonarchY

and one person replied that its madVR that is the issue...

[iSunrise]

Originally Posted by XMonarchY

You say they don't know madVR code and they say you don't know nV code.

I meant the one guy that posted a reply to your post. NV knows about all of this already (we gave them the details that were provided by madshi himself) and they will come back to us (people that are in the Beta program, actually) if they have reproduced it themselves. They don´t need the code from madshi anyway, because they can track the error without any problem. And even if they need more info, we will know soon. That one guy that posted the replay though, can do neither of that. So it´s better to ignore him.

Originally Posted by XMonarchY

Thanks for a warm reply - I'll make sure not to post a fix if I find one. Its better to do it the right way - wait 6 more driver releases before nVidia fixes this issue and creates another one.

Unfortunately, that´s exactly what needs to happen. Wouldn´t matter if I post it any other way. I just want to make sure that an official fix doesn´t get delayed any further. And that benefits us all.

[5ts]

Thanks Madshi for your excellent work. Is it possible to have a direct source mode feature added to madvr for those with external video processors that would disable all video processing features such as chroma upsampling, scaling and color conversion etc in madvr to effectively send the video signal untouched to the external video processor to do the heavy lifting. This would be an awesome feature if it could be incorporated into this fantastic renderer.

[DarkSpace]

Originally Posted by 5ts

Thanks Madshi for your excellent work. Is it possible to have a direct source mode feature added to madvr for those with external video processors that would disable all video processing features such as chroma upsampling, scaling and color conversion etc in madvr to effectively send the video signal untouched to the external video processor to do the heavy lifting. This would be an awesome feature if it could be incorporated into this fantastic renderer.

Uhm, what?

So, you want a video renderer (madVR in this case) that forwards all the video renderer work to something else (your "external video processor") so that this something else can do the work the video renderer is supposed to do?
A possibly quite stupid question, but why?
Can't you just use the "external video processor" as video renderer instead, then?

[cyberbeing]

Would it be possible to have madVR's traditional scaling algorithms correct any NNEDI3 pixel shift when they perform additional upscaling/downscaling afterwords?

[madshi]

Originally Posted by omarank

Ok, I have removed the profile and switched to "only if there would be judder..." Now SM gets enabled for 29.97 fps interlaced videos (video mode) and 30 fps progressive videos (from Kodak digicam). It remains disabled however for 29.97 fps progressive videos. IIRC, SM switching was working fine in v0.86.11.

@Madshi, Turbojet: Can you check for 29.97 fps interlaced videos?

I think the issue you're seeing has nothing to do with the new profiling functionality, and I would guess it also occurs with v0.86.11. I think your movie framerate and your display refresh rate are simply so far away that madVR believes SM is needed. Look at the OSD (Ctrl+J) and check if refresh rate and movie framerate are really (more or less) identical. They're probably not. If you still think this is a new bug caused by profiles, then please downdate to v0.86.11 and double check that the problem *really* didn't occur with v0.86.11 because right now I think you'd get the same with v0.86.11.

Originally Posted by XMonarchY

I started a thread about broken OpenCL on GeForce forums and one person replied that its madVR that is the issue...

Probably a madVR hater posting that without having a clue. Just ignore him.

Originally Posted by cyberbeing

Could you post a test image?

But aside from artificial test patterns, you said you actually saw this on real videos, right?

When talking about image scaling I like to test with specific images which are known to showcase strengths and weaknesses of scaling algorithms. E.g. try this image:

http://madshi.net/clownOrg.png

Look at the white cars. With 16 neurons there's still some aliasing left in there. The improvement from 16 to 32 neurons is larger there than when going from 32 to 64 neurons. But as I said earlier, it depends. Sometimes the step from X to Y neurons looks bigger than the step from Y to Z neurons. And sometimes it's the other way round. It differs depending on the test image. But I've seen several instances like this "clown" image where 16 neurons still left some aliasing in the image which 32 neurons mostly took care of.

But in the end all I can give is my thoughts. And in terms of image quality analysis I don't claim to be the final judge. You're free to disagree with me and post different recommendations.

Originally Posted by 5ts

Thanks Madshi for your excellent work. Is it possible to have a direct source mode feature added to madvr for those with external video processors that would disable all video processing features such as chroma upsampling, scaling and color conversion etc in madvr to effectively send the video signal untouched to the external video processor to do the heavy lifting. This would be an awesome feature if it could be incorporated into this fantastic renderer.

That's technically not possible for 2 reasons:

(1) The GPUs in HTPCs are used to output RGB. You can switch them to YCbCr, but all that results in is that they take the Windows RGB desktop and convert it to YCbCr in the GPU drivers and then output that via HDMI. Which makes no sense since that means *more* processing than outputting RGB directly. It is very hard (with some GPUs and OSs even impossible) for madVR to output YCbCr data in such a way that the GPU and OS don't further manipulate it. So you have to live with RGB output. And once you accept that RGB output is the best option for HTPCs, you automatically have to live with all that's necessary for good quality RGB output, which is at least chroma upscaling, color conversion and then conversion to the final RGB output bitdepth.

(2) Even if it were possible for madVR to tell the GPU/OS to output some specific YCbCr data untouched, there's still the problem that HDMI up until 1.4 does not support 4:2:0 transport. Which means that every source device (including external Blu-Ray players etc) has to take the decoded video and at least partially upscale chroma to 4:2:2. So untouched output is technically possible. Ok, HDMI 2.0 finally introduced 4:2:0 support, so there's that. But no GPUs I know actually have HDMI 2.0 ports yet. And even if they had, we're back at problem (1).

But I think you really don't need to worry: I believe that madVR has better chroma upscaling, color conversion and scaling algorithms than any external video processor out there today. E.g. users with Lumagen processors have personally told me that they prefer madVR's Jinc3 AR over Lumagen's scaling. The one thing external video processors might do better today is that they might offer more reliable/easy to use deinterlacing. That is an area I find lacking myself in HTPCs, currently.

[5ts]

Originally Posted by DarkSpace

Uhm, what?

So, you want a video renderer (madVR in this case) that forwards all the video renderer work to something else (your "external video processor") so that this something else can do the work the video renderer is supposed to do?
A possibly quite stupid question, but why?
Can't you just use the "external video processor" as video renderer instead, then?

Let me clarify further. By external video processor I am referring to video processors from the likes of Lumagen and DVDO which is a hardware device. I am seeking a feature to emulate a configuration where blu ray players from the likes of Oppo for e.g. offer a direct source mode that bypass the blu ray player's internal video processing capabilities and send these to the external video processor (Lumagen, DVDO) for processing which is superior. All I am requesting is for madvr to emulate such a feature for those who have the benefit of external video processors. It is always wise to seek clarification first instead of passing judgement on the intelligence of one's question.

[madshi]

Originally Posted by cyberbeing

Would it be possible to have madVR's traditional scaling algorithms correct any NNEDI3 pixel shift when they perform additional upscaling/downscaling afterwords?

Hmmmm... That should be technically possible. I'm already doing exactly that to match the separately upscaled chroma channels to the NNEDI3 scaled luma channel. Sounds like a good idea to me, although it would further complicate my code (depending on scaling factor I'd have to sometimes correct the position of the chroma channels and sometimes the position of the luma channels, and sometimes both and sometimes none, ouch). Please add this as a "bug" to the tracker. I don't want to spend time on that atm, but I consider it a good idea, so I don't want to lose sight of that.

[DarkSpace]

Originally Posted by 5ts

It is always wise to seek clarification first instead of passing judgement on the intelligence of one's question.

Which is precisely why I wrote down what I understood your feature request was, and then offered an alternative to what I understood your request was, all without hostility. That was intended to give you an alternative to something I think makes little sense should my understanding be correct, and should my understanding be incorrect, it was intended to give you an opportunity to correct specifically the point where I misunderstood (here: the "external" part of the video processor).
I obviously did simply misunderstand your request, but even so, I am sorry that you perceived it as hostile. Let me assure you, there was no hostility on my end.

Finally, I did not question your intelligence. You may notice that I specifically did not include anything regarding that except for the simple question of why you would want that (saying that I don't see the reason, and not saying that there is none). In this case, the inability to see the reason behind your request originated from my misunderstanding of the request itself.

[Mano]

is it normal for mpc to use 1.5gb ram then another 500mb in exclusive mode playing a 322mb mkv anime?

[ryrynz]

Only if you have Avisynth or something similar running.

[sandman7920]

Which decode method produce better quality for image up scaling DXVA or Software?

Sent from my HTC One using Tapatalk

[DarkSpace]

Originally Posted by 5ts

By external video processor I am referring to video processors from the likes of Lumagen and DVDO which is a hardware device. I am seeking a feature to emulate a configuration where blu ray players from the likes of Oppo for e.g. offer a direct source mode that bypass the blu ray player's internal video processing capabilities and send these to the external video processor (Lumagen, DVDO) for processing which is superior.

I have done a bit of thinking, and have reached the conclusion that what you intend may indeed be possible, depending on how those hardware devices work (and how configurable they are):

• If you create a file with the filename "YCbCr" (no extension, and the file itself may be empty) in the directory madVR resides in, madVR will not convert the data to RGB before presenting it. The image will be YUV, but still be treated (and flagged) as RGB by the GPU. Therefore, you will output YUV, but the GPU will signal that it's outputting RGB. If you can configure your device to treat the input as YUV regardless of what the signal thinks it is, you can let it perform the conversion to RGB instead.
• In any case, however, madVR will upsample the Chroma channels. If you select Nearest Neighbor as Chroma upsampling algorithm, the pixels will be literally doubled for 4:2:0 content. If you can tell your device to only take one pixel of every 2x2 block and upsample the Chroma from that, you can also forward that task to the device.
• Make sure you output the video at its original resolution, of course. Otherwise, make sure your device knows the video's original resolution and instruct it to invert Nearest Neighbor scaling from the device's input resolution to the original video resolution before doing the Chroma upsampling step. Of course, also make sure you have Nearest Neighbor selected as Image Upscaling algorithm. This may or may not work, but in my opinion (does anyone know something better?) it is your best chance of getting stuff right.
• I am not sure about deinterlacing. If you can manually tell your device when to treat the input as interlaced, set your GPU to deinterlace using Weave (this will result in not deinterlacing at all, and instead treating the image as progressive), and set madVR to video mode deinterlacing. Also check the halfrate deinterlacing option in madVR's Trade quality for performance section: If you weave the image back together, doublerate deinterlacing will probably give you the same image twice in a row (I never tried this myself).
• Disable all settings in the Artifacts removal tab of Processing.
• You probably also want to disable SmoothMotion framerate conversion.
• Since I will be assuming that your input is DVD or BluRay content, or otherwise native 8-bit content, disable dithering completely: You only use Nearest Neighbor scaling, which does not increase the image bitdepth, so you can safely round down or truncate back to 8 bit. You can find the setting in the Trade quality for performance section.

I hope I didn't forget anything!

[cyberbeing]

Originally Posted by madshi

But I've seen several instances like this "clown" image where 16 neurons still left some aliasing in the image which 32 neurons mostly took care of.

So the artifacts you speak of are only 'aliasing' or can it produce other strange artifacts as well?

The clown image change from 16 neurons to 32 still seems very minor. And it actually appears that 32 has more artifacts than 16 does in that image when compared against 64. 64 seems like a sharper version of 16 with similar sub-pixel structure, while 32 seems to have a very *different* sub-pixel structure with bad guesses which are reverted by 64 & 128. 256 on the other hand seems too strong to the point it starts enhancing minor source artifacts in a couple places.

The reliable improvement sweet spot for NNEDI3 appears to be 64-128 neurons, with 16 neurons as nice low-cost speed option. I'll continue to do more testing, but 32 neurons seems rather inconsistent compared to the others. It almost makes me think there is a math error or something with 32 neurons, but maybe this is just how NNEDI3 behaves normally...

Originally Posted by madshi

Hmmmm... That should be technically possible. I'm already doing exactly that to match the separately upscaled chroma channels to the NNEDI3 scaled luma channel. Sounds like a good idea to me, although it would further complicate my code (depending on scaling factor I'd have to sometimes correct the position of the chroma channels and sometimes the position of the luma channels, and sometimes both and sometimes none, ouch). Please add this as a "bug" to the tracker. I don't want to spend time on that atm, but I consider it a good idea, so I don't want to lose sight of that.

I think it would be worthwhile, especially when you consider the sub-pixel positioned subtitle typesetting madVR receives. Screenshot comparisons against the quality of traditional resamplers would also be more practical.

[madshi]

Originally Posted by cyberbeing

So the artifacts you speak of are only 'aliasing' or can it produce other strange artifacts as well?

The clown image change from 16 neurons to 32 still seems very minor. And it actually appears that 32 has more artifacts than 16 does in that image when compared against 64. 64 seems like a sharper version of 16 with similar sub-pixel structure, while 32 seems to have a very *different* sub-pixel structure with bad guesses which are reverted by 64 & 128. 256 on the other hand seems too strong to the point it starts enhancing minor source artifacts in a couple places.

The reliable improvement sweet spot for NNEDI3 appears to be 64-128 neurons, with 16 neurons as nice low-cost speed option. I'll continue to do more testing, but 32 neurons seems rather inconsistent compared to the others. It almost makes me think there is a math error or something with 32 neurons, but maybe this is just how NNEDI3 behaves normally...

I don't really have the time to micro-analyze this with large numbers of test images and videos atm. With the clown image I clearly prefer 32 neurons over 16 neurons. You seem to disagree, that's fine. I can only post my personal subjective impressions. And my impressions are that more neurons usually helps, and I've seen a reduction in aliasing when going from 16 to 32 neurons with one or the other test images. That's why I personally suggest to use at least 32 neurons (or more). But what I suggest is not the law, and I'm fine if people have different opinions.

I'll happily admit that different neuron settings sometimes give a little bit different results, and sometimes one neuron setting can look better than another, and it's not *always* the higher neuron setting that wins. But usually it is. And if you compare 16 neurons to 256 neurons, the difference can sometimes be quite noticeable (in favor of 256 neurons), while comparing "neighbor" neuron settings often only shows small improvements.

I think that's the last I want to say about neurons for now.