Forgot your password?
typodupeerror
Graphics Software Technology

The Wretched State of GPU Transcoding 158

Posted by Soulskill
from the things-that-should-work-better-in-2012 dept.
MrSeb writes "This story began as an investigation into why Cyberlink's Media Espresso software produced video files of wildly varying quality and size depending on which GPU was used for the task. It then expanded into a comparison of several alternate solutions. Our goal was to find a program that would encode at a reasonably high quality level (~1GB per hour was the target) and require a minimal level of expertise from the user. The conclusion, after weeks of work and going blind staring at enlarged images, is that the state of 'consumer' GPU transcoding is still a long, long way from prime time use. In short, it's simply not worth using the GPU to accelerate your video transcodes; it's much better to simply use Handbrake, which uses your CPU."
This discussion has been archived. No new comments can be posted.

The Wretched State of GPU Transcoding

Comments Filter:
  • by carlhaagen (1021273) on Tuesday May 08, 2012 @07:12PM (#39935581)
    ...since the results of OpenCL code is static across GPUs rather than being an arbitrary output.
  • by PopeRatzo (965947) on Tuesday May 08, 2012 @07:34PM (#39935763) Homepage Journal

    The GPU isn't meant to do everything.

    But since "Graphics Processing" is part of their name, wouldn't you expect them to at least do that?

    Especially considering the price of high-end GPUs is getting up there compared to high-end CPUs.

  • by TD-Linux (1295697) on Tuesday May 08, 2012 @08:19PM (#39936187)
    Because behind the scenes your "encoder" program is actually using several different encoders. Generally the encoder has to be custom written specifically for the specialized GPU hardware it is targeting.
  • by Nemyst (1383049) on Tuesday May 08, 2012 @08:23PM (#39936215) Homepage

    You mean yesterday's, surely. Rasterizers still are required obviously but GPUs nowadays are very much shader-based and not so much polygon-centric (we're far from T&L). They're built to efficiently process short but otherwise arbitrary floating-point operation sequences in extremely parallel scenarii.

  • Re:Welp (Score:4, Interesting)

    by gnasher719 (869701) on Tuesday May 08, 2012 @09:01PM (#39936615)

    Pity the Handbrake devs are dickwads.

    1. It's not funny.

    2. They make an excellent bit of software that I have been using for free for years. Unless you helped them out you can't complain.

    3. The guys creating Handbrake and the guys making video encoders are not the same people, so your rant is misdirected.

    4. I mailed them two suggestions for improvements, and both got implemented. Now this may be because my suggestions were the kind of things that were (a) genuine improvements and (b) interesting for the developer and therefore would have been implemented anyway, but in my experience they are responsive to the right kind of suggestions.

  • by nabsltd (1313397) on Tuesday May 08, 2012 @09:09PM (#39936681)

    No, but it is using it for post-processing such as deinterlacing, noise reduction, etc.

    I use the GPU to do FFT noise reduction before some encodes, and it's essentially "free" as it's faster than the 8 threads used by x264 for encoding.

  • by Dputiger (561114) on Tuesday May 08, 2012 @09:19PM (#39936767)

    Fuzzy,

    You pretty much nailed my problem with the output. :P That's the reason why Arcsoft, with compatibility problems, ultimately ranked above Cyberlink. Arcsoft doesn't do very good work on the Radeon 7950 and it can't handle CUDA, but it at least gets something right. Quick Sync video is very good.

    Cyberlink got nothing right anywhere. And it's the program most-often recommended to reviewers as a benchmark when we want to review GPU encoding.

  • by nabsltd (1313397) on Tuesday May 08, 2012 @09:29PM (#39936857)

    That's why video professionals and tv stations rely on hardware based transcoding, and this solutions tend to be expensive.

    x264 can encode 1080p in realtime on a modern Intel CPUs (Sandy Bridge, etc.) with pretty much as good a quality for the same bitrate as most hardware solutions. For non-HD, x264 just smokes hardware, as it can do better than realtime encodes at very high quality on those same CPUs.

  • by Anonymous Coward on Wednesday May 09, 2012 @12:04AM (#39937727)

    Shill paper? I guess you prefer your papers sponsored by Nvidia, showing a device of no more than 5x memory bandwidth improvement and no more than 5x flops improvements getting 1000x peformance increases? *Those are shill papers*. Today the situation is slightly changed, but not hugely.

    i7-3770K makes 112 DP GFLOPS and 25.6GB/s memory bandwidth.
    5970 makes 928 DP GFLOPS and 256GB/s memory bandwidth.

    So they're both within 10x. It makes 4.64 SP TFLOPS, which is about 20x the SP FLOPS.

    Still not going to get 100x performance increases, are you? 1000x? Pfft

UNIX is many things to many people, but it's never been everything to anybody.

Working...