GPU encoding considered not ready for prime time

[jman98]

Quite a few posts here have been all gaga about doing GPU encoding to speed things up. Here's a recent article that suggests that GPU encoding is not yet ready for prime time unless you value time over quality.
http://www.extremetech.com/computing/128681-the-wretched-state-of-gpu-transcoding

[mh2360]

GPU encoding is fast and can produce decent results, as long as you use a high enough bitrate. Of course using a higher bitrate kind of defeats the purpose of using a format such as H.264.

So far I have yet to find a GPU encoder that will produce anything close to the quality of x264 at lower bitrates.

[fritzi93]

Thanks for the link.

So apparently it's still no contest if one cares about quality, as do most members here. Any of the free front ends using the x264 encoder beats hell out of GPU encoding. Put your money into a fast multi-core processor instead of a high end video card and GPU encoding payware; that's the way to shorten encoding times.

[MOVIEGEEK]

Put your money into a fast multi-core processor instead of a high end video card and GPU encoding payware; that's the way to shorten encoding times.

Multi-core is the way to go, my AMD A6 quad-core will encode three times faster than my old P4 single-core. I have to hand it to the maker of DVDShrink, he optimized the program for multi-cores because it blazing fast now. Unfortunately my old Ulead VideoStudio program is not multi-core optimized. Handbrake is also blazing fast on multi-core CPU's, the author of the article is spot on.

[jagabo]

If you have a quad core or better CPU x264 with the veryfast or ultrafast preset is faster and delivers better quality at lower bitrates than the GPU encoders.

[poisondeathray]

If you have a quad core or better CPU x264 with the veryfast or ultrafast preset is faster and delivers better quality at lower bitrates than the GPU encoders.

Is that still true for IB quicksync in terms of speed ? It's supposed to be about 50% faster than SB, but CPU is only about 0-5% faster from SB=>IB for software encoding . That should be enough to put it over software x264 encoding (in terms of speed only)

I haven't seen any in depth reviews of IB quicksync comparing quality vs. speed yet

[Nelson37]

Interesting that the article makes one clear exception to that issue, with MediaCoder. They do not offer much useful info on it, however.

Personally, I tried BadaBoom and quality was awful. Mediacoder was much more promising, though the interface is somewhat glitchy. Very fast, produces fully usable output, framerates OK. The quality is tweakable and can be quite good. Pretty much exactly what the article said.

What really surprises me is that no one has done a really good breakdown or guide on this prog. Very little info on what the various settings do, how accurate bitrate control is, etc.

[jagabo]

Yes, Ivy Bridge's Quick Sync is probably faster than a quad core i5 or i7. The 8 thread hyperthreaded i7's CPU rendering might sill be faster. IB's GPU rendering quality doesn't seem to have improved much from the little I've seen.

[olyteddy]

Yes, Ivy Bridge's Quick Sync is probably faster than a quad core i5 or i7. The 8 thread hyperthreaded i7's CPU rendering might sill be faster. IB's GPU rendering quality doesn't seem to have improved much from the little I've seen.

Quite a bit faster according to this: http://club.myce.com/f7/3770k-vs-3770s-327174/#post2633974

[edDV]

If you have a quad core or better CPU x264 with the veryfast or ultrafast preset is faster and delivers better quality at lower bitrates than the GPU encoders.

Is that still true for IB quicksync in terms of speed ? It's supposed to be about 50% faster than SB, but CPU is only about 0-5% faster from SB=>IB for software encoding . That should be enough to put it over software x264 encoding (in terms of speed only)

I haven't seen any in depth reviews of IB quicksync comparing quality vs. speed yet

I thought all the Adobe/Sony GPU acceleration was about speeding the FX preview, not the final encode.

[poisondeathray]

If you have a quad core or better CPU x264 with the veryfast or ultrafast preset is faster and delivers better quality at lower bitrates than the GPU encoders.

Is that still true for IB quicksync in terms of speed ? It's supposed to be about 50% faster than SB, but CPU is only about 0-5% faster from SB=>IB for software encoding . That should be enough to put it over software x264 encoding (in terms of speed only)

I haven't seen any in depth reviews of IB quicksync comparing quality vs. speed yet

I thought all the Adobe/Sony GPU acceleration was about speeding the FX preview, not the final encode.

That's correct - Adobe/Sony NLE's don't use Intel QuickSync. Only programs like Cyberlink Mediaexpresso, a few others

[mammo1789]

I must say I am on the opposite side. Today's GPU, s are the most advanced and complex chips and are brutally powerful, and if you consider paralleled processing with 1000 ( and more "cores"), coupled with ultra fast memories ( 2-4gb ) on the board which are more than 3 times faster than regular ddr 3, working beyond 1ghz mark than you certainly have heavy weight machine that can clean floors with any cpu of today (and future ?) world ( from hardware point of view ).

The problem is that software developers are progressing very slowly ( think the time it needed the software developers to switch to gpu hardware h264 decoding and how mainstream gpu can beat beasty cpu in that task now )main problem is also the complexity of software platforms from the hardware producers nvidia and ati ( cuda and stream ), and now intel software must catch up.
Even if it catches many of the developers are forgetting ( or they now so far ) to make clean fast ( most importantly stable ) software that can use the hardware in the right way because hardware without proper software is just metal junk.

[steptoe]

Without getting too technical, a lot of programmers say the maths side of GPU instructions just can't match CPU math instructions as they were never designed for the complexities and math intensive code needed for video encoding. They were designed for shifting vast quantities of data around and let the CPU handle the hard part


Surely just using the sheer brute power of the GPU compared to the CPU can overcome what is lost in writing equivalent GPU code to match certain CPU instructions

Off topic, but if it could be done to compile the old BASIC programs to assembler code using standard instruction sets why not for CPU instructions. Does nobody use assembler anymore or use c++ entirely and let the compiler do the work

[jagabo]

I must say I am on the opposite side. Today's GPU, s are the most advanced and complex chips and are brutally powerful, and if you consider paralleled processing with 1000 ( and more "cores"), coupled with ultra fast memories ( 2-4gb ) on the board which are more than 3 times faster than regular ddr 3, working beyond 1ghz mark than you certainly have heavy weight machine that can clean floors with any cpu of today (and future ?) world ( from hardware point of view ).

The problem is that software developers are progressing very slowly ( think the time it needed the software developers to switch to gpu hardware h264 decoding and how mainstream gpu can beat beasty cpu in that task now )main problem is also the complexity of software platforms from the hardware producers nvidia and ati ( cuda and stream ), and now intel software must catch up.
Even if it catches many of the developers are forgetting ( or they now so far ) to make clean fast ( most importantly stable ) software that can use the hardware in the right way because hardware without proper software is just metal junk.

So what you're saying is "GPU encoding considered not ready for prime time"?

[mammo1789]

I will also try not to go too much technical

Without getting too technical, a lot of programmers say the maths side of GPU instructions just can't match CPU math instructions as they were never designed for the complexities and math intensive code needed for video encoding. They were designed for shifting vast quantities of data around and let the CPU handle the hard part

I can't see this as true because modern gpu,s have programmable cores that can do anything that regular cpu cores can do and more, even intel in 2010 admitted that nvidia gpu's are "slightly"( meaning 14 times and not 100 as claimed by nvidia ) faster than their cpu i7 doing math work by the way, Certain type of algorithms (graphics processing, linear algebra, video encoding etc) can be easily parallelised on such huge number of cores and from then the gpus progressed much faster than cpu's even further. So you see math code needed for video encoding gpu's can easily crash it and by doing in parallel processing with huge number of "cores"which is what started from supercomputers of last century as a standard, when we were using puny one core cpus.
http://blogs.nvidia.com/2010/06/gpus-are-only-up-to-14-times-faster-than-cpus-says-intel/

and very in depth compassion in 2011 http://www.behardware.com/articles/828-1/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-str...-and-x264.html

The ratio between the raw computational powers of a 8800GT card and one Xeon 5120 CPU core is less than 30 to 40 times. Now, assume both GPU and CPU programs have same performance ratio (performance/peak raw power), then your new GPU program will be 30 to 40 times faster than CPU program. Based on the fact that a multi-thread program is harder to reach the same performance ration as a single-thread program, the gain should be even smaller.

from one knowing engineer

O very interesting commercials of the time when 3dfx was number one in the gpu world http://www.youtube.com/watch?v=DmaYH1F6kho http://www.youtube.com/watch?v=JIOYoZGoXsw
http://www.youtube.com/watch?v=ldiYYJNnQUk&feature=related

So what you're saying is "GPU encoding considered not ready for prime time"?

I'm saying it is ( from hardware stand ) and will be very soon from software be patient

[jagabo]

So what you're saying is "GPU encoding considered not ready for prime time"?

I'm saying it is ( from hardware stand ) and will be very soon from software be patient

It depends on what you mean by "very soon". If you mean the next several months, I doubt it. Only ATI seems to have made any improvements in the last three years. And they've only gone from pitiful to poor. Nobody has moved much beyond the proof-of-concept stage. And nobody seems to be spending time on it.

[Noahtuck]

Okay, we won't go into the difference of what the title of this thread is,

GPU encoding considered not ready for prime time

And the title of the article you linked to,

The wretched state of GPU transcoding

And "Re-Encoding"....

And the first sentence of the article,

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.

Like the program has nothing to do with "wildly varying quality and size"

And I did not read the entire article yet so maybe we are talking about encoding to another or smaller format ?

But one thing I have discovered over the last week......

When I pulled one of my 2 GTX 560's that i was running in SLI out of my main system to test another system, my re-encoding times from a BD50 to a BD25 slowed down by a good amount of time using BDRB.
And That is using "Highest (Very Slow) 2 pass encoding.

Granted when going from 9 hours to 11 hours, yes that 2 hour difference is not a big difference yet it is...

And no, I have seen no noticeable difference between the two on my 46" 1080p LED.

[mammo1789]

The thing is a heard that there is much pressure from the community to the x264 project to be able to start using some sort of gpu encoding to speed up ( although i agree that it is fast already especially on the fast settings using quad core). All big players started using gpu as assisted or pure video encoding ( adobe, sony, cyberlink , pegasys tmpgenc and others ), but the problem is that all of them focus only on h264 as standard future codec (and cyberlink even on mpeg2 ), and basically on dumped presets for devices like mobile or tablets ( i guess the market is asking for it ).

Also gpu proved very helpful in video filtering ( especially in noise reduction look at new version from neatvideo and you will see what I am talking about ( and the quality is the same with or without gpu so there is nothing different there also in tmpgenc i don't see difference in quality but i see allot of it in speed), and also in premiere and sony vegas where in hd material cpu ( especially single core and dual core ) chokes. Not to talk about a lot of avisynth filters where gpu is making it faster ( some of them many times faster)

It depends on what you mean by "very soon". If you mean the next several months, I doubt it. Only ATI seems to have made any improvements in the last three years. And they've only gone from pitiful to poor. Nobody has moved much beyond the proof-of-concept stage. And nobody seems to be spending time on it.

well my friend if you consider commercial part of success then Nvidia sadly is miles ahead with their cuda in front of ati. and if we consider the title then yes the prime time ( used by all major players ) is already here. But I agree with you on many points.

Look for instance Direct X version 11 is with us ( from hardware and OS point) long time with all its benefits for games, and yet game developers some of them AA titles are still using oldy Direct X 9 and "don't give up" because they are afraid of the future or are lazy or don't know how to do it properly. Is that Direct X fault? no. So I think that developers are also to be blamed for the slow of the process of moving over to GPU for video encoding taks. I myself have many times posted on the neatvideo forum in the past of requesting the gpu assistance in the process explaining why it will benefit in speed. And the answers were that the cuda is very difficult to implement and that cpu is better suited, but we saw that it is not like that and they had to admit that.

Why I am very optimistic and say very soon ( no I dont meant months ) because now that all major players had started implementing gpu encoding ( like decoding in the past and now everybody is using it ) everybody will follow.

PS By the way did you watched the commercials It reminds me of the good old times

[Selur]

getting a bit offtopic is there a free alternative to DGDecNV out there? (a tool that allows to decode H.264/MPEG-2/MPEG-4 ASP content and output to standard out or feed it in another way to x264? in case of DGDecNV, avisynth is needed)