Implications of the
Unidirectional
Analog Component Interface
for Use With the ATSC System
(What is Wrong with EIA-770.x?)
White Paper
© July 16, 1999
By David K. Broberg
Broberg@ieee.org
www.TheOffice.net/dbroberg
Introduction | Colorimetry | Aspect Ratio| Image Burn-in | Scanning Rates | Copy Protection | Captions | V-Chip | Conclusions
CableLabs (OpenCable) and CEMA and others have recently advocated the use of a unidirectional analog component interface as a means to connect an external MPEG-2 decoder to a DTV or HDTV display. This white paper identifies the implications of such an interface, the limitations and the consequences of applying such a standard.
While the CableLabs process through OpenCable has suggested such an interface, there is currently no standard available from OpenCable and apparently none is under development. CEMA on the other hand has published a trio of standards covering such analog component interfaces. One for Analog 525 Line (EIA-770.1); one for Standard Definition TV (EIA-770.2) and the third for High Definition TV(EIA-770.3). These three standards were passed in August 1998 by the R4 committee.
Since all three interface standards use the same physical connectors (BNC x3), it is reasonable to assume that some readers of the standard may choose to implement all three standards through a common set of connectors with the expectation that such an interface will be effective for all formats that might be encountered in an ATSC system. This paper examines that assumption.
The CEMA standard for High Definition (770.3) interfaces includes a normative reference to support the ITU-R BT.709 colorimetry. A separate note is included in the standard that says: "Under some circumstances the colorimetry of the source video may not be ITU-R-BT.709." But the standard includes no countermeasures for such cases. 1
The ATSC standard provides for an opportunity to describe the colorimetry of the encoded signals2 as either SMPTE 274M or SMPTE 170M which is more commonly used for 525 line (NTSC) programs (Note that ATSC documents refer to the SMPTE 274M colorimetry which is the same as ITU-R-BT.709.) This provision was included, among other reasons, to permit upconversion of '170 source material to HDTV scanning rates without complex recalculation of the colorimetry which can result in loss of image fidelity. Many first generation DTV receivers are equipped to respond to these embedded codes to adjust the colorimetry of the display accordingly.
This colorimetry issue has continued to gain attention in the ATSC. At the December 16th meeting of the T3/S6 the committee voted to amend the A/53 specification to further strengthen the support of these flags.3 Unanimously the committee added the following sentence to A/53, Annex A, clause 5.1.4:
"When colorimetries other than SMPTE 274M are used, they shall be explicitly indicated in the sequence display extension."
In further discussion at the same meeting, the committee also unanimously approved changes to the A/54 standard paragraph 5.2.1.3 to say:
"When colorimetries other than SMPTE 274M are indicated in the video bitstream, receivers should decode the color description information and provide the appropriate matrixing."
What happens when the EIA-770.3 interface is used between the decoder and the display? The coupling of these colorimetry signals between the decoder and the display is lost, so the message doesn't get through to the display circuits. The trouble is, the colorimetry matrixing in the display is primarily a function of the CRT calibration and phosphor selection, rather than the color decoder.
So when this critical path from the decoder to the display is broken, what options are available on the decoder side to deal with the colorimetry signals? There are two possibilities and neither is ideal. (A) There is no compensation in the decoder when the '170 colorimetry is encountered, resulting in distorted color representation on the display; (B) The decoder is built with a complex real-time transcoder to convert the color space from the '170 source to match the '709 outputs. The trouble with this is, that currently there is no decoder built today with sufficient digital processing power to make such a real-time transformation and even if there was, the transformation itself results in some loss of fidelity of the color signal.
The only other possible solution to the advisory note in the standard, would be for all broadcasters to agree to convert the color space to 274M colorimetry regardless of the origin. The trouble with that assumption is, upconverters without this capability are already being used by numerous broadcasters making it an expensive proposal. Even if they could do the color space conversion, they may not want to, since sets that don't rely upon the EIA-770.3 interface will be able to accurately match the original colorimetry when the appropriate colorimetry tags are used. Why would a broadcaster deliberately distort his signal to compensate for just a few sets that rely upon the inadequacies of the EIA-770.3 standard?4
The shaded areas of the table below show the situations where the output of the STB will have colorimetry that violates the EIA 770.x standards, unless the decoder can perform real-time color space conversion.
Source Material | Broadcast Path | STB Mode | Output |
HDTV ('709) | Linear | Direct Decode | HDTV @ '709 |
HDTV ('709) | Linear | Downconversion | SDTV @ '709 |
HDTV ('709) | Downconversion | Direct Decode | SDTV @ '709 |
HDTV ('709) | Downconversion | Upconversion | HDTV @ '709 |
SDTV ('170M) | Linear | Direct Decode | SDTV @ '170M |
SDTV ('170M) | Linear | Upconversion | HDTV @ '170M |
SDTV ('170M) | Upconversion | Direct Decode | HDTV@ '170M |
SDTV ('170M) | Upconversion | Downconversion | SDTV @ '170M |
The shaded output modes will have colorimetry errors
The solution to the colorimetry errors is to restore the communication channel between the demux (decoder) and the display. With such a digital communication channel, the colorimetry bits embedded in the MPEG stream can conveyed to the display circuitry where appropriate compensation can be made.
Section 6.5 of EIA-770.3, (High Definition Component Interface) says only 16x9 aspect ratios are supported. The Scope sections of EIA-770.2 and EIA-770.1 (Standard Definition Component Interface and Analog 525 Component Interface) say that both 16x9 and 4x3 aspect ratios should be supported. None of the specifications include any notes, explanations or advisories on how these aspect ratios should be managed. Nor do these standards include any mechanism to convey the transmitted aspect ratio information to the display even though this information is available in the ATSC bitstream.5
DTV Ready display devices may be sold with either 4x3 or 16x9 aspect ratios for the physical display. Numerous models from several manufacturers have already appeared that offer HDTV display with 4x3 physical aspect ratios. These HDTV display devices use a variety of reformatting technology to provide the user with a choice of several ways to view material that has aspect ratios not matching the physical characteristics of his display. Some of these sets are designed with the ability to automatically select the optimum aspect ratio and processing based on identification tags embedded in the signal.
The FCC omitted the image format list from the ATSC standards (Table-3) when adopting the rules for digital television. As a result of this, broadcasters are free to provide signals of any image format or aspect ratio.6 After the first full month of regular over-the-air transmissions by dozens of pioneer DTV stations, it is apparent that 4x3 material will be transmitted with regularity as High Definition signals in both 720 line and 1080 line formats. These signals are typically transmitted as 1920 x 1080 or 1280 x 720 where only the center pixels are active resulting in effective image sizes of 1440 x 1080 or 960 x 720. This was probably not anticipated by the authors of Table-3. Broadcasters suggest that they are not able to, nor authorized to alter the aspect ratio of much of the material in their regular schedule. Yet they wish to upconvert this material to the HD formats. Without any special processing, these "new" formats would be transported on the EIA interfaces as 16x9 images, when they are not. Since the EIA interface standard does not provide a way to convey the aspect ratio tags, a set receiving these signals that conforms to the EIA 770.3 standard, will process them as 16x9 instead.
This is particularly troubling for those sets with a physical aspect ratio of 4x3. If the EIA interface standards are followed, the receiver is instructed to recognize the HD formats as 16x9 even when they may most often be 4x3. On a display with a physical aspect ratio of 4x3, the set will typically default to an underscanning mode to be able to show the 16x9 image. When the signal coming across the interface is actually 4x3, the set will display a severely reduced image with black borders all around. See figure 1 on the next page, where the black letterboxing effect is a result of the 4x3 display operating in the 16x9 mode, and the gray curtain effect is a result of the 16x9 signal only containing information in the center 4x3 portion.
[Figure 1]
Resulting Image |
Ideal Image |
Clearly users may have the ability to override any automatic setting in a set that adjusts for aspect ratio, but operation is very much compromised from a usability point in that case. As the inventors of the standards anticipated, the best operation is when the set can read the aspect ratio instructions in the signal and respond accordingly.
The bits that convey aspect ratio in the ATSC program stream7 are essential to the effective operation of the display and are being stripped by the EIA component interface standards. When the standard is used in a way that strips such bits from the signal, it results in a broken standard. The solution is to restore the communication channel between the demux (decoder) and the display. With such a digital communication channel, the aspect ratio capabilities of the display can be coordinated with decoding functions and format conversion processes resulting in maximum use of the display's capabilities.
As described above regarding aspect ratios, it is clear that products with a variety of display characteristics will appear on the market. These products may be provided with interfaces that conform to the EIA 770.x standards. The same company may also provide matching source devices in the form of tuner-decoders or digital playback devices. When both sides of the interface are supplied by the same manufacturer, they will likely make compatible assumptions about the expected or desirable aspect ratio setting based on the input format. Anticipating problems may occur when other products are connected with the same interface, such a product might include a consumer warning that says proper operation is only assured when like branded equipment is connected on both sides of this interface.
When another product is connected that is fully compliant with the EIA standards that makes different assumptions about the aspect ratio of the display, it may result in images that cause physical harm to the display such as non-linear phosphor aging (CRT burn-in). See figure 2 below:
[Figure 2]
16 x 9 Display | 4x3 Display |
In such cases, it may be found that the liability for such damage rests upon the maker of the "compatible" source device, rather than the display manufacturer.
If an adequate digital communication channel were provided to coordinate the display's aspect ratio capabilities with the decoder and format conversion process, the chances of image burn-in can be eliminated.
Each of the three EIA component interface standards includes tables describing the sync timing for the various image formats supported. A given architecture is suggested by paragraph 8.3 of EIA-770.38 and 9.5 of EIA-770.2 where the source (decoder) side includes controls that can be set to match the optimum input of the sink (display) side. In this case, the source side includes all format conversion processing and converts all image formats to the single selected output format. See figure 3 below:
[Figure 3]
Since a variety of physical display formats may exist in the market for monitors, a very complex set of user controls must be provided in the source equipment. To simplify the operation, three separate controls might be provided with four choices for image size, four choices for frame rate and type and two choices for aspect ratio. This yields 32 possible display configurations, many of which are possible in the market and not identified by the EIA 770.x standards. On the other hand, the types of native display configurations are truly boundless as products with 1024x1024 and 1280x768 pixels have already been announced and other unimagined configurations are likely.
Such a set-up function doesn't account for other qualities or characteristics of a display device. For example, a given display may be optimized to process SDTV material at one scanning rate (480p) and HDTV material at another scanning rate (1080i). Unnecessary image conversion in the STB could result in reduced picture fidelity. Likewise, SDTV signals may default to 4x3 while HDTV may default to 16x9. Such a one-time set-up function can not manage this complexity. To suggest that the user select the optimum output display format manually for each image format is to add unwieldy complexity to the user interface.
Another possible solution to this complexity might be the use of separate "ID-codes" for each brand and model variation that display manufacturers create. This might work in a manner similar to pre-programmed "universal" remote controls that have to control a variety of equipment. To manage this data base and provide reprogrammability to accommodate the constantly changing universe of display types might prove impractical.
One can not expect to build a STB that conforms to EIA-770.x without some solution to the monitor matching problems, even though the complexities of such a solution are not explained in the standards. The only real solution to this quagmire of format possibilities is to provide a supplemental digital communications channel between the decoder (source) and the display (sink). Such a channel could communicate the display characteristics to the decoder so the format converter could be effectively configured to maximize the image fidelity and minimize unnecessary and redundant format conversions.
Issues of Copy Protection
None of the three EIA 770.x interface standards currently include any provisions for copy protection systems as none were known for analog component signals at the time they were prepared. It was assumed that the interface can support suitable analog schemes similar to those used by Macrovision for composite signals.
More recently, C-Cube and Macrovision have proposed analog copy protection schemes at recent Copy Protection Technical Working Group (CPTWG) meetings. This C-Cube system appears much more robust than the original Macrovision system and relies upon a separate digital control signal. Likewise it is easy to imagine numerous analog CP schemes that can be effective when a separate digital control line is available.
The authors of the EIA 770.x standards also recognized the value of such a digital control signal and suggest that it will be addressed at some future date, even though they don't list copy protection as one of the applications.
Without such a digital control channel, it would seem that there is no copy protection system that can exist which provides any level of authentication of the sink device (display or record) with the source device (decoder or playback unit) to validate the copy protection scheme. The solution is to include the supplemental digital communication channel.
Issues of Closed Caption Decoding
There is no mention of closed caption processing in any of the three EIA 770.x component interface standards. There is also no mechanism within the SDTV or the HDTV standards to provide a data channel which might pass the closed caption data signals. There is also no defined way to generate, insert or decode caption data on a 3-wire component interface. Therefore, one must assume that the entire obligation to process all closed caption data resides on the video source (ie.set-top-box), not on the display (sink). In this case the captions are decoded in the source device and overlaid on the video image prior to passage over the component interface.
This is not really a problem, but it could be, if source products are built without realizing they have this additional obligation. Since the "source" device can be a storage product such as VCRs or disk players, in addition to DTV receiver/decoders, it seems somewhat onerous and unwieldy to place such an expectation on all source devices. Conversely, the natural place for such a function is the final display.
In some cases this non-standard approach will result in products that include duplicate capabilities perhaps adding to user confusion. Most of the DTV display products already include NTSC tuners and the requisite EIA-608 caption decoder. Certainly these products will have user controls to activate the captions. However, when an external DTV decoder is used to receive DTV signals (which carry EIA-608 caption data in the user bits) the EIA component interface will strip such data and prevent the DTV display from processing the data with its caption decoder.
Since the stand-alone DTV receiver/decoders do not include displays, they technically aren't required to include caption decoders of any kind unless they are sold as a system with the display. In the system case, there may be separate provisions to manage the caption decoding coherently between the two products of the same brand. But in the mixed brand system, the best case scenario is when both the source device and the sink device are equipped with redundant caption decoders. This only results in a minor irritation to the user since it is confusing to know which button to press to activate the captions. Another case is when the source device doesn't have any caption decoder and it is not possible to use captions when connecting across the EIA component interfaces. But the worst case scenario, is when neither the source nor the sink device have an ability to process DTV captions.
Once again this situation could be alleviated if the component interface called for a supplemental digital communications channel to carry the user bits and caption data to the display which should have final responsibility to generate the captions.
Issues of V-Chip and Content Blocking
There is no mention of content blocking (V-chip) processing in any of the three EIA-770.x component interface standards. There is also no mechanism within the SDTV or the HDTV standards to carry the PSIP Rating Region Tables needed to process content blocking. Therefore, one must assume that the entire obligation to process content blocking (V-chip) data must be managed by the video source (i.e. set-top-box), not the display.
This is really not a problem, but it could be, if source products are built without realizing they have this additional implied obligation. Since the "source" device can be a storage product such as VCRs or disk players, in addition to DTV receiver/decoders, it seems somewhat unlikely to expect that a playback device will include functions to enable V-chip blocking. Conversely, the natural place for such a function is the final display.
Like captioning, the user can also be faced with confusing operation and redundant or absent functions if both or neither of the devices was designed to support the V-chip blocking functions.
Once again, this situation can be resolved if the component interface standard called for a supplemental digital communications channel to carry the PSIP data (RRT) leaving the final responsibility for blocking functions to the display.
Taken as standalone, one-way interfaces used to convey a multiplicity of image formats in the analog domain, the EIA-770.x standards are inadequate to mediate between design choices and implementation variations that naturally occur across brands. These standards also repeatedly violate seven basic design goals of any effective interface standard including:
Broberg's
Seven Habits of Highly Effective Interface Design:
|
The solution to every one of these faults is to add a supplemental, bidirectional, digital communications channel. Without such a channel, the component analog interface standard will continue to cause problems.
CEMA should consider withdrawing the EIA-770.x family of standards and issue an advisory to manufacturers considering implementation of these standards in commercial products. CableLabs may also wish to revoke previous support for such interfaces until solutions are in place to address each of these problems by the use of a supplemental digital communications channel.
REFERENCES:
This article may not be duplicated, reprinted or published in whole or part without express written permission from the author. broberg@ieee.org
If you arrived here by a search engine, please visit my HOME PAGE.
Get your free home page at Geocities