LAV CUVID Decoder - High Quality Hardware decoding for NVIDIA

[nevcairiel]

I don't really see how LAV CUVID can affect the output range. I mean, @nevcairiel, you're simply transporting the NV12 data back from the GPU to System RAM, without modifying anything, right?
Right, not doing anything to the data, except pressing it into a DirectShow form.

He says his graphics output itself changes to full RGB, as evidenced by his desktop changing, so its definitely not anything i do.

[jazzysmooth]

Just to follow up, LAV CUVID loads and works fine on my 8600 GT in another system. @Nev, does the decoder perform some sort of lookup to determine that a valid Nvidia chipset is in place? Has anyone else successfully used this with a onboard NVidia GPU? Just wondering if the onboards do something differently that perhaps isn't being picked up by the decoder.

I know I'm reaching, just don't want to perform a clean install on the HTPC (ZOTAC GF9300-G-E LGA 775 NVIDIA GeForce 9300 ) without knowing its going to make a difference.

[e-t172]

@e-t172, are you using madVR's automatic display modes changer? Is it possible that when using LAV CUVID you're getting 1080p60 and thus madVR switches to 1080p60? And when using ffdshow, maybe you're using a different mode? Normally the standard NVidia TV modes all compress to 16-235, while all "custom resolutions" stay at 0-255. So my best guess is that when you get 0-255, you're running a custom resolution.

No. I mean, I looked at it every way I could, and the conclusions are clear:

If LAV CUVID starts decoding a 1080p video, then the output immediately switches to FULL RGB mode, and stays that way until the filter is closed.

And I mean it. Even with this:

http://uppix.net/7/1/c/e2e58a222a02fdbced9b1fe58bc26.png (http://uppix.net/7/1/c/e2e58a222a02fdbced9b1fe58bc26.html)

Even with this graph, as soon as I click play (in GraphStudio), the entire display switches to FULL RGB. If I remove the filter, the display switches back to limited mode. It is absolutely certain LAV CUVID is causing this (meaning, CUVID is causing this).

If I play a 720p file using the very same graph, nothing happens.

From what I'm seeing, I'm convinced that when CUVID is used with 1080p video, the driver is "trying to be smart" and will "optimize" the output level. I'm guessing this is aimed at software Blu-ray players. Too bad it doesn't apply to non-1080p content...

@nevcairiel: thanks for your answer. I understand that this isn't under your control, but I was wondering, maybe you could come up with a workaround? For example, when playing non-1080p content, open a second, bogus CUVID "decoding session" (or whatever it is called) with 1080p parameters, without using it, just to trick the driver into thinking 1080p content is being played? This "second session" would just stand there doing nothing and the first session would decode the actual content. Is this even possible? Of course I'm thinking about something which could be enabled/disabled using a checkbox "Trick CUVID into thinking it is decoding 1080p content".

[madshi]

@e-t172, why don't you simply create custom resolutions for all needed display modes and refresh rates? That would nicely take care of the problem, as long as you can switch or calibrator your display into working with 0-255 content correctly.

[ianken]

@e-t172: glad to see I'm not the only one fighting with nvidia HDMI shenanigans.:)

As is you get two color-space conversions if your display is calibrated to TV levels. Since photos and what not don't matter for me I want full RGB output without scaling to 16-235 for the desktop or anything else.

[madshi]

As is you get two color-space conversions if your display is calibrated to TV levels. Since photos and what not don't matter for me I want full RGB output without scaling to 16-235 for the desktop or anything else.
If you output the desktop in 16-235 you are likely to get banding problems. Windows always renders the desktop in 0-255. If the GPU condenses that to 16-235 you're practically losing a few steps of information. Same applies to games and photos.

[e-t172]

@e-t172, why don't you simply create custom resolutions for all needed display modes and refresh rates? That would nicely take care of the problem, as long as you can switch or calibrator your display into working with 0-255 content correctly.

Could you elaborate? Sure I could create custom resolutions for 24p and 25p (assuming they would take precedence over the predefined 24Hz/50Hz refresh rates… would they?), but what about NTSC content? If I use a custom resolution for 60Hz, then the levels for Windows applications will be wrong… Or maybe I can do something more clever, like defining a 59Hz custom resolution while leaving 60Hz untouched? This way I'll be using 60Hz for the desktop and 59Hz for video?

