The Wretched State of GPU Transcoding 158
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."
Lack of standards, quality. (Score:1)
I've heard from a lot of sources that the quality of output from various GPU accelerated video encoding schemes almost invariably lacks when compared to an established, known good CPU based video encoding scheme. When the GPU encoders can match quality, will they still be fast? Are they just cheating now? What gives?
Re: (Score:2, Informative)
Yes, they are cheating. That is exactly how they are getting it to be so fast.
Re: (Score:3)
has anyone tried Badaboom?
Re:Lack of standards, quality. (Score:5, Informative)
has anyone tried Badaboom?
Not much point. It's been discontinued.
Re:Lack of standards, quality. (Score:5, Insightful)
What I don't understand is how this happens. Why would the same calculation get different results on different GPUs? Are they doing the math incorrectly?
Re:Lack of standards, quality. (Score:5, Informative)
Re: (Score:3)
Re:Lack of standards, quality. (Score:4, Informative)
And remember that this is not necessarily lower quality! There are valid reasons for not following the complexities of IEEE floating point if you have no need for portability.
Re: (Score:3)
Evem with IEEE things aren't that simple: http://randomascii.wordpress.com/2012/03/21/intermediate-floating-point-precision/ [wordpress.com]
Re:Lack of standards, quality. (Score:5, Informative)
Hint: Not all GPUs have IEEE FP compliant math. Often they break the standard, or do something else altogether just to improve performance.
I can't speak for ATI, but actually all FP32 math on Nvidia architectures for many generations now has been IEEE compliant, excluding NAN and -inf +inf and exception handling cases, and except for their hardware sin, cos, log implementations, and except when using the fused multiply add instruction (though the last one you could actually get around by using special compiler intrinsics to avoid the fusing).
Re: (Score:3)
I agree it would be pathetic if this were because someone passed -ffast-math or whatever it
Re:Lack of standards, quality. (Score:4, Interesting)
Re:Lack of standards, quality. (Score:5, Informative)
This has largely ceased to present a problem, thanks to OpenCL.
GPU code no longer needs to run as custom-written shaders targetting 20 different platforms. One program, written in fairly straightforward C, will run on just about any modern platform. And it will do so at speeds that absolutely dwarf a CPU - The Radeon x9yy cards (for x>=5) easily crush a modern CPU at OpenCL code by a factor of a thousand. The x8yy cards still perform admirably, over three hundred to one. For NVidia, the Tesla series do well, while the GX... Well, ten to fifty times faster doesn't exactly suck...
The real problem here? Most people have really crappy GPUs. Even compared to the $100 card range, your GPU sucks ass, and hard. And you can't really blame people, because honestly, even modern IGPs will run just about anything fairly well, so why would you pay for more?
But don't blame the GPUs, or the concept in general. If you target OpenCL and the user has a halfway decent modern GPU, it will give consistent, reliable results, and will blow away your CPU many times over.
Re:Lack of standards, quality. (Score:5, Insightful)
but, at least in this context, speed is nearly irrelevant because it fails at the task at hand, producing high quality video.
who cares how fast it completes a task if it's failing? Nobody gives little jimmy props when he finishes the hour-long test in 5 minutes but scores a 37% on it.
Re:Lack of standards, quality. (Score:4, Informative)
I agree that presents something of a problem for current implementations; the concept of GPU transcoding doesn't fail, however. Only the fact that those currently pushing it have tried to show at least modest gains for everbody - meaning those with massively inappropriate hardware - has made it such an abysmal failure to date.
To repeat my earlier post, if you target an OpenCL-capable GPU, you will get consistent results; and if you target a card with a reasonable number of compute units, (58xx/59xx/68xx/69xx/tesla), you'll see performance far beyond what a modern CPU can give.
Does that make GPU transcoding the best choice for the general public at present? No! But for those with the hardware, the comparison counts as literally laughable.
Re: (Score:3)
I've got a first generation fermi-based GTX 470. Considering that, at the time, the parallel compute power was the big halo selling point of the new fermi gpu, I was very underwhelmed when I finally found some software that would actually use it. I saw speedups of only about 3x or so above and beyond my core 2 duo (only a 2-core!) e8400, and the quality was abysmal in comparison
I'm not saying that GPU transcoding -shouldn't- be a better option than cpu transcoding, it completely should be, but current imple
Re: (Score:2)
One source of comparative CPU benchmarks is here http://www.cpubenchmark [cpubenchmark.net]
assume 200W power consumption (Score:2)
Around here running that 24x7 would cost ~ $200. You'd need to run it for several years to pay for the cost of a new system.
Re: (Score:2)
Between my wife and I, we have 7 computers. dedicating one to transcoding isn't a big deal. it's also our file server, so it's on 24/7 anyway.
I transcode 2-5 videos at a time usually. once every few weeks/months.
Re: (Score:3)
Props to Jimmy, he got 37% right in 8.3% of the time, and even more credit since I assume not everyone could get a 100% in an hour, or what would be the point of the test.
Re: (Score:2)
I think of it with a different analogy. Instead of little Jimmy and the test, I prefer the BK Lounge metaphor:
Burger King manages to hand you "food" in 11 Seconds, compared to Shari's (or wherever, insert a middle-of-the-road place here) 20 minutes,
The "food" is consistently inedible at BK, whereas at Shari's or wherever won't make you sick after bite 2.
The GPGPU is shitty at video transcoding, but boy howdy it's fast. And that's completely beside the point.
What good is a "burger" in 11 seconds if you can
Re: (Score:2)
Re: (Score:2)
Sorry to break this to you, but I write OpenCL, and yes, it really does work that simply.
Now, I will readily admit that getting every last drop of performance out of a given GPU still requires hand-tuning your code to target the specifics of its architecture; But you could say the same for CPUs, as well.
Don't even dare to think that nVidia and ATI chips like the same kinds of optimizations - they don't.
Very true -
Re: (Score:3)
There are probably two issues here, but the kind of calculations we're talking about here are floating-point calculations. And as every programmer should know floating-point calculations done by different CPUs or GPUs don't give you consistent results: http://developers.slashdot.org/story/10/05/02/1427214/what-every-programmer-should-know-about-floating-point-arithmetic [slashdot.org]
Also, we're talking about GPUs here. GPUs aren't even designed to give you IEEE standard results. Instead they're designed to give approxima
Re: (Score:2)
It is true that code can be compiled using libraries that deliberately compromise the algorithms for transcendental functions to make them faster, but that's 100% the programmer's fault.
Re:Lack of standards, quality. (Score:5, Informative)
Because they're not using the same encode paths.
All 3 hardware encode paths - Intel QuickSync, AMD AVIVO, and NVIDIA's CUDA video encoder - are largely black boxes. Programs such as MediaEspresso are basically passing off a video stream to the device along with some parameters and hoping the encoder doesn't screw things up too badly. Each one is going to be optimized differently, be it for speed, more aggressive deblocking, etc. These are decisions built into the encoder and cannot be completely controlled by the application calling the hardware. And you have further complexities such as the fact that only Intel's QuickSync has a hardware CABAC encoder, while AMD and NV do it in software (and poorly since it doesn't parallelize well).
Or to put this another way, everyone has their own idea on what the best way is to encode H.264 video and what kind of speed/quality tradeoff is appropriate, and that's why everything looks different.
Really depends (Score:2)
The real problem especially when
Re: (Score:2)
Because it's not the same calculation. All they must do is succeed in outputting h264 compliant files, there are many h264 compliant files that look something like the original source video. Different methods of encoding produce results closer or further from the original, at higher or lower file sizes.
Re: (Score:2, Insightful)
Nice shill paper you got there... Of course a paper made by the throughput computing lab and the Intel architecture group (both Intel corp) will advocate there's not much speedup by a GPU when compared to a CPU.
The big thing to note is that with a GPU, you have to do what you did when working with the original SSE (intel...) instruction set on regular CPU's, FP16 numbers will not have a significant amount of precision, so you must take that into account when programming with that instruction set in mind. I
Re: (Score:2, Interesting)
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
Re: (Score:2)
A properly written GPU program is ideally never relying on main memory except to keep a buffer filled - it feeds all its FPUs from shared memory, which can deliver an aggregate bandwidth of TBps to about 750KB (total) of space in a good card.
And the moral of the Story is... (Score:4, Informative)
The GPU isn't meant to do everything. If it were, there wouldn't be a CPU. Considering the hatred that was poured on Quicksync here, and that Quicksync still produces better quality Transcodes than GPUs while being substantially faster, I don't think we'll be seeing the end of CPU transcoding anytime soon.
Re: (Score:2)
Re:And the moral of the Story is... (Score:5, Informative)
The quick sync hardware is part of the IGP block but it is specialized hardware specifically geared towards transcoding. For example, it is not using the main GPU pipeline and shader hardware to do the transcoding.
Re: (Score:3)
Yeah now go look at the heaping scorn that was heaped on the Intel rep when he approached the x.264 guys way late in development. Had they been smart enough to come forward sooner we might have gotten accelerated instructions the x.264 guys would have used - not so now it seems. :-(
Re:And the moral of the Story is... (Score:5, Informative)
Re: (Score:2)
Except even when you compare the fixed function H.264 encoders to x264 at those exact settings, x264 still dominates.
Re: (Score:3)
That's my point though. Fixed function encoders won't be able to match x264 because of a lack of flexibility. They can't be optimized for specific niches, they need to be generalist in order to be decent at everything since the hardware can't be changed.
Also let's be clear (Score:5, Informative)
That while the x264 guys aren't wrong to want to keep working on a software encoder that is tweakable, there is nothing wrong with a fixed function hardware encoder for some tasks. Sometimes, speed is what you want and "good enough" is, well, good enough.
Like at work I edit instructional videos for our website (I work at a university) using Vegas. I use its internal H.264 encoders, which can be accelerated using the GPU. They are quite zippy, I can generally get a realtime or better encode, even when there is a decent amount of shit going on in the video that needs to be processed (remember that Vegas isn't for video conversion, I'm doing editing, effects, that kind of thing).
Now the result is not up to x264 quality, per bit. I could get better quality by mucking around setting up an avisynth frameserver and having x264 do the encoding using some tweaked settings for high quality. However it would be much slower.
Not worth it. I'll just encoder a reasonably high bitrate video. It is getting fed to Youtube anyhow, so there's a limit to how good it is going to look. The faster hardware assisted encode speeds are worth it.
If I was mastering a Blu-ray? Ya I might do the final encode to go off to fabrication with x264 (actually more likely an expensive commercial solution that can generate mastering compliant bitstreams). Spend the extra time to get it as quality as possible because of all the other work and because it could actually be noticable.
There is room for both approaches.
Re: (Score:2)
I take issue with your fact. I say you have not tested it against Sony's encoder built in to Vegas (which isn't QuickSync, it is a hybrid CPU, CUDA, and OpenCL encoder). If you want me to believe that x264 is faster and better you need to show me a test that shows:
1) Settings with x264 that produces a render rate equal to or greater than the rate that the Sony AVC encoder does.
2) That the quality is superior, in picture and video comparisons.
3) That the resulting file size is the rough same (within 10% say)
Re: (Score:2)
Actually they seemed to have some ideas for functions that were bound and could be accelerated. However Intel contacted them having apparently already decided what instructions they were going to accelerate and they weren't useful. Additionally, as I recall, shortly after contacting the development team Intel sort of let on that these guys were somehow on board when in fact they were really only just being contacted and weren't. things didn't go really well after that and I couldn't find any more contact on
Re: (Score:2)
No, but it is using it for post-processing such as deinterlacing, noise reduction, etc. The shader pipeline is still involved whenever you need to decode something, be it for QuickSync or for just playing back a video on a PC.*
*Consequently this is why Intel can't quite match AMD or NV in video playback quality; they lack the shader performance to do as much resource intensive processing
Re:And the moral of the Story is... (Score:4, Interesting)
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.
Re:And the moral of the Story is... (Score:5, Informative)
Quick Sync uses dedicated HW on the die. Intel's solution that uses their GPU is called Clear Video.
Re: (Score:2)
Re:And the moral of the Story is... (Score:5, Insightful)
Actually, recent GPUs *were* meant to do exactly this type of thing, and have been marketed by Nvidia and ATI heavily for this purpose. Of course there needs to be a CPU as well. The CPU runs the operating system and application code, and offloads very specific, parallelizable work to the GPU. This sort of architecture has existed almost as long as modern CPUs have existed.
And Quick Sync is even less of a general purpose CPU solution than using a GPU. Quick Sync uses dedicated application specific hardware on the die to do its encoding.
Re:And the moral of the Story is... (Score:4, Interesting)
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.
Re: (Score:1)
Today's "graphics processing units" are essentially designed to render a large number of triangles on a screen in a highly efficient way. If any other graphics operation is thrown at them, they may simply not be designed to execute it well. Just because it has "graphics" in the name it doesn't mean that it can handle every graphics technology perfectly well.
Re:And the moral of the Story is... (Score:4, Interesting)
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:And the moral of the Story is... (Score:5, Insightful)
Well see, that's the thing. A GPU is better suited to some kinds of massively parallel tasks, like video encoding. After all, you're applying various matrix transforms to an image, with a bunch of funky floating point math to whittle all that transformed data down to its most significant/perceptible bits. GPUs are supposed to be really really good at this sort of thing.
My hunch is that the problems we're seeing are caused by two big issues:
1. lack of standardization across GPU processing technologies. CUDA vs OpenCL vs Quicksync, and a bunch of tag-alongs too. Each one was designed around a particular GPU architecture, so porting programs between them is non-trivial.
2. lack of expertise in GPU programming. Let's be fair here: GPUs are a drastically different architecture than any PC or embedded platform we're used to programming. While I could follow specs and write an MPEG or H.264 encoder in any high-level language in a fairly straight-forward manner, I can't even begin to envision how I would convert that linear code into a massively parallel algorithm running on hundreds of dumbed-down shader processors. It's not at all like a conventional cluster, because shaders have very limited instruction sets, little memory but extremely fast interconnects. We have a hard enough time making CPU encoders scale to 4 or 8 cores, this requires some serious out-of-the-box thinking to pull off.
Moving to a GPU virtually requires starting over from scratch. This is a set of constraints that are very foreign to the transcoding world, where the accepted trend was to use ever-increasing amounts of cheaply available CPU and memory, with extensively configurable code paths. The potential is there, but it will take time for the hardware, APIs and developer skills to converge. GPU transcoding should be seen as a novelty for now, just like CPU encoding was 15 years ago when ripping a DVD was extremely error-prone and time-consuming. If you want a quick, low quality transcode, the GPU is your friend. If you're expecting broadcast-quality encodes, you're gonna have to wait a few years for this niche to grow and mature.
Re:And the moral of the Story is... (Score:5, Insightful)
Expecting super-zippy magic-optimized speedups on all the architectures tested would be the mark of expecting serious maturity. Expecting a commercially released, GPU-vendor-recommended, encoding package to manage things like "Don't produce an h264 lossy-compressed file substantially larger than the DVD rip source file" and "Please don't convert a 24FPS video to 30FPS for no reason on half the architectures tested" seems much more reasonable.
I can imagine that the subtle horrors of the probably-makes-the-IEEE-cry differences in floating point implementations, or their ilk, might make producing identical encoded outputs across architectures impossible; but these packages appear to be flunking basic sanity checks, even in the parts of the program that are presumably handled on the CPU(when a substantial portion of iPhone 4S handsets are 16GB devices, letting the 'iPhone 4S' preset return a 22GB file while whistling innocently seems like a bad plan...)
Re:And the moral of the Story is... (Score:4, Interesting)
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.
Re: (Score:2)
A GPU is better suited to some kinds of massively parallel tasks, like video encoding. After all, you're applying various matrix transforms to an image, with a bunch of funky floating point math to whittle all that transformed data down to its most significant/perceptible bits. GPUs are supposed to be really really good at this sort of thing.
And there's your problem.
An h.264 encoder takes a frame of video and splits it up into 16x16 pixel macroblocks. Each macroblock is heavily dependent on those surrounding it (spatially and temporally). For an intra block, a prediction of the content of the current block is made using the decoded content of the top and left blocks. For inter blocks, a previous frame is used as a reference. The decoder has no idea what the original source file looked like, so any predictions made in the encoding process must b
Or just use an OpenCL-powered encoder... (Score:4, Interesting)
Re:Or just use an OpenCL-powered encoder... (Score:5, Informative)
Only the more modern GPU support it. And of those, there are still different levels of support. Even if it's supported, you would probably get much better perf on an nvidia card by using cuda for example. So in today's world, you can't just use an onpencl-powered encoder, it depends on what hardware you have.
Whoa there. You're plainly wrong. (Score:2)
CUDA was released, supported by NVIDIA GPUs, in early 2007. The first OpenCL specification was not released until late 2008 (OpenCL has not been around for 4 years, as you claim). As for which is more popular, I'm afraid that you have this backwards too. The dominant market force for GPU computing is supercomputing. How many of the top 5 supercomputers used AMD GPUs? Zero. How many use NVIDIA GPUs? Three. And they're all using CUDA because it's more feature rich---it can do fancy things like direct
Does anyone have editors anymore? (Score:3)
Re:Does anyone have editors anymore? (Score:5, Informative)
As the author of the story, that's an error that slipped past in formatting. I'm uploading the proper graph right after I hit "Reply" on this.
Re: (Score:2)
GPUs will be great once we ... (Score:1)
Re: (Score:2)
Maybe by then, "traditional" CPUs will be different from the ones we have right now.
Re: (Score:2)
Encoding should be trivial to paralellize, you just cut up a movie to a sequence of n clips and encode them independently.
Re: (Score:2)
Encoding should be trivial to paralellize, you just cut up a movie to a sequence of n clips and encode them independently.
Because the structure of modern codecs is based on Groups of Pictures (GOP), you'd have to run two passes on the video, with the first pass determining where the keyframes go. Although this is commonly done by people who don't have a good understanding of video encoding, the more efficient way is to just run a single pass using a constant quality (which is not the same as a constant quantizer). Then, on that single pass, you parallelize the operations on each frame. This also results in less disk thrashi
Re: (Score:2)
What about slice-based parallel processing?
Correct me if I'm wrong, (I wouldn't be surprised if it turns out I am...) but doesn't x264 have an option to do slice-based parallel processing? As I understand it, if there are 4 running threads, each frame is chopped into four quadrants with a little edge room buffer in each slice, then independently encoded, then glued back together at the other end? That's how I remember that option being described in some forum or other. Not the standard multi-threading, b
Re: (Score:2)
What about slice-based parallel processing?
According to the wiki [project357.com], you're still better off using normal multithreading even if you are using slices (as you must if you are encoding for Blu-Ray).
Re: (Score:2)
2-pass let's you determine your final filesize (IMO, the reason one recodes)
That's a weird IMO. Certainly 2-pass is the best way to go if you care about exact filesize, but that's not what most people care about. They care about having video that will play back so they can watch and hear it, and the primary reason anyone I know recodes is to convert to a format that they can actually play (generally for ipad/smartphone or ps3 playback).
Re: (Score:2)
Single pass has always produced garbage results for me unless you knock the bitrate WAY up, but why even bother recoding, then?
Two-pass x264 with an average bitrate just has the first pass compute the CRF value that will give you the target bitrate. After just a few encodes of similar material, all the rest of your encodes can use one-pass with the CRF set to near the value that was computed for the two-pass encodes.
One of the things this does is that every movie gets exactly the bitrate it deserves, so easy to compress (less movement, less film grain, etc.) movies get a lot lower bitrate at the same CRF value. This is how I end
Single Page Version of Article (Score:5, Informative)
The real problem... (Score:2)
Explain to me how its the GPU's fault (Score:2)
Re: (Score:2)
The problem with transcoding is that it exists at all. Strongarm the holdout encoders into using h264 or mp4v with mp4 wrappers, and transcoding will be like... well, like anything no one does anymore.
There will always be transcoding, since you can't fit the 20GB H.264 stream from a Blu-Ray on a phone. And, why would you want to? Resize the 1920x1080 to 800x480 or so, and it will look great on every phone.
For tablets or other devices with more resolution, you still don't need all the bits that most Blu-Ray encodes use. Most are essentially constant bit rate around 25-30Mbps. For movies that are essentially "talking heads" (courtroom dramas like A Few Good Men and Presumed Innocent are the best exampl
Re: (Score:2)
There will always be transcoding, since you can't fit the 20GB H.264 stream from a Blu-Ray on a phone.
You are thinking about this all wrong. You think you own that movie... but you don't, you own a license. That license entitles you to transcode... if you want to go ahead and do work that, chances are, has already been done, and is constantly being done for you by others that create far better quality transcodes. The obtuse talk about how great their hardware is, and how fast they can rip their movies... but the astute keep all their movies backed up on the Internet in every format and resolution imaginable
Re: (Score:2)
> You are thinking about this all wrong. You think you own that movie... but you don't, you own a license.
Your attempt to spread that pro-corporate propaganda simply won't work here. We know better.
Re: (Score:2)
if you want to go ahead and do work that, chances are, has already been done, and is constantly being done for you by others that create far better quality transcodes.
In general, there are two kinds of rips available on torrents: too large so that quality stays high, and really small to fit on phones or similar devices. It's very hard to find something in-between, where you the encode is close to transparent, but as small as possible. Most rips still use two-pass average bitrate mode, which is basically "find the CRF value that gives me this bitrate", which is the wrong way to maintain quality. The right way is to pick a CRF value and let x264 figure out the bitrate n
Re: (Score:2)
I've been transcoding for at least 10 years (and everything but ffmpeg sucks).
For H.264 encoding, ffmpeg just spawns x264, but you don't have the ability to control all x264 options through ffmpeg, so using x264 directly is generally better.
For the life of me, I can't figure out how YIFY does it...
Lots of pre-filtering to remove hard-to-encode detail. Even a relatively gentle temporal smoother can cut bitrates by half on very grainy material, and not affect quality much unless you freeze-frame.
Intel QuickSync is the true winner (Score:1)
Duh. QS is made to do a very specific task (encoding/decoding video) and it can do it super fast at decent quality rates. There's always the tradeoff of quality vs. encoding time. With QS, I can rip an entire 50GB Blu-Ray in 12 minutes to a 1080p MKV @ 8000kbps. It takes about 16 hours doing the same task with a normal x264 encoder such as Handbrake even though the quality is a little bit better. Is it wo
Re: (Score:2)
With QS, I can rip an entire 50GB Blu-Ray in 12 minutes to a 1080p MKV @ 8000kbps. It takes about 16 hours doing the same task with a normal x264 encoder such as Handbrake even though the quality is a little bit better.
Even using the "slower" preset on x264, 1080p encodes take about 3 times as long as the movie, so no more than 8 hours. This is on a slower CPU (since you have QuickSync) than you use, and end up at about 4Mbps
If I used a less-intensive preset, I would get encodes at about the same bitrate as yours, but taking just a little more than the running time of the movie to do it. QuickSync may be even faster, but 3 hours to encode most movies is good enough.
With enough bitrate, anything looks good.
In general, this is true, but very poor encoders can st
Re: (Score:2, Informative)
No, the article says that GPU encoding software runs the gamut from outright awful to simply broken and limited. Quick Sync video is great in Arcsoft, terrible in Cyberlink, unsupported in Xilisoft, and looks decent in MediaCoder. Check the GTX 580's output in Xilisoft for plenty of proof that no, you don't need insane bitrates to create decent-looking output.
Re: (Score:3)
Hardware transcoding, not GPU (Score:1)
That's why video professionals and tv stations rely on hardware based transcoding, and this solutions tend to be expensive. There should be many systems than encode H264 videos really fast, something like this: http://www.blackmagic-design.com/products/teranex/
Re:Hardware transcoding, not GPU (Score:4, Interesting)
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.
Re: (Score:2)
Fascinating. The fact that hardware based transcoding is a disaster is why "professionals" use hardware based transcoding?
That simply makes no sense.
Re: (Score:2)
that it's just all hw.
the point of the article however is that that the state of hw encoding for consumers using their already bought equipment is a mess.
kinda like video decoding using hw was a mess too for so many years and still is on some levels. (vlc being the equivalent of handbrake there).
a company providing shit in both cases? cyberlink - the pinnacle of how to be the number one shipping sw solution for something and being in the bottom 5% of actual use!
Re: (Score:2)
1) Because they're guaranteed real-time, so you can pipe video through and just factor in a set time delay
2) Designed to be robust, so you don't need to worry about overheating, or the encoder choking on a certain bit of video
If
How about DVDFab? (Score:2)
I use DVDFab to rip DVDs using my GPU, and it positively flies. Most 2 hr movies take around 10 minutes to convert to H.264. It doesn't support VBR, but outside of that I've never had trouble with it. The resulting video quality is quite good as well (except with files that need deinterlacing, but that's always a problem). I think the person who wrote the articles just didn't try the right programs.
Re: (Score:2)
Please see real transcoders (Score:3)
Please see Elemental Technologies [elementalt...logies.com] GPU-accelerated H.264 transcodes.
Re: (Score:2)
Considering the article ruled out some software, because it was considered too difficult to use, I suspect Elemental Technologies' software would be ruled out due to cost.
Poor software, not poor GPUs (Score:2)
Surprise, surprise, I have the feeling that most of you haven't actually read the article. The article is not arguing that GPUs are inherently flawed. Also, the article is not an NVIDIA-vs-AMD competition. Rather, the author tests software on each platform. It's the software that is bad, not the GPUs themselves. For instance, the NVIDIA GPU does quite well with Arcsoft and Xilisoft; this wouldn't be possible if GPUs were somehow broken for transcoding. After all, as others have pointed out here, floati
DVDFab and NVidia GTX 560 - Finally! (Score:2)
Using the GPU I get about 70fps, and I've watched about 15 of the movies without noticing any problems at all.
I flat out gave up with trying to support my fricking PS3.
Yeesh - not 600! (Score:2)
Re: (Score:2)
Because it was a review the actual GPU encoders themselves not various frontends to those GPU encoders.
Re: (Score:2)
The review and summary are giving mixed signals then, as I had the same reaction to the article.
If this is a review of the encoders and not the front ends, then why is Handbrake specifically pointed out for ease of use?
Handbrake is only a front end to an encoder that can easily give similar or vastly worse results if you don't know how to use it.
Re: (Score:2)
Mine was a reply to "Because it was a review the actual GPU encoders themselves not various frontends to those GPU encoders." which you and I both seem to disagree with.
That said, I do believe that there are better GPU assisted applications than those tested, such as DVDFab mentioned above.
I'd be very interested to see how it compares using this methodology, but testing every available application could become a full time job.
I have no affiliation with DVDFab, but it comes to mind as a decent encoder well b
Re: (Score:2)
Re: (Score:2)
Getting varied quality from different cards means you're doing something VERY wrong.
Maybe it means you're good at programming one GPU but you're not as good at programming the other. Or if another person did the code for the other GPU, maybe the other person doesn't code as well as you do.
But if all these chips have different instruction sets and APIs, it sounds kinda like saying, "If your program runs slower on iOS than it does on Android, you're doing something very wrong." Maybe. The point is that things were supposed to be getting easier, but apparently they're not.
Re: (Score:3, Informative)
As the author:
Because 3000-word articles with PNGs at ~300K per large image and 100K per preview image aren't fun reading in a single go. There's ~1.5MB of imagery just on the third page . Pages 3-8 have about the same, and that's with the images only loaded as thumbnails.
If you've got a fast net connection, you won't care. If you don't have a fast net connection, loading 16MB of images at once isn't a lot of fun.
Visual quality comparisons are one area where you can't use low-quality JPGs. A 9-page article
Re: (Score:2)
If you've got a fast net connection, you won't care. If you don't have a fast net connection, loading 16MB of images at once isn't a lot of fun.
Speaking of which, can anybody recommend a software package that cleanly implements that "load images upon scrolling near the active viewport" that I see on some sites? It seems like a nice way to do things.
Re:Welp (Score:4, Interesting)
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.
Re:Incompetent Author? (Score:5, Informative)
I set out to test presets. Specifically, I set out to test the presets of software packages which are sold on the purported *strength* of those presets. I say so in the first paragraph:
" 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."
That's why MediaCoder results weren't included.
The entire article came about because Cyberlink's iPhone 4S preset yielded files that were 1.4GB if I used CPU encoding or a GTX 580, and 188MB if I used Quick Sync. That disparity is what I noticed when I went to check encode quality for the initial IVB review.
Can you build custom profiles in CME and create outputs that avoid these problems? You can -- though some options aren't available. That, however, is not the point. If I'm going to build my own custom profiles, I can download a copy of MediaCoder for free and do it with a more powerful piece of software that offers a huge number of options.
I did a review of "Software that claims to automate the GP encode process." I did not do a review of "Can Cyberlink MediaEspresso EVER create a decent image?" Given what I set out to evaluate, my ability to tweak profiles to achieve a satisfactory result is not a valid criteria for my conclusions.