This month's report is on Dirac, CEA standards, OpenCable, and the Broadcast Flag Rule.
TV-B-Gone is a single-function universal remote control. It turns all television sets off. It is a clever product, and it also is a demonstration of the difficulty of remote control standards. It works by sending all known IR codes for turning off a television set in sequence. It takes 69 seconds to send all of the codes. The most popular codes are sent first, so most sets will go off within 17 seconds.
The device (a key-chain) has been surprisingly popular. They sold out their first production run in two days.
BBC Research and Development has developed a video codec called Dirak. Its performance is similar to the performance of AVC and VC-1, but it is Open Source and Royalty Free. I think that makes it extremely attractive because the licensing terms of the other codecs are onerous. A free HDTV codec can be a very good thing. Currently, MPEG-2 is the transcoding standard for Firewire. Dirak could be a superior alternative because it will cause less image scarring.
The competition between AVC and VC-1 has degenerated into an argument over which one is more standard. In this respect, Dirak is far behind.
It will be difficult for existing platforms to take advantage of any of the new codecs. ATSC is locked into MPEG-2, although E-VSB (which will require new tuners) can consider such a change.
The Consumer Electronics Association supports standards development activities. This month I bought copies of CEA-931-B Remote Control Command Pass-through Standard for Home Networking ($61) and CEA-2027 A User Interface for Home Networks Using Web-based Protocols ($66). I strongly disagree with the practice of charging for access to standard documentation. As a promoter of standards, CEA should be encouraging adoption by making the information freely available. By contrast, W3C makes all of its works available on its website, free of charge. ECMA goes even further by mailing printed copies of its standards, free of charge. If I were a member of CEA, I would complain about this.
CEA-931-B and CEA-2027 attempt to solve the Remote Control Problem and the User Interface Problem. These are two very difficult problems in the design of digital entertainment systems.
CEA-931-B (September 2003) uses web technology. It defines controllers and targets. A controller receives proprietary IR codes from a RCU (remote control unit). It can then convert the codes into a standard form and pass them to a target (such as an STB or PVR).
It transmits the codes in the form of a URL using an HTTP GET request.
http://{TARGET}/CEA931/?{OPERATION}
The host address of the target could be obtained by a discovery protocol such as UPnP. An operation can be something like
power_off_function volume_up&press tune_function&9&1
So a television set that receives IR codes can be a 931 controller, which means that it acts like a web client. A 931 target is a web server. They can communicate over any link that supports HTTP, including Ethernet, Firewire, or WiFi.
CEA-2027 (August 2004) takes the web idea further. The television set becomes a renderer and a full web browser. The television set might also contain web servers, representing its tuner, its display hardware, and the UI subsystem. Each of the target devices will also contain one or more web servers. The browser will send GET requests to each of the servers to get their status. They will each return an XHTML document that can contain visible status information as well as a link for getting more information from the device. The browser will collect all of the status documents, displaying them all on the screen in an array of subframes. Using the RCU, the user can open up the detail panel of any device. The detail panel is another XHTML document that provides more detailed interaction. Documents can contain JavaScript programs, allowing for a high level of interactivity. I think JavaScript is better suited to light client applications than Java.
I think that HTTP is one or the worst protocols ever designed, so it bothers me every time I see it being injected into new applications. It is inefficient and has bad realtime characteristics. But it is simple and open and well understood and globally popular. When setting standards, it is better to be popular than smart.
The UI proposed by CEA-2027 is device-oriented, not task oriented. To accomplish a task, you must individually command each device separately. Still, it does allow operation of all devices with a single RCU and that is an extremely good thing.
This architecture also makes the television the center of the universe, since it becomes the user's agent in controlling everything else. It may be possible to create a competitive advantage in having a superior browser implementation. For example, a high-performance JavaScript engine would produce a more responsive system.
CEA-2027 might not get adopted by other manufacturers. I do not know how effective CEA will be in getting the other manufacturers to implement it. It is a new standard, and I have not seen any manufacturers other than Samsung talk about it yet.
Plug and Play is the name of an agreement that the FCC brokered between the Cable Industry and Consumer Electronics Industry. The agreement seems to have grown from a meeting that CableLabs hosted on August 5, 1999 in which work from the OpenCable project was shared with CE companies. Later, on October 28, documentation was formally released, including specification of the Host-POD interface.
The FCC adopted rules on September 14, 2000 that included a three phase plan: Digital Cable Ready 1 (One-way with POD), Digital Cable Ready 2 (1394), and Digital Cable Ready 3 (Two-way). In the FCC's action of September 10, 2003, the so-called Plug-and-Play Order, which details the labeling requirements for Digital Cable Ready, the term "Plug-and-Play" does not appear, although the term does appear on a Consumer Facts Sheet. Neither document discusses a future two-way standard. The term "Plug-and-Play" was adopted by CE and by the Press.
CableLabs did not adopt the term "Plug-and-Play". It does not appear in the standards of OpenCable, nor does the term "Digital Cable Ready". Instead they talk about an "OpenCable Terminal". I think that the Cable Industry never fully adopted the idea of DCR. They shared some of their documentation with CE, but they did not significantly alter their own plans. DCR is not an important part of their strategy. I can't find anything on the OpenCable Member website that looks like a PnP2 Specification or roadmap. I did find a OCAP Digital Video Recorder (DVR) Specification. DVR is a critical technology for Cable which is not included in any definition of DCR.
The term Plug-and-Play originally came from the computer business, and was used to describe peripherals that were compatible with IBM mainframes. The term was later used on PCs to describe the process of discovering and configuring peripherals and accessories.
The FCC adopted the first part of the Broadcast Flag Rule on November 4, 2003. The rule applies to digital tuners (or demodulators). A summary of the debate over the Rule is given, along with the FCC's own reasons for adopting and limiting the BPDG proposal. The FCC's rational is very important when interpreting the technical part of the rule. In particular, the details of the rule should not be read to prohibit behavior which the Commission is explicitly allowing.
We also wish to clarify our intent that the express goal of a redistribution control system for digital broadcast television be to prevent the indiscriminate redistribution of such content over the Internet or through similar means. This goal will not (1) interfere with or preclude consumers from copying broadcast programming and using or redistributing it within the home or similar personal environment as consistent with copyright law, or (2) foreclose use of the Internet to send digital broadcast content where it can be adequately protected from indiscriminate redistribution.
It uses the PSIP Redistribution Control rc_descriptor set forth in ATSC Standard A/65B, excluding the rc_information.
Licensees of TV broadcast stations may utilize the Redistribution Control descriptor...provided they do not transmit the optional additional redistribution control information.
Tuners that never cross state lines are not controlled by the rule. So a non-compliant tuner could be manufactured and sold in California, but it could not also be sold in other states.
No party shall sell or distribute in interstate commerce a Covered Demodulator Product that does not comply with the Demodulator Compliance Requirements and Demodulator Robustness Requirements.
The critical part of the rule is section 73.9004 (a).
(a) A Covered Demodulator Product shall not pass, or direct to be passed, Marked Content to any output except
(1) to an analog output;
Analog output is always allowed. The FCC does not see an immediate solution to the “analog hole” problem, so there is no requirement to restrict analog output. They considered watermarking schemes but did not select one.
(2) to an 8-VSB, 16-VSB, 64-QAM or 256-QAM modulated output, provided that the Broadcast Flag is retained in the both the EIT [Event Information Table] and PMT [Program Map Table];
The output can be in the form of a broadcast signal or cable signal that preserved the flag.
(3) to a digital output protected by an Authorized Digital Output Protection Technology, in accordance with any applicable obligations established as a part of its approval pursuant to § 73.9008;
Section 73.9008 approves the set of technologies formerly known as Table A.
(4) where such Covered Demodulator Product outputs, or directs to be output, such content to another product and such Covered Demodulator Product exercises sole control (such as by using a cryptographic protocol), in compliance with the Demodulator Robustness Requirements, over the access to such content in usable form in such other product;
This allows for sending material around the home over a secure proprietary link.
(5) where such Covered Demodulator Product outputs, or directs to be output, such content for the purpose of making a recording of such content pursuant to paragraph (b)(2) of this section, where such content is protected by the corresponding recording method; or
This allows for making a recording with one of the approved recording technologies.
(6) where such Covered Demodulator Product is incorporated into a Computer Product and passes, or directs to be passed, such content to an unprotected output operating in a mode compatible with the Digital Visual Interface (DVI) Rev. 1.0
Specification as an image having the visual equivalent of no more than 350,000 pixels per frame (e.g., an image with resolution of 720 x 480 pixels for a 4:3 (nonsquare pixel) aspect ratio), and 30 frames per second. Such an image may be attained by reducing resolution, such as by discarding, dithering or averaging pixels to obtain the specified value, and can be displayed using video processing techniques such as line doubling or sharpening to improve the perceived quality of the image.
A computer with a DVI interface that does not have HDMI capability must downrez the program to EDTV resolution. This seems to punish owners of older monitors. Broadcast Flag programs will look bad to these people. (6) seems to be about Computer Products, but I think it is really about pre-HDMI DVI, and about insecure digital outputs in general. The FCC is not trying to dictate computer designs. It is attempting to describe restrictions on content redistribution. It does not make sense that a computer could have more or less privilege than any other device. Taking this further, I think that downrezzing is generally allowable in the case where none of the other options are effective. I think the FCC would prefer that a consumer would get a degraded signal than a blank screen in the case were no content protection is available. Their intention is to prevent mass indiscriminate redistribution of high value digital content, not to frustrate early adopters with older equipment.