View Full Version : Fastest decoder with and without CUDA
Tuik
9th November 2010, 21:21
Hello,
I've got 2 pc's which one of them has nvidia GT330M (that supports CUDA) and the other only has onboard graphic card.
I encode from h264 sources in both of them and for now i'm using CoreAVC to decode the source (with DSS2, if you know anything faster please tell me :D ) wich also uses CUDA acceleration on the pc that supports it.
Now i'm asking if you know anything that is faster than CoreAVC since encoding takes a lot of time and i need those pc's available the most possible time.
Thanks a lot for your help!
Blue_MiSfit
9th November 2010, 21:41
CUDA decoding is a little tricky, for two reasons
1) Using CUDA for decode frees up a good chunk of CPU time to do the actual encode, especially if you have only a single or dual core CPU. This can increase encoding speeds quite a bit in some cases
2) However, CUDA places a ceiling on your maximum fps. For example, say your GT330M's decoder can spit out ~100fps for a given file. If your CPU is fast enough to encode at MORE than 100fps, your encode will bottleneck on the CUDA decode.
#2 is only really a factor when you have a lot of extremely fast CPU cores at your disposal. For the average user with a modest dual core or slower quad core, CUDA decode does net a reasonable overall encoding fps improvement.
Oh, and your method is about as fast as it can get. DGDecNV/DGIndexNV might be a little faster, since it bypasses DirectShow... hard to say though.
Hope that helps!
Derek
Tuik
9th November 2010, 22:35
CUDA decoding is a little tricky, for two reasons
1) Using CUDA for decode frees up a good chunk of CPU time to do the actual encode, especially if you have only a single or dual core CPU. This can increase encoding speeds quite a bit in some cases
2) However, CUDA places a ceiling on your maximum fps. For example, say your GT330M's decoder can spit out ~100fps for a given file. If your CPU is fast enough to encode at MORE than 100fps, your encode will bottleneck on the CUDA decode.
#2 is only really a factor when you have a lot of extremely fast CPU cores at your disposal. For the average user with a modest dual core or slower quad core, CUDA decode does net a reasonable overall encoding fps improvement.
Oh, and your method is about as fast as it can get. DGDecNV/DGIndexNV might be a little faster, since it bypasses DirectShow... hard to say though.
Hope that helps!
Derek
Hum, thanks a lot for the explanation.
Well the pc that uses CUDA has i7 Q720 (notebook) and the one without CUDA has i7 Q950 (desktop server). So i guess it's preferable, taking in attention what you have said, to decode without cuda acceleration right? But i've already experimented to encode with DSS2 and CoreAVC with and without CUDA and the results are always faster when CUDA acceleration in CoreAVC settings is activated. What should i do?
Blue_MiSfit
9th November 2010, 23:41
Use CUDA then ;)
Use whatever is fastest / fits into your workflow the easiest.
Things may get more complex if you're doing lots of encodes in parallel, or if you have sources that are unreliable through DSS2. In that case, DGDecNV can help, so long as you don't mind shelling out a measly $15.
Derek
Tuik
9th November 2010, 23:44
Use CUDA then ;)
Use whatever is fastest / fits into your workflow the easiest.
Things may get more complex if you're doing lots of encodes in parallel, or if you have sources that are unreliable through DSS2. In that case, DGDecNV can help, so long as you don't mind shelling out a measly $15.
Derek
Ok, thanks.
And in the non-CUDA system? What should i use? Another faster CPU-only x264 decoder?
nm
10th November 2010, 00:01
And in the non-CUDA system? What should i use? Another faster CPU-only x264 decoder?
There are no significantly faster decoders. The usual alternatives to CoreAVC are DiAVC (costs $10), DivX7 (freeware) and ffmpeg-mt (free, available in ffdshow and FFMS2). I doubt you'll see a difference more than 10 % in average between CoreAVC 2 and the fastest decoder in this set. This difference will be even smaller in the overall encoding time, maybe a couple percents when using medium x264 settings. Unless you are downscaling before encoding or you use very fast x264 settings, in which case decoding can become an actual bottleneck.
Tuik
10th November 2010, 00:08
There are no significantly faster decoders. The usual alternatives to CoreAVC are DiAVC (costs $10), DivX7 (freeware) and ffmpeg-mt (free, available in ffdshow and FFMS2). I doubt you'll see a difference more than 10 % in average between CoreAVC 2 and the fastest decoder in this set. This difference will be even smaller in the overall encoding time, maybe a couple percents when using medium x264 settings. Unless you are downscaling before encoding or you use very fast x264 settings, in which case decoding can become an actual bottleneck.
Hum.. I see, but for me ffdshow instead of coreavc slows a lot the encodes (talking in xvid encoding) and DirectShowSource instead of DSS2 also slows...
Any explanation? Should i try another Source to avisynth?
kristiXS
10th November 2010, 03:47
Hum.. I see, but for me ffdshow instead of coreavc slows a lot the encodes (talking in xvid encoding) and DirectShowSource instead of DSS2 also slows...
Any explanation? Should i try another Source to avisynth?
im using a quadcore 940 / 6gig ram to encode with megui to x264...when i use coreavc with cuda to decode (downsizing 720p a little as a test) rather than ffdshow, the frame rate goes from 15-17 fps to 12-14. i was expecting a speedup rather than a slowdown..
on a sidenote, when playing back test encodes after changing from ffdshow to coreavc, i saw a difference in picture color / contrast etc even though both were left at default settings; so maybe we want to consider settings adjustability as well as speed.
Blue_MiSfit
10th November 2010, 04:30
@ kristiXS:
There is NO DIFFERENCE in image quality between CoreAVC and ffdshow. If you saw a difference, it was due to one or the other adjusting the luma levels (TV vs PC) or assuming a different color matrix (601 vs 709).
Derek
nm
10th November 2010, 12:28
Hum.. I see, but for me ffdshow instead of coreavc slows a lot the encodes (talking in xvid encoding)
Do you have ffdshow set to use ffmpeg-mt for H.264 decoding? And no post-processing enabled whatsoever in ffdshow?
Should i try another Source to avisynth?
You could try FFMS2-mt (http://code.google.com/p/ffmpegsource/). It avoids DirectShow overhead and could be a percent or two faster than CoreAVC in some cases (http://forum.doom9.org/showthread.php?t=155441).
xv
10th November 2010, 23:26
2) However, CUDA places a ceiling on your maximum fps. For example, say your GT330M's decoder can spit out ~100fps for a given file. If your CPU is fast enough to encode at MORE than 100fps, your encode will bottleneck on the CUDA decode.
Is there some information/benchmarks out there how fast different graphics processors of nvidia can decode certain H.264 streams?
I´m planning to buy a new system soon and I´m not in gaming, so I don´t need high-end graphics, but a fast cuda decoder would be nice for a quad-core.
nm
11th November 2010, 00:02
Is there some information/benchmarks out there how fast different graphics processors of nvidia can decode certain H.264 streams?
You could search for qvdpautest results from nvnews.net and elsewhere. Qvdpautest uses a specific test clip for each video format. IIRC, decoding speed within a VP generation seems to depend mostly on driver version and sometimes on system misconfiguration. VP3 and VP4 may be able to decode 1080p60 H.264 in real time, VP2 can't.
I'd recommend a current generation card with VP4 chip. It's the most capable variant (supports MVC) and it should be at least as fast as the previous chips. GPU model doesn't matter (much) when using just the hardware decoder. GeForce GT430 would be appropriate, I think?
Blue_MiSfit
11th November 2010, 02:15
Yeah, it basically makes no difference. There's a benchmark thread in the DGIndex and related tools forum about this.
A GT240 was no slower than a GTX 460.... so yeah XD
Derek
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.