How much is the graphics card used in video encoding?

[justinrye]

Thinking about building a second pc just for video encoding (Handbrake), but will look to save money anyway I can

Current rig is

i5 2500k
8gb
gtx570

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?

[jagabo]

How much is the graphics card used in video encoding?

Usually not at all.

Handbrake (beta builds) supports Intel Quick Sync encoding. That's faster than x264 but the quality isn't as good. Haswell's (4xxx CPU numbers) quality is a little better than Ivy Bridge (3xxx) or Sandy Bridge (2xxx).

[Selur]

" 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)

[newpball]

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.

[johns0]

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.

[MaverickTse]

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
*- Gaming
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).

[newpball]

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?

Source: http://provideocoalition.com/f/story/adobe-premiere-pro-and-multiple-gpus
(and yes they got paid by Adobe to create a hardware performance white paper)

[poisondeathray]

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

[newpball]

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"

I do not believe it is even a normal mixture of rendering and GPU effects, to me it seems to be designed to make people believe that their rendering time is halved if they add another GPU.

[poisondeathray]

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

I do not believe it is even a normal mixture of rendering and GPU effects, to me it seems to be designed to make people believe that their rendering time is halved if they add another GPU.

You'd have to do more specific tests, because some GPU tasks do almost scale linearly (!) which is incredible

[poisondeathray]

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

[sophisticles]

x264's OpenCL did speed things up a few % which is better than nothing, but there were accompanying very tiny drops in SSIM

The lead developer once claimed that OpenCL actually sped up x264 by about 40% on some of the AMD so-called "APU' processors.

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).

The one thing I don't understand is why is it limited to Lowrez scenarios, it would seem to me that HD resolutions would benefit more from the speed up and would be easier to parallelize due to having more pixels per frame.

Maybe x265 will prove to be more amiable to OpenCL acceleration.