Skip navigation
Electronic Design

Avoid The Pitfalls Of Inaccurate EDID

Modern A/V devices rely on HDMI Extended Display Identification Data (EDID) to communicate with other devices in an audio/video system. If the EDID is poorly thought out at the design stage, significant audio and video errors can occur.

Whatever its relative merits and demerits may be, HDMI is here to stay as the audio/video (A/V) interface of the foreseeable future. As the number of consumer and professional devices using HDMI to deliver audio and HD video grows, the pressure mounts on A/V manufacturers to ensure that their devices’ Extended Display Identification Data (EDID) is accurate (Fig. 1).

The idea of EDID is a powerful one, analogous to the spec sheet of an HDMI device in electronic form. Contained in one simple ROM, and usually in just a couple of hundred bytes of data, is all of the information about the video and audio formats the device will handle.

In the world of broadcast manufacturing and test, it’s a welcome innovation, because if you want to know what formats a certain piece of hardware can cope with over HDMI, all you have to do is read its EDID (Fig. 2). Or that’s the theory. In practice, there seems to be quite a lot of equipment out there with EDID that doesn’t accurately describe the device’s capabilities, frustrating manufacturers and end-users alike.

Generally speaking, the specification of HD A/V equipment isn’t always as clearly expressed as it could be. This is particularly the case in the consumer domain, where labeling is everything. In the U.S. and Europe, for example, if you buy a TV that says “1080p” in large letters on the box, it’s not always a guarantee that the screen can show video with a vertical resolution of 1080 progressively updated lines. Sometimes, the label only indicates that the device can receive incoming video in the 1080p format, which it then decimates before displaying it at a lower resolution.

There are similar ambiguities with EDID information, as EDID is concerned only with describing the formats that a device can successfully recognize and receive. It doesn’t contain information about how a particular format will be reproduced.

If the EDID says a device will accept audio at a sample rate of 96 kHz, and it plays the audio back correctly, the EDID is accurate even if the device actually achieves playback by sample-rate converting the audio down to 48 kHz internally beforehand. However, can it honestly be said that the EDID is accurate if the 96-kHz audio is received by the device but is reproduced full of dropouts and pops (as was the case with an HD television recently tested by Audio Precision’s engineers)?

It’s not clear what causes the mistakes in HDMI EDID, but it’s possible to speculate, based on some of the errors that crop up regularly. Some manufacturers seem to be uncertain how to write the required information in accordance with the EDID specification.

In other instances, off-the-shelf EDID information produced by third parties is being used, and it doesn’t correctly describe the product. This might be due to oversight; perhaps the companies concerned bought the third-party EDID as a starting point to describe their product, but they never got around to adapting it for their device. Others may be producing EDID information for a top-of-the-range product, and then they use that same data for all of the products in the range without considering that the EDID is inaccurate for the entry-level product in the same range.

There’s no doubt that producing accurate HDMI EDID requires care. Add to that the increasing number of available formats for HD video and audio delivery, and the task becomes even more complex.

It could be that the situation will both improve and worsen over time. Manufacturers may become more appreciative of the importance of producing accurate EDID information and more accustomed to the task as time goes by. But new formats will continue to develop, which means it won’t be easy to stay on top of the situation.

It’s been interesting to watch the growing popularity of the now-regular PlugFest events organized by HDMI manufacturers. This can be interpreted as a measure of just how difficult it can be in this digital, metadata-driven age to create products that are compatible with a wide range of industry hardware. For those unfamiliar with PlugFests, they’re essentially opportunities for manufacturers to meet and bring along their hardware and software, sometimes at an early stage in the development of a new product, and try connecting it to other manufacturers’ equipment.

At this year’s Spring PlugFest, the Audio Precision team was able to observe what was happening down at the metadata level. Some of the HDMI devices at the show were connected together, thanks to a recently added feature in Audio Precision’s APx analyzer that presents metadata in a view like a logic analyzer (Fig. 3).

One example that was observed involved two HDCP content-protected devices. When hooked together, they have to decide whether they’re going to allow digitally protected content to pass from one to the other. They’re supposed to have a short “digital handshake,” authenticate each other, and if successful, exchange encryption keys and begin encrypted transfer.

Yet some of the hardware for this process was authenticating, starting encryption, de-authenticating, re-authenticating, starting again... The devices took a lot longer than normal to settle down and get on with the transfer.

With consumer equipment pairings like HDMI-equipped Bluray players and TVs, authentication errors like this could lead to a noticeable delay of several seconds between a consumer pressing “Play” and playback beginning on screen. That’s the kind of thing consumers would notice and would compare unfavorably to old home video systems, even analog ones like VHS.

Some companies argue that they attend PlugFest to pick up on these kinds of problems and that further action is unnecessary. It’s true that some consumers will never encounter problems, depending on the devices they hook up via HDMI and the formats they use. Certainly, none of this is likely to matter if a manufacturer of broadcast technology produces devices that respond to well-established standard audio and video formats and correctly flag this fact in their EDID.

Continue to page 2

But if the EDID incorrectly says the device will receive, say, compressed formats like Dolby’s AC-3, and this fact hasn’t been tested or brought up at a PlugFest, the first people to find out might be the manufacturer’s customers. These days, when disgruntled users can rapidly make their displeasure regarding an apparently dysfunctional machine heard around the world via consumer forums, it’s much better for manufacturers if such problems never make their way into the public domain.

Ideally, HDMI- and EDID-related problems should be picked up at the R&D stage of the product’s development, rather than at a PlugFest before the scrutiny of the world’s HDMI manufacturers, or when the device is already on the production line. There’s sense in using PlugFests in addition to a carefully designed inhouse program of rigorous product testing.

Sill, a few ad hoc interconnection tests performed on some preproduction hardware at a PlugFest can’t be considered a replacement for proper product testing programs. Using accurate EDID information, and a thorough program of audio and video testing at the design stage, can nip these problems in the bud.

Manufacturer-led support for accurate EDID is good news for both customers and manufacturers. Use of off-the-shelf EDIDs should be avoided. Also, the product design team, which needs to be trained properly in the art of writing properly specified EDID information, should create it so it properly describes the capabilities of the specific product—and not just one in that range.

The device should then be given to an EDID-conversant test engineer, ideally someone not involved with the product design, who should decompile the EDID. This is not as hard as it sounds. Plenty of companies such as Audio Precision make devices capable of reading and editing EDID.

But just reading the EDID isn’t enough. The engineer also needs to test the device’s ability to cope with the media formats that the onboard EDID says it can handle. Again, this isn’t difficult. It’s simply a matter of constructing a systematic test program that involves firing these media types—including obscure HD video and compressed audio formats where necessary—at the device under test and evaluating the results. Error handling should also be tested. This would be done by sending deliberately corrupted information and seeing exactly how the device handles data that the EDID says is untenable.

With modern video and audio test hardware, the process of testing, analysis, and results reporting can be automated and integrated into a software-based process control environment. In this way, any problems with the EDID or with the device’s ability to behave according to its advertised specification could be picked up long before the product reaches end users. None of this needs to replace testing sessions at the likes of PlugFest, but it might make for more reliable HDMI equipment at both the broadcast and consumer level.

TAGS: Components
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.