CoreCodec/H.264 Codec "CoreAVC"

[chros]

The 181.22 driver by itself does not contain all the needed components. Perhaps you've installed one of the DG***IndexNV programs.
and @ Malow: indeed ... Thanks for clarifying this ...

[leeperry]

we are working hard on issues reported and have already fixed a number of them.
indeed you have, no more banding/blockiness and very rare artifacts on seeking in KMPlayer w/ the latest beta I've been given.

way to go :cool:

[Inventive Software]

Those decoder figures are interesting: seems software decoding is still the way to go!

[nm]

Those decoder figures are interesting: seems software decoding is still the way to go!
Certainly in some situations, if you need a high throughput or if the video exceeds some limitations of the hardware decoder. However, dedicated hardware is much more energy-efficient (and therefore requires less cooling).

[leeperry]

Those decoder figures are interesting: seems software decoding is still the way to go!
well, it still offloads the CPU........for whatever x264 encoding or avisynth PP in ffdshow :p

[BetaBoy]

Those decoder figures are interesting: seems software decoding is still the way to go!

In some cases sure... but I'd also hold off in any decision of what do use till we release a few of the next 1.9.x bug fixes releases, with interlaced support being the most important.

[Disabled]

(2) Or you could use the general purpose CUDA stuff to let NVidia accelerate only some specific parts of your software decoding code. (Probably this would be run by the shader hardware [...]).
madshi... more of the #2 approach. That has been the basis for all our goals with GPU... obviously more so with CorePlayer (xScale, ATI, Marvell, Qualcomm/QTv, RMI and next CUDA) then with CoreAVC to this point.
initial tests show that there is no decoding speed difference between a 8600gt and a 8800gt i have. [...], but thats to be expected since both of the cards use the same VP2 processor.
Ok, so CoreaAvc 1.9 doesn't really have decoding "CUDA-code", but rather tries to use VP via CUDA API instead of DxVA API? That's all?
BetaBoy can you comment on this?

I'd really like to get an honest answer: Are you using shaders to do your acceleration? If yes, why is there a need for the VP2 decoding engine, and there is no speedup with better cards? Either way: Is there a plan to extend the support and get rid of the VP2 need? Bonus: If ever ATI plans do have a compelling API and support and such, will you support them too, will the upgrade be free for 1.x owners?

[BetaBoy]

Disabled... I'm not going to go into a detailed explanation of CUDA. Also, the need is 'no need' at all (from what I remember being told), VP2, VPx are are independent generations and we do not require one generation to work with the next (I'll confirm this). Read this if you want to know the other answers on shading and CUDA vs. other solutions: http://developer.download.nvidia.com/presentations/2008/NVISION/NVISION08_ImageVideoCUDA_web.pdf

On ATI.... we have no plans for supporting their hardware anytime soon.

[dansus]

indeed you have, no more banding/blockiness and very rare artifacts on seeking in KMPlayer w/ the latest beta I've been given.

way to go :cool:

Where? how?

I would like to join the beta game too... :p

[lexor]

Disabled... I'm not going to go into a detailed explanation of CUDA. Also, the need is 'no need' at all (from what I remember being told), VP2, VPx are are independent generations and we do not require one generation to work with the next (I'll confirm this).

I think what everyone was getting at, was the claim made by Leak in MPC-HC thread. The claim was that CoreAVC-CUDA uses shaders and not ASIC of VP2, thus card kicks all the shader units into high gear, power consumption kicks into high gear, fans kick into high gear. So, Leak claimed that CUDA solution is louder and more power hungry than DXVA in MPC-HC.

All those people quoted above probably wanted to know if that's true.

[hajj_3]

if thats true it would be nice to have a "maximum acceleration" and "low power acceleration" as my cpu is a quad core overclocked to 3.5ghz so my pc is fast anyway but less cpu usage when playing 1080p is always welcome but i dont want it to make my electricity bills go up.

[Cyber-Mav]

I think what everyone was getting at, was the claim made by Leak in MPC-HC thread. The claim was that CoreAVC-CUDA uses shaders and not ASIC of VP2, thus card kicks all the shader units into high gear, power consumption kicks into high gear, fans kick into high gear. So, Leak claimed that CUDA solution is louder and more power hungry than DXVA in MPC-HC.

All those people quoted above probably wanted to know if that's true.

not true since both my 8600gt and 8800gt stay at idle temps when using coreavc in cuda mode which means there is hardly any load on the gfx card.

[STaRGaZeR]

not true since both my 8600gt and 8800gt stay at idle temps when using coreavc in cuda mode which means there is hardly any load on the gfx card.

That's because CoreAVC is NOT using the shaders. The power consumption of VPx is negligible.

[lexor]

not true since both my 8600gt and 8800gt stay at idle temps when using coreavc in cuda mode which means there is hardly any load on the gfx card.

Hey, you don't have to convince me. But when I said Core was using vp2 as well (by analogy with neuron2's work)... I was called a fool and told to read some wiki articles. At that point I left that discussion. Dunno if they settled it or not... don't much care.

[Disabled]

I asked this, because Betaboy said they were using "more of the #2 [shader] approach. That has been the basis for all our goals with GPU".
But quite obviously, they are not using a shader, but a vp2 approach.
And maybe its my english, but I don't quite understand the following sentence:
Also, the need is 'no need' at all (from what I remember being told), VP2, VPx are are independent generations and we do not require one generation to work with the next (I'll confirm this).
Are you implying you don't need VP2?

[DeepBeepMeep]

I asked this, because Betaboy said they were using "more of the #2 [shader] approach. That has been the basis for all our goals with GPU".
But quite obviously, they are not using a shader, but a vp2 approach.
And maybe its my english, but I don't quite understand the following sentence:

Are you implying you don't need VP2?

According to the document mentioned by Betaboy (see p30/31), you can access the H264 video decoder through the CUDA API, so this should explain how CoreAVC Cuda support works...

[STaRGaZeR]

And maybe its my english, but I don't quite understand the following sentence:

Are you implying you don't need VP2?

The same goes for me. I don't know if that was intentional but it sounded like a very good evasive, dunno why. Is that hard to say "hey, CoreAVC doesn't use the shaders, it uses the VPx unit present in the following GPUs: ... "?

[Sulik]

Both CoreAVC and neuron2's DGAVCDecNV use nvcuvid.dll which allows access to VPx HW from CUDA applications (technically, it probably uses both VPx and shaders to some extent)

[CiNcH]

Well, maybe some would feel like 15$ is too much if they knew that the filter was only calling some pretty simple API functions... ;)

On ATI.... we have no plans for supporting their hardware anytime soon.
Obvious.

[Guest]

Well, maybe some would feel like 15$ is too much if they knew that the filter was only calling some pretty simple API functions If you think it is simple, you need to read this:

http://neuron2.net/dgavcdecnv/cuda/cuda.html

[jj666]

Well, maybe some would feel like 15$ is too much if they knew that the filter was only calling some pretty simple API functions... ;)


Obvious.

Actually, I've found Donalds utilities very helpful and given the support and frequency of updates, I think the $15 is extremely cheap. Given the compatibility is much better than the libav counterparts (I'm encoding a few things ripped with my Dreambox, where DGAVCDEC fails and DGAVCDECNV doesn't).

In the past, I thought exactly the opposite regarding CoreAVC as (despite being a paid user here), the updates are few and far between and I've never felt the details given here on the forum were detailed enough, or supportive enough (especially in the state of the Haali muxer). However, with the new CUDA decoding issues I experienced fast and extremely helpful service to solve all of my found issues. Now would wholeheartedly recommend this software to everyone.

I'm guessing most of the negativety is coming from ATI users, where they found they're somewhat out in the cold regarding such innovative software.

Cheers,

-jj-

[STaRGaZeR]

However, with the new CUDA decoding issues I experienced fast and extremely helpful service to solve all of my found issues. Now would wholeheartedly recommend this software to everyone.

