VideoHelp Forum

Try DVDFab and download streaming video, copy, convert or make Blu-rays,DVDs! Download free trial !
+ Reply to Thread
Results 1 to 12 of 12
Thread
  1. 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?
    Quote Quote  
  2. Originally Posted by justinrye View Post
    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).
    Quote Quote  
  3. " 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
    Quote Quote  
  4. Banned
    Join Date
    Oct 2014
    Location
    Northern California
    Search PM
    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.
    Quote Quote  
  5. I'm a Super Moderator johns0's Avatar
    Join Date
    Jun 2002
    Location
    canada
    Search Comp PM
    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.
    Quote Quote  
  6. 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).
    Stopping development until someone save me from poverty or get me out of Hong Kong...
    Twitter @MaverickTse
    Quote Quote  
  7. Banned
    Join Date
    Oct 2014
    Location
    Northern California
    Search PM
    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)
    Quote Quote  
  8. 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
    Quote Quote  
  9. Banned
    Join Date
    Oct 2014
    Location
    Northern California
    Search PM
    Originally Posted by poisondeathray View Post
    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.
    Quote Quote  
  10. 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


    Originally Posted by newpball View Post
    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
    Quote Quote  
  11. 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
    Quote Quote  
  12. Originally Posted by poisondeathray View Post
    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.
    Quote Quote