CoreCodec/H.264 Codec "CoreAVC"

[madshi]

Originally Posted by BetaBoy

Ahh... that could be the case then. We are taking the stand to not include the CUDA DLL in our installer but instead opting to use the one that is public. We will see if this is the right approach as time progresses and continue to work with NVIDIA on it.

I agree that distributing the CUDA DLL with CoreAVC doesn't make much sense, since the danger would be high that the CUDA DLL you distribute would be outdated rather soon.

But maybe you could make the latest CUDA DLL available as a separate optional download? Updating this download whenever a new CUDA version is available should be easy for you (no need for any installers or release notes or such stuff, just the DLL).

[Gleb Egorych]

Originally Posted by BetaBoy

What I have found out so far based on the feedback is that since every system configuration is different it yields varied results. We are getting some report of a massive drop of 60% CPU usage down to 1%-7%. But I think the average so far is about a 50-60% reduction (more like 75% for me with a dual core 3.2ghz 9400GPU laptop).

You apparently talk about CUDA acceleration but I asked about pure software decoding, about comparing different CPUs.
For example, timecodec results for Intel Qxxx0, AMD X4, X3 and so on.

[DJ Bobo]

Since we're talking about CPU usage here, shouldn't the hardware requirements list on the CoreAVC homepage get updated? Recommending a P4@2.8GHz for 1080p videos can be a little bit misleading, can't it? I mean, I'm getting a little over 70% average CPU usage on an Athlon X2 QL-60 (1.9GHz) which should be roughly equivalent to a Pentium D @ 3.2GHz, and you recommend a P4?!
I mean not everybody can use this CUDA thing, I have a Radeon for instance.

[Rectal Prolapse]

The artifacts jj666 saw look identical to what I saw with Max Payne and Ghost in the Shell: Stand Alone Complex: Solid State Society (whew, long name!), so if you fix those other titles I'm sure it'll work with these.

[BetaBoy]

Originally Posted by DJ Bobo

Since we're talking about CPU usage here, shouldn't the hardware requirements list on the CoreAVC homepage get updated? Recommending a P4@2.8GHz for 1080p videos can be a little bit misleading, can't it? I mean, I'm getting a little over 70% average CPU usage on an Athlon X2 QL-60 (1.9GHz) which should be roughly equivalent to a Pentium D @ 3.2GHz, and you recommend a P4?!
I mean not everybody can use this CUDA thing, I have a Radeon for instance.

We are holding off in such changes till we release the Press Release with NVIDIA. Then we will update the frontpage and the requirements page. However we have updated both the changelog and the Configuration Guide to reflect the 1.9 release.

[squid_80]

Originally Posted by neuron2

That's unfortunately not necessarily the case. I use the latest nvcuvid.dll from my contact at Nvidia. The version I have has several fixes beyond what is in the released driver.

Your quickstart html tells people to copy nvcuvid.dll into the windows/system32 directory, so it's going to clobber the one installed with the driver anyway (or alternatively be clobbered if the user installs a new driver).

[hajj_3]

would it not be best to include the .dll in 1.9.0.0 and update it by 1 build each time and bundle the new .dll in and call it 1.9.0.1 have the changelog say "updated cuda .dll file". would save loads of people from having to mess around.

[STaRGaZeR]

Field order when using hardware deinterlacing is still wrong.

[Guest]

Originally Posted by squid_80

Your quickstart html tells people to copy nvcuvid.dll into the windows/system32 directory, so it's going to clobber the one installed with the driver anyway (or alternatively be clobbered if the user installs a new driver).

Most CoreAVC users are not DG tool users, so my point stands. Or maybe I missed yours?

My point was that nvcuvid.dll is evolving faster than the driver releases, and it would benefit users to distribute the latest version, as I do for my tools.

[Guest]

Originally Posted by STaRGaZeR

Field order when using hardware deinterlacing is still wrong.

The VMR framework forces a one-field delay when the deinterlacer is enabled.

[leeperry]

thanks for the final 1.9!

