HDCP, HDMI, Repeaters, and You (Well, Me, Anyway)

EDIT (8/4/2011): I continue to get questions about this blog post even today, but I need to point out that the information is seriously outdated. A change was required to happen in vendor DVD software (PowerDVD, WinDVD, Arcsoft TotalMedia) and this was done in late 2008. Processors and chipsets from 2009 and beyond do not have this issue.

Hi, I'm Aaron Brezenski, and welcome to my blog.

I'd planned on a big introduction and discussion of what I hope to accomplish here, and I have about half of that written, but I'm not the important bit here, the high- and lowlights of Intel graphics in the Home Theater PC space are.

My plan is to discuss them, sometimes at length, and propose end-user friendly solutions and challenges to our graphics software developers. I'm not one, and don't pretend to know what their problems are; I'm approaching this from an end-user perspective (I own a G965 board) and am bringing back the messages from Consumerville that I'm not sure are being heard. So enough about that.

It's really unfair that my first post is essentially a gripe, but I feel it's important enough (and time sensitive enough, given where our competitors are in this space) right now that I'm skipping all the good things about Intel graphics usage in media and hitting what I consider to be one of the top 3 end-user issues which would prevent a small system builder or an individual from choosing Intel graphics for their Home Theater PC: HDCP repeater mode failures. Without further ado...

HDCP, HDMI, Repeaters, and You

How deep to go on HDCP this early in the game? Suffice it to say that HDCP is a handshake-driven content protection mechanism found in some DVI, most HDMI, and (likely all) DisplayPort interfaces. It enables a source device (a DVD player, Blu-ray player, cable box, or-- in the case we're concerned with-- HTPC) to detect the "sink" device (usually a monitor or A/V receiver) and determine whether said device is "safe".

If the sink device is "unsafe" (has not been given a set of licensed keys), no content will be passed. This is done to increase the difficulty level of someone inventing a device which can make a perfect digital copy of a video/audio stream and thereby providing a path for piracy. If you are a licensed keyholder and do something naughty like create a digital video recorder in violation of the license agreement, you can be fined and ultimately your keys can be removed from the list of valid ones: HDCP source devices will no longer recognize your sink device as valid.

I'm not going to argue about the effectiveness of this technique or even the motivations behind the content owners who demanded this-- my opinions (and I do have some) aren't relevant to the technical issue which needs addressing. It is this:

As of the latest (15.8) Vista drivers, HDCP for a very common usage model is broken on Intel graphics (G965, GM965, G33, G35).

Now there are two kinds of "broken": one exposes Intel to legal ramifications (if our graphics solution sends out protected material without verifying the sink device is licensed, we can be liable) and one just annoys the hell out of customers who merely want to use their systems as advertised.

This is the latter sort, but I think it deserves attention, and my observation of current driver release candidates is making me worry it's either not documented as a sighting or not being addressed. Now, the issue in gory detail:

There are Intel graphics-based motherboards out there right now which issue video over HDMI (we actually are ahead of the competitive pack in that our HDMI solution incorpoates full 7.1 channel audio as well, but that's a topic for another day). The HDMI solutions currently out for Intel graphics consist of a third-party chip which sits on the SDVO bus (muxed into PCIe) and does the conversion from video data to HDMI signalling.

It should be plug and play, and in fact, if you plug an HDMI cable into your Intel-based HDMI motherboard, and then into an HDCP compliant TV set, everything works fine. The HDCP handshake occurs with this solution, detecting the validity of the sink device and telling the software application, "Yes, the video path is protected. Go ahead and send the video." WinDVD and PowerDVD solutions which want HDCP protection for their Blu-ray disks smile happily and run around like a small boy in a field.

This is one usage model; however, it's only half the story. Modern home theaters have lots of different source components (DVD, cable, HTPC, DVR... heck, maybe even an "ancient" VCR), and the usual solution to this problem is to have a switching audio/visual receiver. This consolidates all of the audio and video sources into one box and sends it out to the TV and to the nifty loud speakers in glorious 5.1 sound. This is how things have been done for years, and a significant number of folks operate their systems this way.

HDCP has provisions for this usage model, in fact. When the handshake occurs between the source device and the sink device, a valid sink must inform the source whether it is a "repeater" or not. A repeater is, at its most simple, a device which will be passing the HDCP-protected signal on to another sink device somewhere downstream. Sound familiar? An A/V receiver which is passing HDCP-protected data onward (presumably to another HDCP device like an HDTV) is acting as a repeater, and will report itself as such.

It is this condition which appears to be broken. Plug Intel-enabled HDMI motherboard into a TV: Blu-ray disks will play. Plug Intel-enabled HDMI motherboard into an A/V receiver with an HDTV on the other end: HDCP device invalid error.

It looks from the evidence like repeater mode on Intel graphics enabled HDMI is not working. This is being reported by folks on AVSForum (where I'm a member), and is global across all Intel-based HDMI motherboards, all A/V receivers attempted, and across all legitimate software players (WinDVD, PowerDVD, Arcsoft TMT).

It is not happening with ATI or Nvidia solutions, nor with other HDMI devices (HD DVD or Blu-ray players). It's isolated to Intel graphics.

This is huge for the home theater PC community, a large fraction of whom have multiple source devices and don't just plug directly into a TV. In addition, the competitive advantage we do have in the HDMI audio space is completely destroyed by this problem: if a software application won't send to a receiver because it's a "repeater", the nifty 7.1 channel HDMI audio is useless.

The technical class of nerds in home theater is robust. They have developed a workaround: it's called gray-market software whose name I shall not utter here but whose purpose is to strip the protection mechanism from the aforementioned legitimate software players so they never even request HDCP protection. No protection, no worries about repeater mode.

Problem solved? Does Intel really want to have standard HDMI functionality only work while using gray market hacking software? Of course we don't.

I challenge the Intel graphics software developers and validation teams to correct this in the 15.9 drivers.

Sure, that's easy for me to say: I'm not on that team.

I shouldn't have to be.

I see this as a big miss. I can't imagine how it was missed, with all the validation that goes on both internally and at OEMs, but it looks like a substantial gap. And it's causing end-users to avoid Intel graphics-- which we obviously don't want.

Welcome to the Home Theater PC space: where the enthusiasts will argue for hours over the picture quality of American Idol and will demand 7.1 channel 24bit 192kHz sampled sound on the same.

In this case, they just want their fancy new HDMI A/V receivers to work, as advertised, with Intel graphics. I don't think that part is too much to ask.

That's enough for now. I'll be back another day with more unreasonable demands. At least until they fire me.

For more complete information about compiler optimizations, see our Optimization Notice.