Posted
by
Soulskill
on Tuesday May 08, 2012 @05:57PM
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."

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?

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

The math units on every nVidia card made since at least late 2009, both single and double precision, are ieee754 compliant. The only excuse for it being wrong is that someone deliberately used the __fast non-primitive operations (sqrt/log/exp & friends), which compromise the algorithms used to compute transcendental operations. The exact extent of the compromise is detailed in the back of the nVidia CUDA guide.

I agree it would be pathetic if this were because someone passed -ffast-math or whatever it

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.

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.

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.

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.

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.

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

Maybe I'm missing something... but if it's taking you 36 to 48 hours to transcode a single video, and assuming you can justify dedicating a system to that purpose for such an extended time, wouldn't the power savings you'd get by purchasing a much faster system be worthwhile? I'm guessing that the power draw for a process which takes so long to complete is substantial, and that you aren't intending to transcode only a couple of videos.

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

Thank you. I'm personally getting sick and tired of badly written articles on Parallel Programming discussing CUDA and having to wade through crap before one sharp post discusses OpenCL. OpenCL 1.2 is very robust and we'll be seeing OpenCL 2.0 this August.

I'm sorry to break it to you, but OpenCL is not as simple as you make it out to be.

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.

Every GPU from nVidia for 3 full hardware generations (Since compute architecture 1.3 - 2009 at least, possibly earlier) has had IEEE754 compliant fp32 and fp64 math. I imagine ATI has been compliant for as long also.

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.

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.

CABAC doesn't scale well in massively threaded environments that is true. However there are ways to avoid the issues involved and this really isn't the issue either. It's not the CABAC so much as the bit stream writing for the most part. CABAC scales fine if you parallelize it across slices. Of course no modern encoders make use of multiple slices per field/frame, so it's more of an issue of whether latency is an issue. You can run parallel CABAC encoders by buffering frames.The real problem especially when

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.

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

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.

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.

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.

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.

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.:-(

Let's be clear here: the x264 guys will never be happy. QuickSync, AMD's Video Codec Engine, and NVIDIA's NVENC all use fixed function blocks. They trade flexibility for speed; it's how you get a hardware H.264 encoder down to 2mm2. There are no buttons to press or knobs to tweak and there never will be, because most of the stuff the x264 guys want to adjust is permanently laid down in hardware. The kind of flexibility they demand can only be done in software on a CPU.

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.

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.

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.

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

For example, it is not using the main GPU pipeline and shader hardware to do the transcoding

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

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.

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.

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.

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.

What strikes me as a bad sign is not so much that the GPU transcoding doesn't necessarily produce massive speed improvements; but that the products tested produce overtly broken output in a fair number of not-particularly-esoteric scenarios.

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

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.

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

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.

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

There is a screwed up graph on page two where they use the same graphic twice, and the caption describes aspects of the one that is missing. I really wanted to see the comparison too. You would think in an article of that size and scope someone would be responsible for checking layout as well as copy. It is no wonder we are losing to china. Their English may be worse, but their work ethic and attention to detail is possibly better.

Much obliged then sir. You can also delete my comment on your story at your site then! I posted there as well, not knowing you were watching/. Maybe we do have a chance after all (as long as crusty old cynics like me don't depress everyone too much).

I think that the real benefit of GPUs for transcoding will be seen once people start making new as-yet unimagined encoding schemes that are designed to do data parallel tasks that wouldn't even be considered on a traditional CPU.

I think that the real benefit of GPUs for transcoding will be seen once people start making new as-yet unimagined encoding schemes that are designed to do data parallel tasks that wouldn't even be considered on a traditional CPU.

Maybe by then, "traditional" CPUs will be different from the ones we have right now.

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

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

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

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

The real problem is a lack of a common API for encoding regardless of GPU/CPU, which leads to vendor-specific implementations with varying degrees of quality.
The most efficient way to pretty much do anything is a dedicated HW block (from both perf and power point of view), so there is no question that there is value in encoding using dedicated hardware, but the software has to catch up.

that encoders inexplicably insist on codex and wrappers that predate the Millenium? 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.

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

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

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

So basically the article says GPU rendering is bad, but QuickSync is good enough for prime time.

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

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.

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.

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/

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.

The hardware based transcoding is not necessarily better (see: the dire state of BBC's terrestrial HD broadcasts compared to the earlier 'test' HD broadcasts, and their stonewalling whenever people call them out on it and explain how to improve it). Hardware transcoders are used
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

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.

Have you tried x264 with --preset veryfast? My experience is that x264 is able to match a GPU encoder's speed while still giving significantly better quality. I'd only bother with a GPU encoder if I had a terrible CPU (netbook, phone?).

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

The problem is that the processor (GPU in this case) shouldn't make a difference as to the results of the calculations. Sure, a shittier GPU is going to have a shittier picture when forced to run at a certain framerate beyond its capabilities, but when used as a processor for a process that isn't time constricted, it should just take longer. Instead, feeding the same input into one brand of GPU is giving different results when it is run on a different GPU.

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.

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

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.

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.

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.