Three points, those reviews say that the Quick Sync technology supports up to main profile H.264, which is just about all that people will use since that's the top of the spec for the Apple TV and all of the mobile iOS devices (including the iPad). Second, they say that Intel worked very hard to match the encoding quality that was produced when using strictly software-based techniques (that relied on previous generation Intel CPUs). Lastly, they said that the encoding quality when using Quick Sync was very close to the existing software-based encoders and much superior to the results you get when using hardware-accelerated encoding using a top-end NVIDIA GPU. I'm fairly certain that they also suggested that the quality and performance of the Quick Sync encoding might improve once the drivers are more fully optimized.
The only profile that would beat H.264 main would be the so-called "high." But frankly, I think you would only use high if you wanted to be absolutely certain that you were getting visually lossless encodings from a source like Blu-ray or maybe a very good DVD (as a form of backup, I guess). Besides, most people are going to be re-encoding for their mobile devices (and maybe the Apple TV) so I suspect that Quick Sync would be fine for those applications. Personally, I do multiple encodes anyway, some for streaming over 3G and others for my Apple TV.
Your points are well taken, however, since we really won't know until a Sandy Bridge MacBook ships with Quick Sync enabled (i.e. Apple will have to supply the drivers, which they may not do in the initial release). It's worth pointing out, however, that even the software-based encoding on Sandy Bridge was twice as fast as on a Core 2 Duo.
Hmm... I thought that from the iPhone 3GS on up they supported high profile, despite Apple's specs only indicating main profile. I could be wrong though. I did recently receive the new ATV as a gift but haven't had a chance to set it up yet, and I was hoping that my movie collection would play just fine. Little have I suspected that I might try streaming my high profile encodes only to be met with a big fat fail.
And I see your point about quality vs speed as well. I'm still not sold on the quality being comparable to a software solution until I know the quality of the software solution being compared, but that information will come in time. But for the casual encode, QS could potentially be a big time saver when absolute quality is not paramount, especially when paired with a second, higher-quality encode for devices that support it (if SW encoding is in fact that much slower independent of library, doing it twice would be painful even if one of the encodes is faster due to lower quality). My interest in the comparison is mostly academic because I probably won't be upgrading soon anyway.
Last edited: