Thinking about building a second pc just for video encoding (Handbrake), but will look to save money anyway I can
Current rig is
If I could ditch the (expensive) graphics card for the new PC, would the encode times remain the same?
edit - bit of a strange question, but would gaming cause any problems whilst video encoding, ie. would handbrake halt on any errors caused by a system overload, or just continue and allow video corruptions?
+ Reply to Thread
Results 1 to 12 of 12
" is a little better " not that little in my honest opinion, but jagabo is right normally a high end graphic card is nor really needed.
for encoding: gpu encoding can be faster but software delivers better quality
for decoding: hardware decoder normally depend on specific chips which are mostly the same on expensive and cheap cards, sometimes hardware decoders deliver better output than software decoders (thinking about libav) and some times it's the other way around
for filtering: unless you use special filters that are written for gpu hardware decoding, gpu isn't used at all
-> unless you use specific decoders, filters and/or encoders the impact of a fast gpu is really slim (or null)users currently on my ignore list: deadrats, Stears555
Technology is catching up and is using GPUs more and more but presently it is not only messy (CUDA vs. OpenCL) but also under exposed.
For fast rendering you should get an i7 processor.
What you have is good enough for cpu encoding,most people here use cpu based encoding programs since gpu encoding isn't as good in quality.I think,therefore i am a hamster.
If you only use handbrake to encode, an Intel i-Series CPU will be sufficient.
However, ask yourself if you may do the following:
*- Any form of screencast
If you do, get a decent Nvidia card(e.g. GTX750).
The recently introduced ShadowPlay technology by Nvidia would help in this area.
Also, if you do screen capture often, HW-accelerated encoding would be a big help as it off-loads quite a burden from the CPU. This is particularly important if you ever capture a long gameplay or demonstrating operation of a CPU-heavy program(e.g. image/video editors).Stopping development until someone save me from poverty or get me out of Hong Kong...
While I think that at present time a GPU can certainly help the rendering process especially when GPU enabled effects are on the timeline some tests seem to suggest it is the most important element in the chain.
Another member of this forum gave us a link to some tests from some website that seem to suggest that adding a second GPU about halves rendering times.
I am very skeptical about this, am I simply wrong and can adding a second GPU halve rendering times, or are perhaps those tests specifically constructed to give misleading results?
(and yes they got paid by Adobe to create a hardware performance white paper)
I guess it depends on how you look at it - it's purposely misleading because they used GPU effects . Pure video encoding won't show that speedup factor in PP CC . I guess if those are common task (I suppose they are), you could argue that would be "typical"
But OP wan't asking about PP, just video encoding and handbrake in particular
It's ok. In a sense , it reflects common tasks used in PP CC . So for "typical" video editor, it makes sense to invest in decent GPU setup. But it's typical marketing speak so we have to be careful it how to interpret those tests
You'd have to do more specific tests, because some GPU tasks do almost scale linearly (!) which is incredible
I don't know about the current state of handbrake, but Intel QS was covered above
But there were also Handbrake OpenCL beta builds which used x264's OpenCL lookahead for the lookahead portion. Also there were some scaling OpenCL builds IIRC (if you were resizing in handbrake) . x264's OpenCL did speed things up a few % which is better than nothing, but there were accompanying very tiny drops in SSIM
Also, more than just lookahead is accelerated:
When enabled, the lookahead thread is mostly off-loaded to an OpenCL capable GPU device. Lowres intra cost prediction, lowres motion search (including subpel) and bidir cost predictions are all done on the GPU. MB-tree and final slice decisions are still done by the CPU. Presets which do not use a threaded lookahead will not use OpenCL at all (superfast, ultrafast).
Maybe x265 will prove to be more amiable to OpenCL acceleration.