Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
11th February 2009, 15:52 | #4401 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
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). |
|
11th February 2009, 15:57 | #4402 | Link | |
Registered User
Join Date: Aug 2008
Posts: 231
|
Quote:
For example, timecodec results for Intel Qxxx0, AMD X4, X3 and so on. |
|
11th February 2009, 16:35 | #4403 | Link |
Encoding Dinosaur!
Join Date: Oct 2001
Location: Europe
Posts: 1,668
|
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. |
11th February 2009, 17:04 | #4404 | Link |
Registered User
Join Date: Mar 2005
Posts: 433
|
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.
|
11th February 2009, 18:12 | #4405 | Link | |
CoreCodec Founder
Join Date: Oct 2001
Location: San Francisco
Posts: 1,421
|
Quote:
__________________
Dan "BetaBoy" Marlin Ubiquitous Multimedia Technologies and Developer Tools http://corecodec.com |
|
11th February 2009, 18:24 | #4406 | Link |
Registered User
Join Date: Dec 2004
Location: Melbourne, AU
Posts: 1,963
|
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).
|
11th February 2009, 19:01 | #4407 | Link |
Registered User
Join Date: Mar 2004
Posts: 1,126
|
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.
|
11th February 2009, 20:31 | #4409 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Quote:
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. Last edited by Guest; 11th February 2009 at 20:36. |
|
11th February 2009, 20:49 | #4411 | Link |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
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.. Last edited by leeperry; 11th February 2009 at 20:53. |
11th February 2009, 21:20 | #4412 | Link |
CoreCodec Founder
Join Date: Oct 2001
Location: San Francisco
Posts: 1,421
|
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.
__________________
Dan "BetaBoy" Marlin Ubiquitous Multimedia Technologies and Developer Tools http://corecodec.com |
11th February 2009, 21:21 | #4413 | Link | |
Registered User
Join Date: Dec 2004
Location: Melbourne, AU
Posts: 1,963
|
Quote:
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? |
|
11th February 2009, 21:52 | #4415 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
@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? |
11th February 2009, 21:54 | #4416 | Link |
Registered User
Join Date: Jan 2004
Posts: 849
|
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?
__________________
Geforce GTX 260 Windows 7, 64bit, Core i7 MPC-HC, Foobar2000 |
11th February 2009, 22:08 | #4417 | Link |
Registered User
Join Date: Mar 2005
Posts: 433
|
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? |
11th February 2009, 22:54 | #4418 | Link | |
Registered User
Join Date: Jan 2003
Location: Greece
Posts: 53
|
Quote:
Last edited by netchris; 11th February 2009 at 23:45. |
|
12th February 2009, 00:28 | #4419 | Link |
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
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.
|
12th February 2009, 00:33 | #4420 | Link |
CoreCodec Founder
Join Date: Oct 2001
Location: San Francisco
Posts: 1,421
|
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.
__________________
Dan "BetaBoy" Marlin Ubiquitous Multimedia Technologies and Developer Tools http://corecodec.com |
Tags |
codec, coreavc, corecodec, coremvc, cuda, decoder, dxva, h.264, mvc, scam |
|
|