After approximately a century of radio and a half-century of television, broadcasting is about to enter a new era - an era of data distribution, software, compressed video, interactive elements, distance learning, intelligent agents, and inexpensive program origination. Reception will be available nationwide from the first day of service and will include customized, subscription, impulse-access, proprietary, and public programming. OOP techniques will be a fundamental component of the delivery system, system management, user interface, and a large number of new types of broadcast services not previously possible.
This and other processor-based communications systems will result in a fundamental paradigm shift in the software industry from single static applications to smaller components: standardized and custom dynamic, interactive, intelligent, and even disposable components. Emphasis will increase on robust software and on system design that can handle diverse and anomalous conditions.
Some of the history of this system is discussed along with the evolution that occurred from dedicated analog hardware to object oriented software. Aspects of this particular system are described and example software implemented in C++ MacApp is discussed.
ACE's system design draws on a variety of disciplines including video compression, dynamic multiplexing, high-speed demodulation and re-synchronization, remote uplink synchronization techniques (similar to that used on some military satellites), error correcting codes, live on-line object-oriented databases, encryption, indexed indirect service access, and object oriented multimedia software. As such, it will be able to deliver the usual compliment of cable TV video fare, digital radio, wide-screen video, HDTV and computer file downloads, but also many new types of object-based digital broadcast services.
Educational course broadcasting will be a major beneficiary of the OOP approach. These combined techniques will allow course delivery to be two to three orders of magnitude more efficient, less costly, and more service-prolific than would otherwise be possible. For example, the two transponders being donated by ACC to the Foundation for Educational Advancement Today will be able to simultaneously carry literally hundreds of courses where only two would have been possible previously, and 10 to 20 using only video compression. At the same time, the provided video quality will be vastly superior because much of it will be generated locally by the receiver processor from received data and software objects and can be displayed on as normal or HD TV screen or on a personal computer with a non-interlaced screen.
In addition, a new multimedia OOP element will make local interactivity possible in the broadcast environment. Software objects used for generating screens and animations will allow user interaction, user individualization, automated response collection, and return link communication by telephone line modem, VSAT, cellular systems, etc. (see Figure 1). InterBroadcast Satellite System activity can range from a simple screen button that beeps to animated coloring books for children and medical students (want to see my brain anatomy coloring book?) to sophisticated laboratory experiment simulations. The persistence of these objects can be controlled absolutely or conditionally. They can be forced to self-destruct after a specified time, be copy controlled, or allow copying and off-line use. They can also be used in conjunction with locally available required or optional resources such as course-specific or general-reference CD-ROMs.
Needless to say, success of this and related systems will open vast new markets for new types of software, software components, authoring tools, and content providers. Of necessity, emphasis initially will be on completing development of the system, development of authoring tools and demonstration software. However, a goal is to make it possible for a not-terribly-computer-literate teacher or professor to be able to do a live nationwide course broadcast without ever leaving the office. A personal computer, pen pad, and an inexpensive TV camera should be all that is minimally required. A LAN could connect to the campus or office-complex uplink or an ISDN link could connect from a home office. This could totally eliminate expensive studio facilities, equipment, and trained personnel presently required for most distance learning.
What I hope to accomplish here is to give you a some indication of both the importance of object oriented programming as an integral element of this system, and to indicate the directions that I believe the software technology and markets will be going as a result of these new interactive capabilities and distribution channels.
A few years later at Bell Labs we developed for Picturephone what was probably the first commercially-targeted video compression codec using intra-frame and frame differential conditional replenishment techniques. Transform techniques were still out of the question by at least several orders of magnitude in cost and capability. However, one of the significant techniques that evolved out of this project was that of dynamic multiplexing, a technique that would later be extremely important in OOP-based DBS.
During the CBS project was when I started to seriously consider the ramifications of a universal digital broadcast system and promote its utility. As part of the project, at an oral presentation to CBS headquarters, I tried to convey my excitement for the concept that digital broadcasting had implications that went far beyond standard television or even HDTV. It was soundly dismissed as just being more video-text in which they had recently taken a financial bath. I protested that we were talking about 10,000 times the delivery capacity of the toy that had been tried, but it fell on deaf ears. The cable and VCR boom was just beginning - and the Macintosh was yet to rise from the ashes of the Lisa. CBS completely pulled out of DBS, leaving a vacuum that was to later pull me in again.
Around 1985 I started developing the concept of broadcasting to computers (including voice channels) as a means of very inexpensive, low-bit-rate, live course distribution. I also recognized that with frame differential coding, video courses which consisted mostly of stationary slides, blackboards, etc. could sustain much higher levels of video compression, especially in a dynamically multiplexed environment where high bit-rates could be delivered in short bursts when needed. To promote such educational uses, with the help of the (now late) Hon. Wilbur D. Mills, the Foundation for Educational Advancement Today was formed and its operational arm was dubbed "Your Educational Services Networks". Yes, Bill Clinton and his people are aware of it and the present Governor has seen some of our Macintosh presentations and demos, for all that's worth. Mills even got us in for a presentation to President Bush, but that was even less productive. Well, nobody said either life or innovation were going to be easy.
I got involved with the Macintosh and decided to learn OOP. I quickly recognized that OOP, its structure, its polymorphism, and its messaging model could provide much of what I had been looking for in reusable, flexible, and disposable components and could provide encapsulation of many other functions. A flexible modem simulation program that I had originally done on the PC was direct-ported to the Mac and later updated to be a full fledged Mac Program. We also converted a PC DSP card to Nu-Bus for use on the Mac and a graphical block-linked interface was done in MacApp.3 It was this project that made me fully grasp the power of using OOP to encapsulate both hardware and software functionality. I only wish I had known about OOP when having discussions with RADC4 and others about the need to do military communications systems initial designs with tools that were independent of hardware/software decision tradeoffs.
For the DBS system we had already planned to transmit software, drawing primitives, and commands to implement the planned features, especially the course broadcasts. It didn't take long to figure out that OOP was a natural for this system. A reasonably rich set of known object classes could be built into receiver ROMs and be augmented by downloads when needed. The dynamic nature of pointer-based objects would allow objects to be queued up and transmitted in advance of when they are actually needed. Code modules for new object types could also be downloaded and dynamically linked to existing code. These could then be flushed out of the receiver when no longer needed, freeing receiver memory for new incoming objects and code.
However, there are significant differences between a closed-loop computer system and an open-loop broadcast system. Ideally, the transmitter would know the basic state of the receiver, what objects it contains, and how much receiver memory is available. As a practical matter, transmission could be interrupted, object data and commands could be corrupted by bit errors, users would not always be on-line at the beginning and might want to switch between on-going services, and worst of all, there is no quick-response return path for the source to know what is happening at the destination receivers. Also, when was the last time your television crashed? We believe we have acceptable solutions for each of these issues, but it will take real field testing to make sure that all the problems have been addressed and adequately solved.
There is a lot of interest today in networks, cable, fiber, and on-line multimedia server systems. The nationwide capital investment required for these systems is enormous, in the hundreds of G$. It will also take 20 years or more to become available to 60-70% of the population. In contrast, ACC's DBS can be universally available within two years at a cost of a few hundred M$, approximately 1000 times less than alternatives. We could afford to spend some of those excess G$ on software programmers and content providers.
Our job as a service provider will be mainly to manage delivery of a large number and mix of fixed, variable data rate, and bit-packet services. Live on-line output can be provided through the receiver to computers and other devices. A goal is to keep the delivery system as open and flexible as possible to accommodate third party services.
Most systems must uplink all of one transponder's signals from a single location. This system uses proprietary techniques to allocate a transponder's capacity between diverse uplink locations. That is of particular advantage when using lower-data-rate OOP-based educational broadcasts. However, statistical (dynamic) multiplexing efficiency is best when several services are combined before uplinking. For example, a college campus could combine several courses on an Ethernet LAN or local fiber and use a single uplink into a portion of one transponder.
It is not possible to even begin to describe the new service possibilities in this article. CDI, TV Answer, a myriad of educational software programs, and the recent 3DO demos at CES give a tiny glimpse of the possibilities. The important thing is that inexpensive locally interactive broadcast capabilities will open new markets for inexpensive, widely disseminated, disposable software, i.e., the stuff that OOP, C++, maybe Bedrock, Taligent, and Kaleida are about.
HyperCard also has much appeal, mainly because of its scripting and elimination of dealing with the infamous compiler/linker cycle. Of course, for this convenience we paid a dear price in performance. Another innovation of HyperCard was the Xcmd. It provided a standard interface for addition of code modules that could greatly expand HyperCard's capability. The interesting thing is that this spawned development of software on the other side of the interface so that Xcmds designed for HyperCard could be used with other programs, Real-Time Presenter being one of them. HyperCard has been reabsorbed by Apple Computer and will be integrated with AppleScript. It is also rumored that version 3.0 will be a complete rewrite in C+. This bodes well for HyperCard's future utility in this type of broadcast environment.
I am not going to go into details of Real-Time Presenter here because I cannot do it justice in one article. Also, there has been some discussion of serializing it to illustrate MacApp programming techniques. I will discuss how it relates to the broadcast system.
The program is designed as a presentation program but will be carried to several levels. The intent is to initially marketed it as a stand-alone presentation program. Its ultimate application is in the DBS broadcasting system. In the two cases, its functionality will seem identical to the presenter and the presentee. However, its internal use of the delivery system will be radically different, transmitting software objects in place of most video.
At each level from Session to Clip there are complete list manipulation capabilities including disjoint multiple selection, cut, copy, paste, duplicate, clear, and drag-and-drop reordering.5 There are drawing6, text7, and manipulation tools. One feature that has recently been added is the ability to drag-copy objects from one window to another. Navigation palettes also allow moving through and editing the lists (see Figure 3). The intent is for the presenter to have at least two monitors, the public presentation monitor and the presenter's private screen. The private screen might be on a PowerBook and the presentation screen on an external projector. The program can do more than one presentation at a time if multiple monitors are available.
A video control palette (see Figure 4) is available and is designed for quick selection of video size and position by clicking on preset frames. When active, live video overlays whatever else is on the screen. A MacApp object class presently supports all features of the RasterOps 364 and 24STV boards. We hope to include the Radius VideoVision soon. Images can be grabbed to the clipboard in any selected bit-depth from 1 to 24-bits and pasted into any presentation screen.
A key feature of the program is the ability to plan and monitor presentation progress. Time can be estimated for each component, clip and segment so that the entire session can be planned to fit the allocated time (e.g., one hour on a satellite link). Progress is monitored and visual feedback is given in real-time to the presenter along with alarm status if dangerously off-schedule.
Although the program can be used for presentation on a computer monitor or data projector, it can also be used for standard TV video transmission whether using analog or compressed digital transmission.
Objects can be time stamped and queued for low-priority (can you say "cheap") space-available transmission. If the presenter dallies excessively, some objects may become stale and have to be retransmitted to placate the latecomers and channel flippers. Commands can be intercepted and sent in real-time to the receiver. A video rectangle can be sent when required to indicate screen location of live video. Compressed video and audio will be transmitted with minimal delay. The basic scheme can be further refined but this should convey the general approach.
If an object resource is not present in the receiver buffer (e.g., an airplane blocked the link) the basic presentation program at the receiver should be robust enough to do something benign. Each object will have an integrity verification check sum.
What we have done is eliminate the middle men, the QuickDraw calls, the screen bitmap (pixmap), the image coding, image decoding, etc. We let the receiver do most of the work of image generation. That is why much course presentation material can be sent more efficiently than with video compression and still generate presentation screens that are superior in image quality. The same is true for animations and other processor generated images.
We wish to initially give instructors familiar tools that do not require radical changes in instruction techniques. This way, they can ease into use of newer tools such as interactive math graphing and simulations. An instructor can demonstrate a software module and then hand it off to the remote students for local or off-line use.
Obviously, the receiver memory is finite, but will get less expensive and more plentiful with time. Management of memory resources and receiver object data bases will be very important, but should be transparent to the program originator and user. An educational program may require additional RAM which can be obtained by installing a PCMCIA card or by purging other data. Many receiver options will be available. If the user wants QuickTime previews of available movies, he may have to add a hard disk.
The (C++ MacApp) Real-Time Presenter program is an operational framework to encapsulate and control a large number of software presentation modules. New modules can be added and existing ones can be encapsulated and controlled. Demo versions of other software could be downloaded and used for training. License free run-time versions of other programs could also be included. Although many software objects and modules will be flushed through the system and disposed when finished, the basic objects can be used over and over again in the same or different context. "Disposable software components" does not mean "throw away" software any more than television means "throw away" movies. But it is certainly a shift in thinking from static applications to dynamic software components.