Honestly, I don't know how almost everyone is having decoding issues and still the product is released. How did it pass QA? It gives the impression of using normal users as betatesters. Also as you say they seem completely centered in CUDA, which is understandable given how popular it is from a marketing and business point of view.

I'm guessing most of the negativety is coming from ATI users, where they found they're somewhat out in the cold regarding such innovative software.

That's far from the truth. It's hard to be impressed when you can get the same from DXVA, without the current bugs and for free. The only situation where CoreAVC CUDA offers any innovation is when the user wants to insert any kind of filters like ffdshow for postprocessing purposes between CoreAVC and the renderer while maintaining hardware decoding, something 99,9% of users will never do, NV or ATI.

[BetaBoy]

Well, maybe some would feel like 15$ is too much if they knew that the filter was only calling some pretty simple API functions... ;)

4 months of engineering, and like neuron2 working directly with the NVIDIA engineers is far from a 'simple' addition.

[BetaBoy]

That's far from the truth. It's hard to be impressed when you can get the same from DXVA, without the current bugs and for free.
Well given that DXVA is on 2.x and been out for at least 3+ years and CUDA video decoding is officially only 7 days old ;-)

STaRGaZeR... point taken but I disagree. I'm not sure you see the full picture. CoreAVC 2.0 will shed even more light on this.

[TheShadowRunner]

Well, you can NOT get the same from DXVA.
Add any filter after the decoder and it'll break DXVA. Adding a filter after CoreAVC in CUDA mode doesn't break CUDA. (hint: VSFilter ^^)
Later,

TSR

[CiNcH]

4 months of engineering, and like neuron2 working directly with the NVIDIA engineers is far from a 'simple' addition.
I did not say that it is easy or simple, but that some people may think that it is. Those who know nothing but always only talk... You know them... Maybe because of them a clear statement that the decoder is not based on shaders was not given... You preferred to hang about...

[squid_80]

