At 6:30 PM -0400 4/29/05, Manfredi, Albert E wrote: >This goes back to these comments: > >> As we told the FCC back before 1995, they only needed >> to do two things. >> >> Choose a modulation standard and a transport stream >> standard. Everything else can be driven by the >> marketplace. >> >> The analogy to this is Ethernet and TCP/IP. > >XML didn't exist in 1995, but something was needed >regardless. Once again Bert takes things out of context. In the 1995 context, the referral to a transport stream standard implied two things: 1. A standardized way of packetizing the data that is carried by the systems; 2. The uses of headers and descriptors to identify the contents of the packets. These issues were discussed extensively inside of the ACATS process (which recommended the same) and in the ATSC, which eventually adopted the MPEG-2 transport stream and a bunch of proprietary header/descriptor garbage which most vendors still do not implement properly . Hence the high level of list traffic about PSIP, Directed Channel Change et al). Ten years later the marketplace HAS come to understand the important role of metadata as it relates to the delivery of all kinds of information via digital networks. During that time the SMPTE has developed parallel standards for the video industry, but their efforts were too little too late, and narrowly defined for a vertical industry market. The SMPTE MXF standard is implements in the equipment from several vendors, but many others are using XML. XML has emerged as the marketplace standard for the handling of metadata, and companies are scurrying around writing filters to convert MXF into XML and back. You see Bert, the marketplace really does work. It is the efforts of industries that are seeking to build walls around their little empires that cause most of the headaches. The ATSC standards may become a case study in futility for the next generation of Harvard MBAs. It is also worth noting that the requirements for a one-way broadcast network versus a two-way IPTV network are NOT the same. As Kon points out, you can burn up significant bandwidth using the network to pull data that should be pushed to every receiver. With a broadcast network there is little choice - although it is possible to use a back channel to send requests for data, it is far more efficient to push data and let the receivers filter out what they need. For IPTV networks the same rules still apply to some extent. It is more efficient to broadcast the stuff that everyone needs, and pull the private stuff. Thus these system use IP multicast on the backbones and routing close to the home to select the streams for individual users. I'm quite certain I could find several megabytes of messages from Bert trying to teach us all of this a few years ago... Regards Craig ---------------------------------------------------------------------- You can UNSUBSCRIBE from the OpenDTV list in two ways: - Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word unsubscribe in the subject line.