The Intel Developer Forum: High-def video slowly matures
Support for both blue-laser DVD formats got the headlines following Tuesday's IDF keynote by Paul Otellini, the broader story involves platform support for the decoding—and eventually, encoding—of high-definition video.
By Brian Dipert, Senior Technical Editor -- EDN, September 20, 2007
There's more than meets the eye to Paul Otellini's Tuesday keynote proclamation of inclusive support for both blue-laser optical formats (Blu-ray and HD DVD). Robust hardware assistance for high-definition video decode will be here within the year, but tangible encode aid is yet to come—and is sorely needed to address today's speed-plus-quality requests.
My cohort Colleen Taylor's excellent coverage of Otellini's keynote, published Tuesday, provides me with a convenient springboard to complete a woefully belated product writeup. To begin, I'll provide some background and perspective on Otellini's comments.
Montevina is the mid-cycle refresh of the Santa Rosa platform that I most recently covered in depth back in May. It evolves from today's 65-nm-fabricated Core 2 (aka "Merom") mobile CPU to the portable-tuned version of Intel's 45-nm-based "Penryn" processor. Commensurate with Penryn's faster front side bus, Santa Rosa's core-logic chipset (the 965GM) will similarly evolve in the Montevina generation to the "Cantiga" core-logic chipset; anticipated enhancements include DDR3 SDRAM cognizance, a GbE MAC (media access controller), and optional WiMax module support, along with an integrated graphics core that provides more robust DirectX 10 support, a faster core clock speed, and additional shaders.
Montevina also brings desirable improvements to the mobile platform in the venue of video decoding, thereby explaining Otellini's highlighting of high-definition optical discs during his pitch. Blu-ray and HD DVD have quite different physical formats, but once the bit stream is pulled off the disc, they actually look quite similar. They use the exact same three video formats: high-resolution MPEG-2, MPEG-4 AVC (also known as MPEG-4 Part 10, and as H.264), and the Microsoft-originated (and now SMPTE-certified) VC-1.
The two optical formats support identical audio formats, although some minor differences exist in terms of which audio codecs are mandatory versus optional. And both platforms support (now-hacked) AACS data encryption. About the only substantial bit-stream difference between the two formats (aside from their navigation schemes, which I'll touch on next) is that Blu-ray also supports optional BD+ encryption in conjunction with AACS. Since the BD+ spec was only recently finalized, I don't believe that any BD+ inclusive Blu-ray discs are yet shipping. Frankly, Microsoft is far more invested in HD DVD, by virtue of its HDi interactivity scheme, which competes against the Sun-developed Blu-ray Java approach, than is Intel. To wit, I suspect that Intel's past stated preference for HD DVD was primarily a favor to its key partner, Microsoft.
Take a look at part 2 of my mid-May Santa Rosa writeup, and you'll see that I asked Mooly Eden about hardware-accelerated video-decode support for H.264, but received no definitive response, neither from him nor from any of the other numerous Intel employees in the room that day. At the time, I thought this was extremely odd. What I've subsequently learned leads me to strongly suspect that whereas Eden knew the answer to my question (he's a smart guy, after all), he declined to respond because the reply wouldn't positively reflect on the products he was pitching at the time.
Courtesy of their DVD-tailored roots, graphics subsystems from Intel and other suppliers have supported hardware-accelerating portions of the MPEG-2 video-decode pipeline for many years now, and that acceleration has broadened to encompass an ever-increasing percentage of the total decode chain:
-
First the final (and processing-intensive in its own right) color-space conversion step, then
-
the preceding motion-compensation process, followed later by
-
the preceding iDCT (inverse discrete cosine transform), and eventually also
-
the initial Huffman and RLE (run-length encoding) bit stream decode processes.
Over time this video-decode support has also broadened to comprehend both standard-definition (DVD) and high-definition (ATSC, Blu-ray and HD DVD) resolutions and bit rates. And, by virtue of VC-1's roots in now-mature Microsoft Windows Media Video 9 (publicly introduced in beta form back in September 2002), graphics vendors have also evolved their hardware to the point that they're able to accelerate a substantial percentage of the VC-1 decode pipeline. While MPEG-2 and VC-1 are dissimilar in their specifics, they share enough high-level resemblance that it's possible to craft hardware that comprehends them both.
Graphics-assisted video decode is particularly critical in mobile applications, because the decoding alternatively takes place in software running on the host CPU and/or in a dedicated video-decode IC. Both options are costly in both silicon and battery budgets. Without robust video-decode support in the graphics subsystem, you'll need a brawnier CPU than you otherwise would, or you'll need an additional chip devoted to the video task. You'll also need a beefier battery, with consequent weight and form-factor impacts. If not, your users will experience decreased system-operating life between charges.
You may have already noticed that I haven't yet mentioned the third video codec supported by Blu-ray and HD DVD: H.264. It's the newest of the three algorithms, and consequently the least robustly comprehended in today's graphics hardware (from both Intel and its competitors). It's also the most decode-processing-intensive of the three codecs, a tradeoff which, in some cases, results in it having the lowest bit rate of the three codecs for a given perceived measure of image quality.
As it turns out, for Santa Rosa Intel is leveraging an H.264 decode chip supplied by Broadcom, which briefed me prior to the product's early-June introduction (thereby explaining my earlier "woefully belated" comment). Judging from Otellini's words on Tuesday, coupled with subsequent (albeit less specific than I'd prefer) messages from other Intel representatives, Montevina's chipset support for H.264 decode will broaden to the point that Intel believes it will no longer require Broadcom assistance (and also won't be placing an excessive power-consumption burden on the system CPU). Hopefully Intel will also solve its current DRM-related driver limitations, which preclude Blu-ray and HD DVD playback on today's dominant operating system, Windows XP.
For reasons that aren't entirely clear to me, I've long harbored a fascination with PC-based multimedia decoding, encoding, and transcoding. As I spoke with Broadcom about its Media PC ICs in late May, I had flashbacks to a mid-1998 article. In it, I described the chip-architecture tradeoffs and decisions that NeoMagic (no longer in the graphics-accelerator business) made when defining its MagicMedia256AV. The company's undue reliance on embedded frame-buffer memory was a mistake, as I pointed out in a subsequent February 2000 article. And NeoMagic's decision to forego meaningful 3-D graphics acceleration on the limited available silicon real estate, in favor of a robust MPEG-2 decode pipeline, probably didn't win it any soundbyte points with the Doom-fixated mass media.
But I'd argue that prioritizing MPEG-2 over 3-D was the right decision at the time, no matter that then-ATI (now AMD) and Nvidia unfortunately ended up winning the perception war. Realize that back in 1998, PCs could barely decode an MP3 audio bit stream in real-time. Now consider this: How many potential customers of systems containing MagicMedia256AV accelerators in 1998-2000 were interested in playing first-person shooters in their airplane seats, versus watching then-embryonic MPEG-2-encoded DVDs?
Switching to high definition, my Broadcom briefing also reminded me of my 1999 hands-on experiences with ATSC decode hardware from subsequently acquired TeraLogic (a 1999 EDN Innovation award winner). Nowadays, the bulk of ATSC processing occurs on graphics chips, with the remainder handled by the system CPU. However, that processing can still be a system-strapping operation, especially when the CPU is single-core and otherwise deficient, and/or if the GPU's resources can't be brought to bear on the task. And, as we're now seeing with the Santa Rosa-to-Montevina migration, more advanced codecs such as VC-1 and H.264 raise the required-performance bar once again.
I'll close with a few thoughts on video encoding. Most video codecs, as I've written as far back as June of 1998, are intentionally designed to be asymmetrical. That is, they have a much higher processing burden for encode as compared to decode. So if real-time video decoding is a challenging function, as I've described above, you can imagine how demanding real-time encoding is on today's computing platforms.
On Wednesday I attended a demonstration of identically configured systems (same CPU clock speed, same Santa Rosa chipset, same front-side-bus speed, same amount and type of memory, and so on), one containing a "Merom" processor and the other housing a "Penryn" prototype. The Penryn-based system completed a standard-definition DivX encoding session substantially faster than its Merom-based predecessor; the beta DivX algorithm being run was cognizant of Penryn's SSE4-instruction-set enhancements, and it also exploited the newer CPU's larger L2 cache. But in neither case did the operation occur in real time, not to mention faster than real-time.
For today's mainstream PCs, and at non-real-time encode rates and encode resolutions of standard-definition and below—targeting subsequent content playback on products like Sony's PlayStation Portable and Apple's iPods and AppleTV—you'll find hardware H.264 encoding assistance in the form of the USB-based ADS Technologies Instant Video To-Go (for Windows) and the cosmetically similar-looking (and suspiciously so) Elgato turbo.264 (for OS X), based on silicon from Mobilygen.
Only within the past two years have we reached the point where Microsoft is comfortable (and then only in some high-end cases) with the idea of removing the requirement for a hardware-based standard-definition MPEG-2 encoder IC (traditionally present to ensure interruption-free real-time recording) in its Media Center Edition specifications. And I haven't yet seen a convincing real-time standard-definition VC-1 or H.264 encoding demonstration that I concluded would stand up in a glitch-free manner to real-life usage scenarios.
What about high-definition real-time VC-1 and H.264 encoding, particularly when done in a high-quality manner? That's the turf of application-tailored chips from companies like Ambarella. It's the bailiwick of banks of multicore x86, Cell, and other CPUs. It's the territory where clusters of Texas Instruments and other high-end DSPs play. And it's perhaps the key application (aside from ASIC prototyping) where high-end Altera and Xilinx FPGAs garner a sustainable and substantial market presence, once again in multiples per system.
To the degree that video encoding and transcoding become pervasive applications, particularly if they're coupled with users' expectations for real-time (or even faster-than-real-time) encoding, the PC platform will absorb whatever incremental horsepower AMD, Intel, and other silicon vendors can throw at it for years to come. More cores? Faster per-core clocks? Bring 'em on.