Having the video player switch output levels makes much more sense to me, IMO. When not playing video, you get limited RGB ; when playing video, you get full RGB. Makes perfect sense! Probably NVidia thought the same, too; too bad they only implemented the idea for 1080p content… That's why I would love to see this fixed in LAV CUVID, as it would make the whole video levels management issue nicely disappear! I would even try to hack it in the LAV CUVID source code myself, if I had access to it…

If you output the desktop in 16-235 you are likely to get banding problems.

Well, I don't have much of a choice, do I? If I want correct levels for photos on a HDTV then I need to compress them to 16-235. Sure there will be banding, but it's much preferable to having horrible black/white levels. BTW, are you sure video cards aren't dithering to avoid this issue?

I'm also investigating solutions involving switching ICC profiles automatically. So I could use a ICC profile to compress the desktop to 16-235, and switch to another ICC profile when playing video. This way I'll be "emulating" the limited range feature of the NVidia card using ICC profiles. Then again, this seems complicated and ugly compared to switching levels automagically in the video player. I suppose the video card doesn't dither when applying ICC profiles, does it?

[CruNcher]

Does for someone else MPC-HC crashes (msvcrt.dll) when ffdshows raw decoding is active in its chain with LAV CUVID,CoreAVC CUDA under Winxp SP3 ?

http://img703.imageshack.us/img703/9963/mpccrashxpsp3.png


oha

VMR7 windowed = crash
VMR9 windowed = crash
Overlay Mixer = crash
VMR9 renderless = crash
VMR7 renderless = crash
Haalis Renderer = OK
MadVR = doesn't crash strange gray-scale halved colored (green) output playback result though

PS: The crash VMR7/9 Overlay only happens with ffdshow colorspace NV12 (YUY2,RGB32 are fine)

Lav Cuvid + ffdshow + Madvr (YV12(NV12)->NV12->NV12)

http://imageshack.us/m/220/6730/mpchcmadvrffdshowlavcuv.png

also seeing this 1920 to 2048x looks strange


Lav Cuvid + ffdshow + Haali (YV12(NV12)->NV12(RGB32)->RGB32) (forcing YUY2 also works with Haali)

http://imageshack.us/m/857/5816/mpchchaaliffdshowlavcuv.png


Interoperability problem (rounding differences) between Decoder (NV12)->ffdshow (NV12)->Renderer (NV12) ?
maybe a compile bug i gonna try different ffdshow builds, for now i would say the issue is ffdshows NV12 very clearly

Ok i take that clearly back (now its unsure where this crash is originating from, though it seems it has todo with NV12 going through without being converted the problem only appears in a straight colorspace untempered data chain beginning from the decoder (LAV CUVID,CoreAVC CUDA))

Cyberlink ->ffdshow->VMR9 Renderless (YUY2->YUY2(NV12)->NV12)

http://imageshack.us/m/51/2002/cyberlinknv12ffdshowok.png

Cyberlink ->ffdshow->MadVR (YUY2->YUY2(NV12)->NV12)

http://imageshack.us/m/52/135/cyberlinknv12ffdshowokm.png

Final result to prove this bug thesis of the NV12 chain :)

Lav Cuvid + ffdshow + VMR9 Renderless (YV12(NV12)->NV12(RGB32)->RGB32) No crash

http://imageshack.us/m/812/9825/lavcuvidffdshowrgb32vmr.png

Possible Bug vectors (10% Lav Cuvid,CoreAVC CUDA,10% Nvidia Driver,80% ffdshow)

[madshi]

@e-t172, can you switch your display between 0-255 and 16-235? If not, can you adjust brightness and contrast so that 0-255 has correct black and white levels?

And yes, I'm pretty sure that the video cards don't do dithering when stretching 0-255 to 16-235. At least mine don't (ATI + NVidia).

[e-t172]

@e-t172, can you switch your display between 0-255 and 16-235?

Aside from the registry hack to put everything to 0-255 (which I haven't actually tried), no.

If not, can you adjust brightness and contrast so that 0-255 has correct black and white levels?

Not sure what you mean by that (which settings? on the display itself? on the driver?). I don't think this will solve anything: no matter what settings I set, there's no way they will be correct for all three situations (Windows desktop, 1080p video with LAV CUVID, 720p video with LAV CUVID). Besides, modifying brightness/contrast settings leaves an opportunity for banding just like levels conversion.

[madshi]

Aside from the registry hack to put everything to 0-255 (which I haven't actually tried), no.

Not sure what you mean by that (which settings? on the display itself? on the driver?).
I'm talking about your DISPLAY (computer monitor, projector, plasma, whatever). Can you switch your DISPLAY between 0-255 and 16-235? If not, can you adjust brightness and contrast on your DISPLAY so that a PC sending 0-255 content is shown with correct black and white levels on your display? I'm talking about DISPLAY controls, only, not about any settings on PC. If you don't answer these questions then I can not help you.

[e-t172]

Yes, I can switch the display between 16-235 and 0-255 (it's a Sony KDL-46W4000 HDTV). But I won't, because there are other sources connected to this HDTV (most notably a TV box) which will only output 16-235. Besides, this would mean doing a video levels conversion inside the HDTV instead of inside the video card. I'm not sure that's better, and I still don't understand how that would help me get consistent black/white levels.

Let me summarize:
- I won't change my HDTV's settings because the HTPC is not the only source connected to it
- I won't switch my Windows desktop to 0-255 because it's not only used for video
- I want to prevent banding in videos, and preserve BTB/WTW - which means the decoded frames must be sent to the HDTV untouched, without any levels conversion
- I want everything to be consistent between 1080p and non-1080p content

The behavior of CUVID on my system regarding video levels is strange, but in a positive way, because it puts me closer to my goal. Unfortunately, it only switches to full RGB for 1080p content, which is incompatible with the last point.

I asked nevcairiel if it is possible to implement a workaround for this, or if I can try implementing it myself. If the workaround works, then I get the perfect system: correct video levels for all Windows applications, and maximum quality for video content which stays untouched and sent as-is to the HDTV, as it should be.

I'm sorry if I'm not making myself clear - please bear in mind that English is not my native language.

[madshi]

Yes, I can switch the display between 16-235 and 0-255 (it's a Sony KDL-46W4000 HDTV). But I won't, because there are other sources connected to this HDTV (most notably a TV box) which will only output 16-235.
Usually settings like this are per input port. Are the other sources connected through the same HDMI port?

[e-t172]

Yes, everything is connected to a Marantz SR5003 receiver which is itself connected to the HDTV. The receiver doesn't allow me to switch levels per input port. So that's a dead end.

I still don't understand why you seem to think that switching to 0-255 mode in the HDTV would make any difference to my situation. It would just be choosing between two equal evils, moving the destructive process from the HTPC to the HDTV.

[madshi]

So that's a dead end.
Yes, unfortunately.

It would just be choosing between two equal evils, moving the destructive process from the HTPC to the HDTV.
No, but anyway, dead end, so no use discussing it.

[ryrynz]

Yes, I can switch the display between 16-235 and 0-255 (it's a Sony KDL-46W4000 HDTV). But I won't, because there are other sources connected to this HDTV (most notably a TV box) which will only output 16-235.

When you change the black levels on a TV it's only for the currently selected input, so you can have one source at 16-235 and another at 0-255.

[nevcairiel]

As he said, the TV only has one source. The devices are connected to his receiver.

[ryrynz]

Figured the best solution be to connect one of his other devices directly to the TV and change the black level, but oh well.

[nevcairiel]

And not use the speakers connected to the receiver? :p

[ryrynz]

:) S/PDIF or Coax in perhaps?

[Carpo]

:) S/PDIF or Coax in perhaps?

depends on the distance, for short distance coax is a good idea, for longer runs spdif is better

[Weirdo]

Is it possible (or maybe in a future version) to alter brightness/contrast/saturation through the decoder, like CoreAVC for example? I tried through Nvidia's control panel settings, but they have no effect (CUVID/madVR combination).

[madshi]

Changing brightness/contrast/saturation is a task for the video renderer, not for the decoder. madVR will allow such changes in a future version.

[andyvt]

Yes, everything is connected to a Marantz SR5003 receiver which is itself connected to the HDTV. The receiver doesn't allow me to switch levels per input port. So that's a dead end.


You could put an HDMI splitter b/w the AVR and the TV.

[e-t172]

I must admit, I really don't understand why everyone is giving me hardware-related advice for a purely software issue. Whey I say "A isn't doing its job properly", everyone is telling me to work around it by altering some connected device B, without even mentioning A. I'm a little confused here.

When you have a compatibility issue such as this, the first thing you do is try to fix the root cause (in my case, the HTPC). So, first of all, I'm trying to make the HTPC comply with consumer video standards (that is, 16-235, BTB/WTW preservation, etc.). That's why I'm asking nevcairiel for a workaround. If this isn't possible, then I guess I'll take a trip to ICC profiles land. And if that doesn't work, THEN, and only THEN, I will consider working around the issue outside the HTPC.

When I'm trying to solve a problem, I usually consider solutions in order, ranging from "clean fix" to "ugly hack". Here, the clean fix is getting NVidia to fix CUVID and having the video renderer switch levels automagically, but we all know this isn't gonna happen soon. The other solutions are all workarounds. A local workaround, closer to the root cause, is always better, because there will be less side effects and less incompatibilities. Here, a workaround in LAV CUVID is best (local to the video player). Then comes a workaround based on clever ICC profiles (local to the HTPC). Then, and only then, come workarounds in the rest of the chain, which are in the "ugly hack" end of the spectrum.

Also, solutions which cost me money (like andyvt's) will obviously always come last.

[ranpha]

When I'm trying to solve a problem, I usually consider solutions in order, ranging from "clean fix" to "ugly hack". Here, the clean fix is getting NVidia to fix CUVID and having the video renderer switch levels automagically, but we all know this isn't gonna happen soon. The other solutions are all workarounds. A local workaround, closer to the root cause, is always better, because there will be less side effects and less incompatibilities. Here, a workaround in LAV CUVID is best (local to the video player). Then comes a workaround based on clever ICC profiles (local to the HTPC). Then, and only then, come workarounds in the rest of the chain, which are in the "ugly hack" end of the spectrum.


Let me tell you, you don't want this to happen. This shenanigan is what ATI used to pull in the past with their drivers, and it wasn't pretty.

Have you already set up your device drivers to pass video data over HDMI using YCbCr instead of RGB?

[e-t172]

Let me tell you, you don't want this to happen. This shenanigan is what ATI used to pull in the past with their drivers, and it wasn't pretty.

Well, in a perfect world, NVidia and ATI would expose a well-defined and documented API for switching output levels. Then video renderers like madVR would just use the API to set whatever levels are appropriate. But I'm dreaming out loud here. It's not like NVidia/ATI are actually listening to their consumers.

Although with NVidia there's a way to "emulate" this hypothetical API: just open a dummy CUDA video decoder with 1080p frame parameters and it'll instantly switch the HDMI output to full RGB!

Have you already set up your device drivers to pass video data over HDMI using YCbCr instead of RGB?

Haven't tried it, I will. Unfortunately I won't have access to the system until May 27th, so I'll get back to you on this one. However, won't this result in quality degradation due to the multiple colorspace conversions (RGB -> YCbCR -> RGB)?

[madshi]

I must admit, I really don't understand why everyone is giving me hardware-related advice for a purely software issue.
Most of us here aim for perfection. We're trying to optimize your hardware setup because that's the best way to get max quality from all aspects of your HTPC, including video playback, games, photos and the Windows desktop / applications. If you can't optimize the hardware the way we're suggesting, you have to live with compromises. IMHO your hardware setup is fundamentally flawed, because a PC has historically always been outputting 0-255 and you simply can't get perfect image quality if you let the GPU stretch that to 16-235 behind the back of the photo application, the games, the video renderer and Windows itself. Of course that's only my personal opinion. Maybe the latest hardware and drivers from ATI/NVidia now suddenly do the stretching in perfect quality, making me eat my hat. I don't think so, unfortunately.

If you do have to live with compromises then I can't help you because that's not an area I have much knowledge in... :p

[andyvt]

I must admit, I really don't understand why everyone is giving me hardware-related advice for a purely software issue. Whey I say "A isn't doing its job properly", everyone is telling me to work around it by altering some connected device B, without even mentioning A. I'm a little confused here.

When you have a compatibility issue such as this, the first thing you do is try to fix the root cause (in my case, the HTPC). So, first of all, I'm trying to make the HTPC comply with consumer video standards (that is, 16-235, BTB/WTW preservation, etc.). That's why I'm asking nevcairiel for a workaround. If this isn't possible, then I guess I'll take a trip to ICC profiles land. And if that doesn't work, THEN, and only THEN, I will consider working around the issue outside the HTPC.

When I'm trying to solve a problem, I usually consider solutions in order, ranging from "clean fix" to "ugly hack". Here, the clean fix is getting NVidia to fix CUVID and having the video renderer switch levels automagically, but we all know this isn't gonna happen soon. The other solutions are all workarounds. A local workaround, closer to the root cause, is always better, because there will be less side effects and less incompatibilities. Here, a workaround in LAV CUVID is best (local to the video player). Then comes a workaround based on clever ICC profiles (local to the HTPC). Then, and only then, come workarounds in the rest of the chain, which are in the "ugly hack" end of the spectrum.


Given the choice b/w countless hours chasing a fix or implementing a relatively cheap workaround (the HDMI splitter I used for testing cost $40), even if temporary, when the end result is roughly equivalent and you net the saved time/frustration ...


Also, solutions which cost me money (like andyvt's) will obviously always come last.

To be fair, you said it was a "dead end" I was pointing out that it was not. Implementing it, is of course up to you. Also, using a splitter b/w the AVR and TV is a common technique for dealing with devices that require specific calibration; not just in the HTPC space. In this case, even if the root cause was identified and addressed at a "palatable" layer in the chain, you may want to use this approach to get the best (http://www.avsforum.com/avs-vb/showthread.php?p=20347814#post20347814) output available.

[madshi]

Well, in a perfect world, NVidia and ATI would expose a well-defined and documented API for switching output levels. Then video renderers like madVR would just use the API to set whatever levels are appropriate. But I'm dreaming out loud here. It's not like NVidia/ATI are actually listening to their consumers.
100% agreed.

The funny thing is, both ATI and NVidia publically offer SDKs which do these kinds of things. Unfortunately NVidia is missing a "set output levels" API. ATI offers such an API, but it doesn't work reliably, unfortunately.

[madshi]

Given the choice b/w countless hours chasing a fix or implementing a relatively cheap workaround (the HDMI splitter I used for testing cost $40), even if temporary, when the end result is roughly equivalent and you net the saved time/frustration ...
Actually, the end result would be even better because with your suggestion (if it works as expected) e-t172 would get banding free quality with photos, games and Windows desktop/applications, too.

[ranpha]

Haven't tried it, I will. Unfortunately I won't have access to the system until May 27th, so I'll get back to you on this one. However, won't this result in quality degradation due to the multiple colorspace conversions (RGB -> YCbCR -> RGB)?

If you use madVR, you don't have to worry about this. That could be good for you, or bad. madVR is after all the equivalent version of WASAPI exclusive mode for video.

[madshi]

If you use madVR, you don't have to worry about this. That could be good for you, or bad. madVR is after all the equivalent version of WASAPI exclusive mode for video.
Well, if you ask your GPU to output YCbCr then your GPU drivers convert madVR's rendering output (which is always RGB) to YCbCr. There's no guarantee that the GPU drivers are doing that correctly. There's even a relatively high danger that the GPU drivers are converting madVR's 8bit RGB output to 8bit YCbCr, without using dithering, which would again eventually add some banding, because the RGB -> YCbCr conversion results in floating point numbers. Rounding them down to 8bit is no good.

[e-t172]

Most of us here aim for perfection.

Oh, me too, actually. The difference is, I have constraints I have to live with. Actually the system we're talking about is not mine, so the aforementioned constraints come from the actual owner/user of the system. I just don't have a choice here.

We're trying to optimize your hardware setup because that's the best way to get max quality from all aspects of your HTPC, including video playback, games, photos and the Windows desktop / applications. If you can't optimize the hardware the way we're suggesting, you have to live with compromises. IMHO your hardware setup is fundamentally flawed, because a PC has historically always been outputting 0-255 and you simply can't get perfect image quality if you let the GPU stretch that to 16-235 behind the back of the photo application, the games, the video renderer and Windows itself.

Well, to be fair, I don't really mind having suboptimal quality for Windows applications. The HTPC is primarily used for video, not for photos. So I only want perfect image quality for video. The workaround I'm proposing would allow me to achieve exactly that: switch to full RGB only when video is playing, so that the frames go untouched from madVR to the HDTV with no conversion whatsoever and pristine quality.

You proposed working in the 0-255 range at the display level. If I'm understanding your posts correctly (especially #582 (http://forum.doom9.org/showthread.php?p=1501457#post1501457)), you claim this would allow me to get perfect quality for Windows applications AND video. I just don't see how is that possible. Working in 0-255 means that I'll have to convert video from 16-235 to 0-255. IMO, there are two issues with this: first I'm losing BTB/WTW information, and second there is a very good chance that the HDTV is not optimized for 0-255 input and will convert to 16-235 internally with a crappy conversion.

Well, if you ask your GPU to output YCbCr then your GPU drivers convert madVR's rendering output (which is always RGB) to YCbCr. There's no guarantee that the GPU drivers are doing that correctly. There's even a relatively high danger that the GPU drivers are converting madVR's 8bit RGB output to 8bit YCbCr, without using dithering, which would again eventually add some banding, because the RGB -> YCbCr conversion results in floating point numbers. Rounding them down to 8bit is no good.

That's exactly what I was worried about :(

[madshi]

Well, to be fair, I don't really mind having suboptimal quality for Windows applications. The HTPC is primarily used for video, not for photos. So I only want perfect image quality for video. The workaround I'm proposing would allow me to achieve exactly that: switch to full RGB only when video is playing, so that the frames go untouched from madVR to the HDTV with no conversion whatsoever and pristine quality.
Ok.

The problem with your proposed workaround is that you wouldn't need it if you created custom resolutions to force NVidia to output 0-255 all the time. Which is a solution many people are using. So your proposed workaround is probably only for a minority of users, and it's not guaranteed that it will work, and if it works it might only work with some NVidia cards, some OSs and some driver versions. Furthermore it would cost several hours of programming time. So that are all very good reasons against implementing your workaround. Besides, it's extremely ugly, too... :p

You proposed working in the 0-255 range at the display level. If I'm understanding your posts correctly (especially #582 (http://forum.doom9.org/showthread.php?p=1501457#post1501457)), you claim this would allow me to get perfect quality for Windows applications AND video. I just don't see how is that possible. Working in 0-255 means that I'll have to convert video from 16-235 to 0-255. IMO, there are two issues with this: first I'm losing BTB/WTW information, and second there is a very good chance that the HDTV is not optimized for 0-255 input and will convert to 16-235 internally with a crappy conversion.
The HDTV also has to support brightness and contrast adjustments (which every TV has built in) without introducing banding. So it's likely that it can do such adjustments without introducing banding. Switching from 16-235 to 0-255 is not much different from changing brightness + contrast. Of course the only way to be sure is to test it. But from my (limited) experience, most displays handle a 0-255 <-> 16-235 switch just fine, without introducing banding.

[andyvt]

I'm losing BTB/WTW information

BTB/WTW should only exist in calibration material. That said, there is some evidence that WTW does exist in real content but clipping won't have a large (http://www.upsilonsoftware.com/blog/5-blog/15-where-were-at-with-wtw.html) impact.

[madshi]

BTB/WTW should only exist in calibration material. That said, there is some evidence that WTW does exist in real content but clipping won't have a large (http://www.upsilonsoftware.com/blog/5-blog/15-where-were-at-with-wtw.html) impact.
True. Furthermore that AVSForum thread discussing whether WTW content exists came to no clear conclusions. A lot of WTW pixels appear to come from scaling artifacts (ringing) or chroma upsampling effects. Anyway, a future madVR version might offer an option to keep some parts of the WTW range, when using 0-255.

[e-t172]

Thanks for the heads up. I read that AVSForum thread long ago, and since it reached no conclusion, I figured it was probably better to err on the safe side and assume BTB/WTW must be preserved. Seems like I don't have to worry too much about it anymore, which is great.

[jazzysmooth]

So I figured I'd try a clean install (win7 SP1 32bit) to see if it would clear up my issue with the CUVID filter not loading in MPC-HC. Much to my surprise, even with a clean environment, it still wouldn't appear when playing a movie.

I then went through all the versions and discovered the following:
versions 1 and 3 will appear in the filter list when I play a movie, but the movie doesn't play. MPC-HC doesn't crash, and I can seek, but all I see is the black screen, as if it was paused. Doesn't seem to matter what renderer or audio decoder I use, I get the same result.

Versions 2, and 4-6 simply won't appear in the filter list. As mentioned in a previous post, if I block MPC-video decoder and Microsoft DTV decoder, I'll get audio but no video. Using a Zotac 93000-I-E motherboard with onboard Geforce 9300 video. Near as I can tell it supports VDPAU feature set B, so I'm confused as to why this isn't working. I also tried turning off the "Stream aspect ratio", DXVA and deinterlacing options, but made no difference.

Has anyone gotten this to work with a 9300 series chipset? Nev, any ideas what I should try? What other info can I provide?

Thanks!

[mindbomb]

i have a 9400m, which is similiar to what you are using.

all i can say is, make sure you have the vc runtime installed, run the install as admin, and update your video card drivers.

[yesgrey]

I read that AVSForum thread long ago, and since it reached no conclusion, I figured it was probably better to err on the safe side and assume BTB/WTW must be preserved.
Not keeping BTB is already considered to be the right choice. The question that still remains open is if we should keep WTW or not. In my case I don't keep WTW, and I don't miss it.;)

[CruNcher]

Nvidia released the 275.27 Beta drivers Scaling was completely overworked :)
http://www.nvidia.com/Download/Find.aspx?lang=en-us

http://de.download.nvidia.com/Windows/275.27/275.27-WinXP-Desktop-Release-Notes.pdf
http://de.download.nvidia.com/Windows/275.27/275.27-Win7-WinVista-Desktop-Release-Notes.pdf


Added support for CUDA 4.1 on GeForce 400 series and later GPUs.

Not sure though if they where any Nvcuvid changes doesn't seems so

Oh new Designed developer Zone :) http://developer.nvidia.com/

Hmm http://developer.nvidia.com/digital-video-pipeline <- empty ?

exactly 1 month after like they announced (no blog entry about them yet) :P

http://forum.doom9.org/showpost.php?p=1493926&postcount=362

[jazzysmooth]

i have a 9400m, which is similiar to what you are using.

all i can say is, make sure you have the vc runtime installed, run the install as admin, and update your video card drivers.

Thanks Mindbomb, I appreciate the response. I'll try the drivers Cruncher linked to, the other 2 suggestions I have done.

Am also curious as to why it will use versions 1 and 3 of the decoder, but none of the others...

[CruNcher]

Can someone reproduce this ? http://forum.doom9.org/showthread.php?p=1501824#post1501824

[jazzysmooth]

Thanks Mindbomb, I appreciate the response. I'll try the drivers Cruncher linked to, the other 2 suggestions I have done.

Am also curious as to why it will use versions 1 and 3 of the decoder, but none of the others...

Turns out it was a Nvidia driver issue, I had to go to a previous version (270.51) to get it working properly. 270.61 and 275.27 both cause the issues mentioned earlier.

[VincAlastor]

LAV CUVID with intel igpu and nv 9800gt dgpu
with new hardware config (win7 x64, hdmi over intel igpu 3000 (means primary gpu), discrete nv 9800 gt (270.51) and lucid virtu enabled) mpc-hc (32bit) doen't use the LAV CUVID even if i set LAV CUVID forced in mpc-hc.
internal filters are all disabled, ffdshow is blocked, but every time ffdshow will decode h.264 videos in mkv.
Could someone help me, please?

of course there is no reason to use the gpu to decode videos with an intel core ix 2xxx but i want to use LAV CUVID in avisynth with directshowsource(), so that i have to be sure that dss() use LAV CUVID... sorry for my bad english.
edit:
the same mkv in graphedit/graphstudio (32bit) will be decoded by (LAV filters) ---> microsoft DTV-DVD video decoder
...very confusing that graphedit doesn't load ffdshow like mpc-hc :/

[nevcairiel]

You would have to force that virtu thing to use the NVIDIA card when running MPC-HC. Not sure if that helps, such setups are weird anyway.

[VincAlastor]

You would have to force that virtu thing to use the NVIDIA card when running MPC-HC. Not sure if that helps, such setups are weird anyway.

thank you... i thought that too, but if i add mpc-hc.exe to the games list in lucid virtu mad-vr will be striking and say: "could not render dx9..."

[VincAlastor]

staxrip.exe runs in lucid virtu discrede mode, but i'm not sure if dss() is using LAV CUVID. please, could you integrate a info symbol for the windows taskbar for LAV CUVID like mad-vr and ffdshow do?

[nevcairiel]

Just to see if its being used? No.
You can always check with stuff like ProcessExplorer and see which modules it loaded.

Or just check your GPU usage with GPU-Z, if its 0, its not being used.