We finally are starting to understand the relationship of HDMI 1.4 to the requirements of 3-D as we discuss what the vendors actually are delivering in Installment 027. Along the way, we also talk about some of the latest news like networking Ceton (or any CableCARD) tuners, how Microsoft is looking to their Azure services as a platform for delivering TV and content from the cloud to all three screens, and finally starting to see products that leverage HDMI’s CEC capabilities across multiple vendors’ product lines.
HDMI 1.4 is not about additional headroom or speed when it comes to 3-D. It is about understanding the multiple 3-D formats and being able to dynamically change the rendering formats as the source content changes. Being able to understand the EDID and InfoFrame extensions is critical to the success of designing and implementing distributed HDMI-based 3-D infrastructures. We discussed the mandatory formats required for 3-D in our last installment (http://thedigitallifestyle.com/cs/blogs/custom/archive/2010/03/08/Analog-is-a-risky-platform_2C00_-More-on-3_2D00_D-Structures-for-HDMI_2C00_-and-CEC-_2D00_-Installment-026.aspx).
So, what are these “InfoFrames?” To make sense out of how these pieces all play together, we need to step back and look at them at a high level. InfoFrames are part of the Consumer Electronics Association’s CEA-861 standard for the auxiliary data sent across the TMDS channels in an InfoFrame packet format. InfoFrames are part of the CEA’s Digital TV Profiles for uncompressed high-speed digital interfaces. They are not just for HDMI or DVI, but a variety of digital audio and video connections. The Auxiliary Video Information (AVI) InfoFrames tell the receiver (the Sink side) the capabilities of the transmitter (the Source side). For example, they include pixel encoding and enhancement support for the video. There also are audio InfoFrames, which describe the details about the audio data formats and rate so the receiver (the Sink side) can synchronize itself with the incoming audio data format. This standard defines video timing requirements, discovery structures, and a data transfer structure (InfoPacket) that is used for building uncompressed, baseband, digital interfaces on digital televisions (DTV) or DTV Monitors. A single physical interface is not specified, but any interface that implements InfoPackets must use the VESA Enhanced Extended Display Identification Data Standard (VESA E-EDID) for format discovery. We will focus on the InfoFrames as they related to HDMI in this blog post, although their scope is much broader.
An InfoFrame packet carries one InfoFrame. The InfoFrame provided by HDMI is limited to 30 bytes plus a checksum byte.
Auxiliary Video information (AVI) InfoFrame
Various aspects of the video stream are identified by the HDMI Source to the Sink using an Auxiliary Video information (AVI) InfoFrame.
A Source shall always transmit an AVI InfoFrame at least once per two video fields if the Source:
– is ever capable of transmitting an AVI InfoFrame or,
– is ever capable of transmitting YCBCR pixel encoding or,
– is ever capable of transmitting any Colorimetry other than the transmitted video format’s default Colorimetry or,
– is ever capable of transmitting any xvYCC or future enhanced Colorimetry or,
– is ever capable of transmitting any Gamut Metadata packet or,
– is ever capable of transmitting any video format with multiple allowed pixel repetitions.
An AVI InfoFrame is transmitted even if the Source is transmitting RGB and non pixel-repeated video. When a Source is not explicitly required to transmit AVI InfoFrames, it still is recommended that the Source transmit the AVI InfoFrames anyhow.
HDMI Sources are required (at least in most cases) to use the Auxiliary Video information (AVI) InfoFrame and Audio InfoFrame, but only are recommended to transmit it in other cases. All InfoFrames are described in detail in CEA-861-D (and now in 861-E). Other InfoFrames specified in CEA-861-D are optional.
HDMI v1.4a references CEA-861-D and selectively reproduces items from CEA-861-E. Work is on-going within CEA (R4.8 WG7) to create an extension to CEA-861-E for 3-D. As part of the process, CEA has asked HDMI LLC to make public the 3-D portions of the HDMI v1.4/v1.4a standard. HDMI Licensing, LLC has agreed.
The CEA also has requested that HDMI Licensing, LLC “Permit 3D-related fields of HDMI VSDB structures (as defined in HDMI Version 1.4 Extraction of 3D Signaling Portion document – what it just released to the public) to be used in new CEA-861 structures, which may be transmitted by other interfaces using non vendor-specific methods.” This would make the HDMI 3-D signaling standard across all CEA-861 uncompressed digital A/V interfaces, but do it by putting the CEA standard wrappers around extracted HDMI 3-D Vendor Specific Data Block (VSDB) structures. The interface issues are somewhat out of scope for the 3-D Video Workgroup, although interested parties should join CEA’s R4.8 WG7 and contribute. The CEA also is concerned about 4K video timings (something we have talked about quite a bit in previous Installments) and is working on solidifying the InfoFrames for that environment, too.
An InfoFrame packet carries one InfoFrame. The InfoFrame provided by HDMI is limited to 30 bytes plus a checksum byte. HDMI Sources are required, in some cases, to use the Auxiliary Video information (AVI) InfoFrame and Audio InfoFrame and recommended in other cases. Other InfoFrames specified in CEA-861-D are optional. All InfoFrames are described in detail in the CEA-861 standard (http://www.ce.org/Standards/browseByCommittee_2641.asp).
The real issue, as it relates to our discussion, is that the 3-D video signals may originate from, or be carried exclusively over, other interfaces (WirelessHD, WHDI, DiiVA, HDbaseT, and DisplayPort), which also use CEA-861 for video timing and signaling. Examples covered in the specs include scenarios like a WirelessHD player (HRTX) directly driving a WirelessHD display (HRRX) or a DiiVA player driving the input of an HDMI display through a DiiVA-to-HDMI converter. However, the “official” CEA-861 specification currently does not include 3-D definitions. These currently are defined by HDMI Licensing, LLC and are considered as vendor extensions to the specification. The CEA is taking these and figuring out how (or if) they should be incorporated into the broader specifications.
One option is to extend the CEA AVI InfoFrame by adding three bytes (note that metadata is not supported)
Another option under consideration is to define new type of 3-D InfoFrame (with metadata supported)
This includes defining a new (EDID) 3-D Data Block (covered in the next Installment)
Some Differences between HDMI and DVI
HDMI follows the CEA-861 standard, which requires all devices to support RGB color space by default. Note that DVI only supports RGB because there is no reverse (InfoFrame) channel to announce a change in color space (from RGB to YCbCr). YCbCr is optional (according to CEA-861) and must be negotiated for by a handshaking sequence. So if YCbCr is not supported by the display, then the HDMI source will automatically default to RGB. HDMI sources must look at the display’s EDID and, if an HDMI Vendor Specific Data Block is not found, are obliged to provide RGB space.
The CEA-861 InfoFrame structures are a key component to being able to play 3-D content effectively. The Source broadcasts the format within the video stream and the Sink dynamically changes the way it displays the content using that information. This process currently is specific to HDMI’s implementation (the 3D_Structures covered previously), but the CEA is looking to incorporate the same functionality into other digital audio and video transports.
All of this is dependent upon the capabilities of the display device through communicating the EDID structures between the Sink and the Source during the HDMI initialization process. We cover those aspects in our next Installment. Please stay tuned……