Most of my transcoding is disc to archive, so quality is more important than speed. It would have been nice if there was more granularity to the fixed function encoder so the parts that matched x264 could have been utilized by it. The x264 people have generally said they can match QuickSync / GPU speed if you drop the quality down to comparable levels.

When I upgrade to Haswell, I'll still use the software encoder, especially if x264 makes as good as use of AVX2 as it sounds.Reply

The x264 clowns are full of it. They went out of their way to hamper bringing Quicksync to the masses, and they did it for petty reasons of personal politics. I've read the forum posts where Intel came to them and said, "hey, this is what we're working on, what do you think?" They acted like jerks, and their performance claims are hogwash. Quicksync is fast. Seriously fast.Reply

There is no way that x264 can compare to QuickSync in raw performance (not in quality) as, with full 4X 1080i59.94 HD Transcoding, Sandy Bridge Mobile CPUs only use 10%-25% of the CPU to feed the QuickSync engine while x264 would need more of the CPU to execute the same video transcoding task not leaving CPU performance for Audio Transcoding.Reply

"There is no way that x264 can compare to QuickSync in raw performance"

Let's fine-tune that statement. The folks at Compression.ru do a yearly compression study and release free + paid reports. The appendix from their 2012 study, which includes IVB QS2 results, found that on performance desktop IVB, x264 is both faster AND provides a higher qual:perf ratio.

There are a huge number of people that stream their gaming live. Quicksync could allow people with 2 core CPUs to stream without impacting game performance, and would allow people with 4 core CPUs to stream at a much higher quality.Reply

The big thing is no one uses x264 on superfast presets because people using x264 usually care about quality. The result is few people are aware of how fast it can be in raw fps numbers once it backs off the quality benchmark it is known for.

I will grant you that while x264 veryfast may be around Quicksync speeds, it will definitely be using more CPU power to do it.Reply

I've read that discussion in the past (first in early 2011 - when deciding whether to buy into P65 or wait for Z77). That's not really a correct interpretation of what the state of affairs were:

Firstly, the x264 dev's overriding interest is in maintaining the quality of the encode. If QuickSync was fast, that was irrelevant if it couldn't be used to replicate the quality of x264's CPU h.264 encode. We hhad all seen nVidia's efforts in this area to that time and they were pretty awful. So of course there was skepticism.

Then there was a problem with what information was actually forthcoming from Intel. The information provided seem to come from one engineer's private outreach. All the claims were vague (maybe he wasn't a native English speaker?). Requests for further information took a long time and still weren't sufficient.

Effectively, there seemed to be cross purposes. The x264 project would have been more than willing look at using specific elements of QuickSync, to the extent it was possible. The Intel engineer was thinking x264 should be just a QuickSync frontend (obviously not going to happen). Intel itself had no official involvement in the discussion at all.

So here we are two years down the track at approximately where we should have been a tad over 2 years ago!Reply

Well, you should reread the discussions again. Love QuickSync and all the juicy part Anand told you about? They are not available unless you paid for an application. The decoder to OS software player didn't came long time later. And Intel couldn't be bother to work with the community as far as i could tell. ( Although not necessarily the engineers fault. )

So we basically have a piece of Hardware in our CPU that is being greatly advertised but cant be used at all.Reply

It is actually not quite true. You DO have free (as in beer) software taping QuickSync since early/mid 2012, when Intel made it available in their dev kit.Mediacoder http://www.mediacoderhq.com/ is one of them and works quite well (on my SB 2500k).

QS is a black box with very limited options though, so in the end I used x264 for flexibility (still with MediaCoder btw).

So, it is usable, but intel is lifting the veil one corner at a time...Reply

This may have been true in the past because they found (collectively) AMD and NVidia solutions did not offer substantial gains in transcoding time. Now QS is the game changer and so reflect the attitudes of said "clowns".Reply

I do enjoy QuickSync, as I specifically wanted the HD 3000 i3 for this very task. I was disappointed I could not use QS on Ubuntu and that Intel offered no support. My guess is that Intel wants full exposure of QS so that their SDP chips have the most market penetration possible. QS on Android perhaps?Reply

Last time I tried to enable both the iGPU and discrete GPU in the BIOS, my system decided to stop sending video signals to any output (on either the iGPU or discrete card), requiring a CMOS reset to get the thing booting again.Reply

Most desktop motherboards come with Lucid Virtu MVP these days, so desktop users with discrete cards can access QuickSync through d-Mode. However that's only for self-built systems; I can't recall ever seeing Virtu with an OEM system, which is what most customers are buying.Reply

Most of my movies start at 4GB, I transcode them to less than a gig so I can fit about 25 films when I travel two weeks at a time. Also decoding a 1080p for a tablet uses more battery than 480p. I dont think transcoding is going away anytime soon.

I use transcoding on the fly with servio and ps3ms in my house for all my dlna devices, but hopefully those apps with start to take advantage of Quicksync as wellReply

I hadn't bothered with it when I had my SGS2 with 16GB NAND and a 32GB mSDHC card. But when I switched to a Galaxy Nexus, space became a premium commodity. Now I reencode my 1080p stuff to 720p (reducing the size to ~1/3 or 1/4 of the original), so that I can cramp more stuff onto the phone.Though I wouldn't look at upgrading to a new setup (from my i7 860) just for QS.Reply

AFAIR, the problem between Quick Sync and x264 were not because mediating library was closed source, but because main encoding process was closed and x264 had no way of affecting the quality. If I remember correctly (and I'm sure the messages can still be found in x264 forums):*) x264 folks were interested in accelerating the encoding, if x264 has access to all key steps and can affect the quality of the output (I have forgot the actual terms used).*) Quick Sync works as a fast black box: you feed some data and get back final results without being able to affect anything.*) Quick Sync produced quick results, but the quality wasn't good enough and offered no way to change that.*) Intel guys offered x264 folks to use Quick Sync, but because of above mentioned reasons it was rejected.*) Some x264 devs tried to play Torvalds and be an a$$hole. But they had actually very little reason to do so and in addition they overdid it. But it's not every day you get to opportunity to say "f**k off" to Intel from high horse, must have been very tempting, I'm sure.

The main argument of x264 against using Quick Sync was: it doesn't matter if it is fast, if it produces inferior results and doesn't provide any means to improve quality. In that sense Quick Sync doesn't differ from other fast libraries, for example Cyberlink. And x264 is not interested in being merely a caller of inferior external black boxes, no matter fast these are.

Many encoders trade quality for speed. x264 offers ability to trade speed to higher quality and x264 is not interested giving it up, even if some fast library is hardware accelerated and has "Intel inside" on it.Reply

Yeah, even still I don't think this makes sense and don't see how it really gets supported by the programs we all actually use.

If I were on one of these teams, I'd be looking at whether OpenCL can do anything for me, given it's...open, and will probably be supported better than anything else, etc.

I continue to be pissed that Intel is blowing all these transistors on video and encoding. I do not want it. I want more cores, bigger cores, etc. Not some proprietary fixed function video encoder...Reply

Yeah, as I understand it this doesn't actually fix x264's problem at all.

And it wasn't just x264 that was unimpressed with QuickSync's image quality; recall that Apple refused to enable it Sandy Bridge on the grounds that the output looked like crap. I assume that's why Intel concentrated more on quality for IVB. It now meets Apple's specs, but you still wouldn't want to use it for non-realtime transcoding (e.g. DVD ripping with Handbrake or whatever).

Also, I must protest being an a$$hole as "playing Torvalds". Linux's success is due in equal parts to Linus' pragmatism and his generally well-founded stubbornness. I'm genuinely afraid of what'll happen if he gets hit by the proverbial bus and the FSF faction takes over the kernel. Google would probably have to fork to continue Android, among other things.Reply

FSF has 0 say in the kernel and would not be able to change anything: the kernel is licensed under GPL v2 PERIOD. No "or later" or anything like that, so it is stuck to it (it would be *impossible* to get consent from the hundreds if not thousand of contributors to re-license it, as each contributor has kept their copyright).

If anyone wants a kernel under a different license, they are welcome to write their own.Reply

So what if it's GPL v2? The FSF could take over as the maintainers/stewards of the mainline kernel, leave it at GPL v2, and still accept patches into mainline that Linus would otherwise reject and/or reject patches that Linus would otherwise accept.Reply

Multi pass is a huge waste of space, unless you're doing something silly like trying to burn movies to 700MB CD-Rs. Believe it or not, x264 knows better than you how many bits it needs to achieve a particular quality level with a particular video.Reply

People that argue that people using x264 only care about quality have very little imagination.There's a lot of uses i can think off where you need speed for x264.It's the codec that xsplit uses, and it's also used by plex and other applications like it.

on both xsplit and plex i'd much rather have the speed than the quality.

For xsplit the ability to stream with little to no performance hit would be very useful. Because assuming it doesn't slow your game down it would be just as good as having a dedicated encoding computer for streaming or a capture card that does hardware encoding.This would allow people to use hardware they already have instead of having to shell out 300 dollars or more on a hardware solution.

Plex would also have huge benefits from this. My whole family uses plex trough roku boxes and iOS clients. For me that means that my entire library has to be transcoded. Having plex use quicksync would probably allow for multiple transcodes with out breaking a sweat. Something that isn't possible right now; since a few 1080p transcodes will choke my server more often than not.

I never understood why intel would invest so much on a piece of technology if they were going to make it so useless...Well, at least they are trying to fix that now. But now we have to see if developers of desirable software jump on board.Reply