Are you implying you don't need VP2?
CoreAVC doesn't specifically do any sort of check for VPx. It asks the card (CUDA device) if it supports Compute Capability 1.1, since that is the minimum required for the nvcuvid component to work.
CoreAVC uses lower-level calls than both MPC-HC's DXVA filter and DGAVCIndexNV. This lets it do a few things more efficiently in the CPU, and also avoid a few bugs.
Are you using shaders to do your acceleration? If yes, why is there a need for the VP2 decoding engine, and there is no speedup with better cards? Shaders are not used directly. They may become important later if we add some new features.
If ever ATI plans do have a compelling API and support and such, will you support them too, will the upgrade be free for 1.x owners? Sure, if they open up UVD in a similar way to NVIDIA. I heard (not official in any way) at the start of this month that they plan to, but it will be a while before anything is released - probably at least 6 months.
Well, maybe some would feel like 15$ is too much if they knew that the filter was only calling some pretty simple API functions... ;)
It's not like we added $15 to the price when CUDA support was added. The price remained exactly the same and CUDA was added as an additional feature. Can't see how that is bad value for money.
Honestly, I don't know how almost everyone is having decoding issues and still the product is released. How did it pass QA? It gives the impression of using normal users as betatesters.
With CUDA enabled on a direct BD Rip ("Hostage") at 25Mb birate only 3%-14% CPU. Great job!! (http://forum.corecodec.com/viewtopic.php?f=3&t=1750)
I tried it and it works perfectly! The CPU usage dropped from 25-30% to 5-10%. Nice job guys ! (http://forum.corecodec.com/viewtopic.php?f=3&t=1724&st=0&sk=t&sd=a&start=60#p8972)
Just threw a 720p copy of Indiana Jones and the Crystal Skull at it, uh, 3-5% CPU usage with CUDA working, WOW :) (http://forum.corecodec.com/viewtopic.php?f=3&t=1724&st=0&sk=t&sd=a&start=30#p8889)
Shockingly the transformers rip i made played fine and thats using the unrestricted profile. (http://forum.doom9.org/showthread.php?p=1248171#post1248171)
Not everyone is experiencing problems. Generally with software you will get feedback from 10% of the happy users and 90% of the unhappy users.
Also as you say they seem completely centered in CUDA, which is understandable given how popular it is from a marketing and business point of view.Not really true, as jj666 and leeperry have noted the CUDA issues have been sorted but a new release isn't out yet because there's some small unrelated things to fix/add.
It's hard to be impressed when you can get the same from DXVA, without the current bugs and for free. The only situation where CoreAVC CUDA offers any innovation is when the user wants to insert any kind of filters like ffdshow for postprocessing purposes between CoreAVC and the renderer while maintaining hardware decoding, something 99,9% of users will never do, NV or ATI.
Additionally:
- Supports up to 15 reference frames (I have asked several people who say this isn't working for samples, and have received none. Please contact me via PM if you think you have such a sample).
- Can be used when a renderer isn't in the directshow graph at all, such as in an avisynth script feeding x264 or any other application that supports generic directshow filters (i.e. virtualdub directshow plugin)
- Doesn't rely on the directshow architecture, so companies licensing the CoreAVC library can still use it
There are also the post-processing options that are built into the filter, such as output colorspace selection, software deinterlacing, input/output levels selection and the brightness/contrast/saturation settings.

[Disabled]

Thanks squid for your good reply!
Two comments though: Afaik, there is no compute shaders 1.1 without VP>=2, so the checks are the same. Sure Nvidia could do a driver for the 8800 GTS/GTX with cs1.1 and implement VP2 in the shaders, but thats not gonna happen.
Second, its not like you added an additional feature, because you felt like it. I paid for GPU support 3 years back, so it was your duty do deliver it.

[BetaBoy]

Second, its not like you added an additional feature, because you felt like it. I paid for GPU support 3 years back, so it was your duty do deliver it.
Sure, we wanted to deliver on the promise! Noting that 3 years ago CUDA was just on the drawing board and that our goals we not aligned with that of the DXVA approach. We are very happy with the decision to wait and with the help of the NVIDIA team (thank you NVIDA Devs!) we are just as excited to see whats on the 2.0 horizon.

We continue to thank everyone for their support (and patience).

[jj666]

Honestly, I don't know how almost everyone is having decoding issues and still the product is released. How did it pass QA? It gives the impression of using normal users as betatesters. Also as you say they seem completely centered in CUDA, which is understandable given how popular it is from a marketing and business point of view.


I tested over 2tb of Blu-ray remuxes and posted 3 incorrectly displayed movies, of which two were fixed in one day and the last a day later. I'd hardly call three out of approx seventy movies with errors a gross incompatibility. I'm only aware of Rectal Prolapse with similar issues, rather than the entire thread being in an outcry?

I must admit that I've not tried this DVXA method, apart from several months ago attempting to use MPC-HC which wouldn't even play back a VC-1 stream correctly, so stuck with MPC and ffdshow for VC-1/Mpeg-2 and CoreAVC for H264.

Cheers,

-jj-

[Cyber-Mav]

iv tried the MPC HT DXVA approach and it failed miserably half the stuff i tried to run would resort to software based decoding.

CUDA is the best way since everything iv thrown at it works in hardware accelerated mode, some videos which arent compliant show up artifacts and blockyness but are still hardware accelerated. that shows the robustness of coreavc cuda.

im sure in the up comming bug fix versions these minor problems will be addressed, i treat coreavc 1.9.0 as a taster of whats to come, and thanks to the power of CUDA a lot of the old systems i have in the house wont need to be replaced for HD video acceleration, just a cuda card to do the business.

excellent work Betaboy on your continued support for coreavc, at $15 its a bargain that no HD viewer should pass up on.

[Rectal Prolapse]

I'm only aware of Rectal Prolapse with similar issues, rather than the entire thread being in an outcry?

Funnily enough, the first two titles I tried with the new CoreAVC had those blocking issues. At that time, it would be a 100% failure rate. :)

I later tried 2 more titles and those were okay (lower bitrate titles incidentally). So now the failure rate is 50% from my point of view. That's not so good hahaha! But hey, I was expecting this so am not too bothered by it. It isn't like PowerDVD's h264 decoder (with h/w acceleration) which is 100% reliable for me - it would be unreasonable for me to expect coreavc to even be close to that at this point in time. CUDA is very new, and there WILL be titles it will not work on.

[me7]

Is the CUDA acceleration incompatible with the Windows 7 beta? I just installed CoreAVC 1.9 and the newest nVidia drivers that add CUDA support (179.48_notebook_winvista_32bit_beta) on my notebook. It has a 8400M GS that is supposed to support CUDA but the option in CoreAVC is greyed out.

[STaRGaZeR]

STaRGaZeR... point taken but I disagree. I'm not sure you see the full picture. CoreAVC 2.0 will shed even more light on this.

I don't know what CoreAVC 2.0 will be or will do, and more importantly when (given your past historial), so please accept the complaints until then :p. The current product is like people in this thread is describing, when the bugs are ironed out don't worry, everybody will say how great and bug free CoreAVC is like with everything else.

With CUDA enabled on a direct BD Rip ("Hostage") at 25Mb birate only 3%-14% CPU. Great job!! (http://forum.corecodec.com/viewtopic.php?f=3&t=1750)
I tried it and it works perfectly! The CPU usage dropped from 25-30% to 5-10%. Nice job guys ! (http://forum.corecodec.com/viewtopic.php?f=3&t=1724&st=0&sk=t&sd=a&start=60#p8972)
Just threw a 720p copy of Indiana Jones and the Crystal Skull at it, uh, 3-5% CPU usage with CUDA working, WOW :) (http://forum.corecodec.com/viewtopic.php?f=3&t=1724&st=0&sk=t&sd=a&start=30#p8889)
Shockingly the transformers rip i made played fine and thats using the unrestricted profile. (http://forum.doom9.org/showthread.php?p=1248171#post1248171)
Not everyone is experiencing problems. Generally with software you will get feedback from 10% of the happy users and 90% of the unhappy users.
Not really true, as jj666 and leeperry have noted the CUDA issues have been sorted but a new release isn't out yet because there's some small unrelated things to fix/add.

It's the same for DXVA. You're using the same piece of hardware in the end, just accessed through different APIs. If there are issues in one side and in the other don't it's probably because of a faulty implementation, drivers or whatever.
Also what feedback do you need from the happy users? That's obvious.
Is the field order issue in your list? Because it's been said over and over, you keep saying it's not a problem when it is and BetaBoy has never responded to it AFAIK.

Additionally:
- Supports up to 15 reference frames (I have asked several people who say this isn't working for samples, and have received none. Please contact me via PM if you think you have such a sample).

It's the same for DXVA, ask MPC developers about how they removed the ref frames limitation when the driver for L5.1 support was released. There are still problems though, you can find samples in the MPC thread. But still there are people that just max out x264 and just can't get hardware decoders to work with their encodes, and they're within the H.264 specification and played perfectly by software decoders. That's THE limitation of DXVA and CoreAVC CUDA.

- Can be used when a renderer isn't in the directshow graph at all, such as in an avisynth script feeding x264 or any other application that supports generic directshow filters (i.e. virtualdub directshow plugin)
- Doesn't rely on the directshow architecture, so companies licensing the CoreAVC library can still use it
There are also the post-processing options that are built into the filter, such as output colorspace selection, software deinterlacing, input/output levels selection and the brightness/contrast/saturation settings.

Indeed, that's THE advantage of CoreAVC, as I wrote in my previous post. You can get the same and more postprocessing options with ffdshow or any other filter. On a side note CoreAVC doesn't do proper chroma upsampling when outputting RGB32, something that can be easily achieved with ffdshow. In my book that makes the option useless.

I tested over 2tb of Blu-ray remuxes and posted 3 incorrectly displayed movies, of which two were fixed in one day and the last a day later.

Actually that's funny, because Blu-ray should be error free since the beginning. There is nothing problematic in there that the VPx can't handle. Try some strange x264 options and you'll find the limitations very fast.

CUDA is the best way since everything iv thrown at it works in hardware accelerated mode, some videos which arent compliant show up artifacts and blockyness but are still hardware accelerated. that shows the robustness of coreavc cuda.

Just in case you don't know, that's done on purpose. The MPC devs don't want any kind of blokiness if possible, so for those situations it falls back to software decoding. Who cares if it's accelerated if half the stuff that is accelerated is bloky or something? If you want to do an apples to apples comparison try Cyberlink's decoder or similar, those will use DXVA regardless of the source. That or you can compile your own MPC without the limitations and force DXVA always.

[squid_80]

It's the same for DXVA, ask MPC developers about how they removed the ref frames limitation when the driver for L5.1 support was released. There are still problems though, you can find samples in the MPC thread. But still there are people that just max out x264 and just can't get hardware decoders to work with their encodes, and they're within the H.264 specification and played perfectly by software decoders. That's THE limitation of DXVA and CoreAVC CUDA.
The MPC devs don't want any kind of blokiness if possible, so for those situations it falls back to software decoding.
I'm not really following here, you seem to say the MPC developers removed the reference frame limitation but then say it falls back to software in certain situations. I was under the impression that the reference frame limitation is enforced in the DXVA filter and this is the primary reason it falls back to software.
Also as I said if anyone has any samples with 15 ref frames or less that are failing with CoreAVC+CUDA (freezing or showing green blocks) I would like to see them.

[Sulik]

Also, a lot of so-called "DXVA" issues are actually DPB management problems in MPC-HC (I've said this from the beginning). Anything that uses MMCO and/or long-term references will not decode correctly in MPC-HC, due to the way MPC-HC manages reference frames.

[ranpha]

I'm not really following here, you seem to say the MPC developers removed the reference frame limitation but then say it falls back to software in certain situations. I was under the impression that the reference frame limitation is enforced in the DXVA filter and this is the primary reason it falls back to software.
Also as I said if anyone has any samples with 15 ref frames or less that are failing with CoreAVC+CUDA (freezing or showing green blocks) I would like to see them.

I have already PM'ed you the links to sample files that has freezing and green flashings. For me CoreAVC CUDA is at best, alpha version. It fails with so many of my test files (north of 90%) that works with MPC-HC DXVA it wasn't even funny. I expect this to improve with the next iterations of CoreAVC 1.9.x.x or else it may well affect my plans to buy an upgrade to 2.0.

[MatMaul]

Also, a lot of so-called "DXVA" issues are actually DPB management problems in MPC-HC (I've said this from the beginning). Anything that uses MMCO and/or long-term references will not decode correctly in MPC-HC, due to the way MPC-HC manages reference frames.
can we have complete explanation on what is the problem in the MPC-HC thread so we can fix it ?
thanks in advance :)

[paulvdb]

Is the CUDA acceleration incompatible with the Windows 7 beta? I just installed CoreAVC 1.9 and the newest nVidia drivers that add CUDA support (179.48_notebook_winvista_32bit_beta) on my notebook. It has a 8400M GS that is supposed to support CUDA but the option in CoreAVC is greyed out.
CUDA is enabled for me in Windows 7 x64. I have a 9400 GT card. But is it not supposed to work for all h264 content? The tray icon turned green to indicate that it uses CUDA when I played a 720p mkv that was encoded with x264. But it did not use CUDA on a ts that I recorded from BBC HD.

[TheShadowRunner]

Currently, interlaced contents decoding falls back to full software mode afaik.

[me7]

CUDA is enabled for me in Windows 7 x64. I have a 9400 GT card. But is it not supposed to work for all h264 content? The tray icon turned green to indicate that it uses CUDA when I played a 720p mkv that was encoded with x264. But it did not use CUDA on a ts that I recorded from BBC HD.

I mean the settings, not the tray icon
http://img179.imageshack.us/img179/726/screenshotvq8.th.jpg (http://img179.imageshack.us/my.php?image=screenshotvq8.jpg)
CUDA is greyed out here although I have the 179.48 driver from February 11th and the nvcuda.dll is in my System32 folder. Seems like Win 7 is not the issue.
nVidia says (http://www.nvidia.com/object/geforce_8400M.html) that the 8400M supports PureVideo HD, and according to wikipedia (http://en.wikipedia.org/wiki/Purevideo) the G84 supports VP2. What could be wrong?

[Cyber-Mav]

just a heads up for everyone, Nvidia have released the latest official WHQL driver version 182.06 now, im gonna grab that and see what version of the cudavid library it uses.


got the new driver installed now not done any testing yet but the nvcuvid.dll file is a different version, only slightly though.
driver 182.05 beta had file version 6.14.11.8205 and the new driver has nvcuvid.dll version 6.14.11.8206 and vista is using version 7.15.11.8206

[paulvdb]

Thanks, TheShadowRunner. That explains why BBC HD and also ITV HD don't work with CUDA.

me7, I think you need a newer version of the Nvidia drivers. I don't think 179.48 included nvcuvid.dll. I think until now only the beta drivers included that file. But if 182.06 is now the latest non-beta release you can use that.

[me7]

me7, I think you need a newer version of the Nvidia drivers. I don't think 179.48 included nvcuvid.dll. I think until now only the beta drivers included that file. But if 182.06 is now the latest non-beta release you can use that.

182.06 is desktop only, 179.48 (http://www.nvidia.com/object/geforce_notebook_winvista_179.48_beta.html) is the newest laptop beta version from February 11th that does include CUDA support (see link) and the nvcuda.dll was installed to my System32 directory.

@BetaBoy: are mobile drivers maybe unsupported?

[nm]

182.06 is desktop only, 179.48 (http://www.nvidia.com/object/geforce_notebook_winvista_179.48_beta.html) is the newest laptop beta version from February 11th that does include CUDA support (see link) and the nvcuda.dll was installed to my System32 directory.
And what about nvcuvid.dll, was it installed too?

[STaRGaZeR]

I'm not really following here, you seem to say the MPC developers removed the reference frame limitation but then say it falls back to software in certain situations. I was under the impression that the reference frame limitation is enforced in the DXVA filter and this is the primary reason it falls back to software.
Also as I said if anyone has any samples with 15 ref frames or less that are failing with CoreAVC+CUDA (freezing or showing green blocks) I would like to see them.

The removed the limitation only for NVIDIA cards and only if the driver with L5.1 support or newer was installed. That was several months ago. MPC-HC is 1-1,5 years old. I can't know when Cyber-Mav tested DXVA and was so disappointed because it fell back to software mode, so I answered in consequence. And yes, number of reference frames is usually why DXVA is not used. For other cards there is an absolute ref frame limit at 11 (or 12, can't remember) imposed by the devs, but that's because MPC's DXVA decoder can't properly handle them and it's not a hardware or DXVA limitation.

[squid_80]

The removed the limitation only for NVIDIA cards and only if the driver with L5.1 support or newer was installed. That was several months ago.
I can't verify this since using build 998 it falls back to software for any stream with more than 11 references (9600GT).

[me7]

And what about nvcuvid.dll, was it installed too?

No, that .dll is missing. Sounds like a definitive NO for mobile cards (at least until nVidia updates their drivers) :mad:

[STaRGaZeR]

I can't verify this since using build 998 it falls back to software for any stream with more than 11 references (9600GT).

I stand corrected with exceptions:

http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=867

http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=857

http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=975

The 11 ref frames limit is still there even for NV cards with L5.1 support in certain scenarios, here (http://forum.doom9.org/showpost.php?p=1251180&postcount=4537) is the explanation.

[Cyber-Mav]

iv installed media player classic last week and was doing more testing on it this week. one thing is sure though, MPC HC does have lower cpu usage than coreavc cuda and it does not get blocky/artifacting in videos like coreavc cuda does. however 3 videos i tried have resorted to software playback on MPC whereas they stay hardware accelerated with coreavc cuda but have few blocking/artifacting issues.

version of MPCHC i use is: MPC-HC v1.2.908.0 / 32 bits November 29, 2008

nothing newer on the sourceforge site. and mpc seems to have massive memory usage, dunno if its a memory leak or something.