but my pulp fiction sample still suffers from banding(doesn't occur in software decode, only CUDA), and seeking still makes terrible artefacts in KMPlayer(only in CUDA mode)

that's w/ the 181.20 drivers on XP SP3, I'll try to update..

[BetaBoy]

Originally Posted by neuron2

My point was that nvcuvid.dll is evolving faster than the driver releases, and it would benefit users to distribute the latest version, as I do for my tools.

Short term that maybe the case... but I think in a few weeks that it will be diff. But maybe there is a compromise. I'll ping the guys.

[squid_80]

Originally Posted by neuron2

Most CoreAVC users are not DG tool users, so my point stands. Or maybe I missed yours?

My point was that nvcuvid.dll is evolving faster than the driver releases, and it would benefit users to distribute the latest version, as I do for my tools.

My point was if a user says "It doesn't work with CoreAVC, but it works with DGAVCIndexNV" then they obviously do have both installed and have probably copied your nvcuvid.dll to the system directory. But then again if they've installed the driver afterwards it might have switched the dll to an older version. I think it would be better if DGAVCIndexNV didn't rely on nvcuvid.dll being in system32; the program location is stored in the .dga file so why can't DGAVCDecodeNV load nvcuvid.dll from there?

I see 2 strong reasons for not distributing nvcuvid.dll with CoreAVC:
- It's now part of the official driver package from nvidia and it's bad practice for applications to overwrite driver files with unofficial versions (unofficial = no version information attached to the .dll)
- It's a lot easier to trace bugs if you know exactly what configuration the user has. It's easier to ask them what driver version is installed than ask them to find the timestamp/hash of a .dll and hope you've got a matching version somewhere.

leeperry: Does the pulp fiction sample look exactly the same as before?

[leeperry]

Originally Posted by squid_80

leeperry: Does the pulp fiction sample look exactly the same as before?

a bit better, but still quite a lot of banding.
and seeking in KMPlayer looks a bit better too, less artefacts but they're still there.
none of this happens in software mode

[madshi]

@BetaBoy,

I'm a bit confused about what kind of CUDA acceleration you're actually using. It seems to me that there are two different possibilities:

(1) Either you could let the NVidia dedicated video decoding circuit decode the h264 stream.

(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 and not the video decoding circuit of the graphics card).

Could you please clarify which solution you're using? To be honest, I don't really like the idea of using (1), because if there's a bug in the video decoding circuit, all hope is lost. Basically by using (1) you'd give up all control over quality. It's possible that there are some shortcuts in the video decoding circuit, so we can't be 100% sure if we get perfect quality or not. I don't see such risks when using approach (2), so I was hoping you'd use that.

Finally, if you (ever) switch from CUDA to OpenCL, probably you'd be forced to choose approach (2), right?

[lexor]

Hey Betaboy, you said previously that CUDA has no inherent limitations like DXVA, but the guys in MPC-HC thread are reporting that they get the exact same compatibility level with 1.9 as they do with build in DXVA decoder.

What's the score here?

[Rectal Prolapse]

Well, according to the DGAVCIndexNV documentation, DGAVCIndexNV requires an NVIDIA card that has the VP2 or better video unit in it. So I suspect that a lot of the work is still being done by the built-in video decoder that is also used by DXVA. I would hazard a guess that CoreAVC does the same thing.

Now the thing is - the Cyberlink (powerdvd) h264 decoder is DXVA and works fine in h/w mode decoding everything I've thrown at it, and use the same amount of CPU. Weird huh?

[netchris]

Originally Posted by Rectal Prolapse

Well, according to the DGAVCIndexNV documentation, DGAVCIndexNV requires an NVIDIA card that has the VP2 or better video unit in it. So I suspect that a lot of the work is still being done by the built-in video decoder that is also used by DXVA. I would hazard a guess that CoreAVC does the same thing.

Sigh, if that is true, this cuda implimentation will not work with my 8800 gts 640MB (first generation 8800) either (as mpc hc doesnt too). I had high hopes coreavc 1.9 would work with my gpu. No luck it seems..

[STaRGaZeR]

Originally Posted by neuron2

The VMR framework forces a one-field delay when the deinterlacer is enabled.

I can't see why that would affect CoreAVC passing BFF flags with TFF content to the renderer. This is in software mode BTW and has been the same since forever. It has been discussed in this thread a few pages back.

[BetaBoy]

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.

lexor... I'll check with the guys.