June 96 - Connecting Users with QuickTime Conferencing
Connecting Users With QuickTime Conferencing
DEAN BLACKKETTER
QuickTime Conferencing (QTC) is a new Apple technology that helps
developers add real-time sharing of sound, video, and data to their
applications. This overview suggests the different ways you can
use QTC to help users collaborate. The article describes the
components that most developers will need to use to take
advantage of QTC and discusses Watcher and Caster, two QTC
applications that enable users to tune into network broadcasts and
create broadcasts for others to view.
Video telephones abound in science fiction movies. From Buck Rogers to Star Trek,
visions of the future show people communicating visually over long distances. This
futuristic technology is available to Macintosh developers and users now. QuickTime
Conferencing provides a platform for developers to easily enable users to share sound,
video, and data across a variety of networks.
QTC ships with selected Power Macintosh computers and with some hardware bundles,
and can be licensed by developers to ship with their applications. Apple provides a
basic videoconferencing application, Apple Media Conference (AMC), and developers
are encouraged to create QTC applications that interoperate with AMC and add cool new
collaborative features.
This article will give you background information on the QTC architecture, tell you
about the components that make up that architecture, and then describe in detail the
workings of two simple QTC applications, Watcher and Caster, that enable the user to
watch audio and video and to broadcast them onto a network. This issue's CD contains
the source code for these applications as well as the QTC documentation and the
extension and header files.
QUICKTIME CONFERENCING -- THE BIG PICTURE
QuickTime Conferencing provides a platform for building Macintosh applications that
can send and receive audio, video, and data between computers connected on a network.
QTC supports basic two-way audio communication and a video "telephone" type of
connection, and it supports a wide variety of other models as well. One of the goals of
QTC is to provide developers with a set of tools that make it easy to add real-time
media sharing across a number of different kinds of networks.
This opens up the possibility of adding sound and video to multiuser applications
where it would have been prohibitively difficult before -- and these don't have to be
conventional telephony-style applications. Imagine a flight simulator that allows you
to talk with your fellow squadron members, or a groupware document-markup
application that lets your fellow editors see your expression upon examining the latest
changes. Picture a regional educational system that enables dozens of students to tune
into an 8 A.M. lecture from their dorm rooms across campus or across the state. This
isn't the stuff of science fiction anymore.
QTC uses many of the services provided by QuickTime itself and shares an
architectural basis in the Component Manager. QTC takes advantage of the Image
Compression Manager for video compression and decompression, the sequence grabber
components for capturing media, and the Movie Toolbox for recording movies to disk.
When new features and improvements are added to QuickTime, they often can be used
by QTC immediately. For example, components created for video or sound compression
in QuickTime are automatically available to QTC.
CONFERENCE CONFIGURATIONS
QTC's basic metaphor for real-time media connections is that of a conference.
Conferences are quite flexible and can be configured in a variety of ways. They can
have one, a few, or many members, connected symmetrically or asymmetrically. As
illustrated in Figure 1, connections can take one of three forms: point to point, for
two-way conferences; multipoint, for virtual meetings and groupware applications; or
broadcast, for transmitting from one member to many others.
Figure 1. The three types of conference connections
Members can send or receive sound, video, or data. Media types can be added, removed,
or changed during a conference. Members can join or leave a conference at any time.
Conferences can be merged, and data can be sent to one or all of the conference
members.
Depending on the application, you may want to give users a single configuration --
say, a two-way audio and video connection -- or allow them to modify the conference
configuration themselves. QTC was designed to support a wide variety of conference
configurations and to leave it up to developers to decide which features they need.
Indeed, some applications may need to switch between different configurations within a
single conference. The applications described later in this article each operate in a
single configuration; one can broadcast video and sound to an unlimited number of
recipients and the other can tune into one or more broadcast conferences.
NETWORK, PROTOCOL, AND MEDIA INDEPENDENCE
QTC is network, protocol, and media independent. This means that applications don't
have to know the specifics of a particular network to set up a QTC conference. QTC
1.0.2 ships with support for TCP/IP and AppleTalk networks; third parties and Apple
are working on adding new networks like ISDN, isoEthernet, and ATM to the list. QTC
1.0.2 supports a new media-oriented network protocol, called MovieTalk, but can also
support other media protocols such as the ITU H.320 standard and the emerging
standards used on the Internet Multicast Backbone (MBONE).
The media that flows between conference members is organized into one or more
streams of a particular media type. QTC 1.0.2 supports sound and video streams,
which can be compressed with any sound or video compressor. Future versions of QTC
will be able to support other media types, such as music and text, to parallel the
different track types that can be stored in a QuickTime movie.
THE CONFERENCING EXPERIENCE
QTC provides some of the basic user interface elements called for in a conferencing
application. For example, each member of a conference can be represented on the
screen with a stream controller, in much the same way that a QuickTime movie
controller provides a control representation for a QuickTime movie. In fact, the
stream controller and the movie controller share a similar user interface, so that a
user who has some experience with one can apply that knowledge to the other.
QTC also provides a standard user interface enabling users to choose who to call and
include in a QTC conference, in the form of browser components. Browsers work a bit
like the Standard File Package that allows users to open and save files: they provide a
standard interface for choosing fellow users or searching through PowerTalk catalogs
to find other conference members and place calls to them.
QUICKTIME CONFERENCING COMPONENTS
QTC, like much of QuickTime, is built of Component Manager components. Apple
provides a basic suite of components that enable the user to share data and send and
receive compressed video and audio on a few different networks. Before we dive into
our example applications, let's go over some of the component types that make up the
QTC component suite.
There are three main types of QTC components that most developers will need to know
about to add QTC support to their applications: the conference component, the stream
controller component, and the browser component. I'll describe these in some detail.
Developers who want to do fancier things will probably need to know about some of the
other components; the key ones are briefly described later.
Because of the modular architecture of QTC, developers can add, extend, or replace
features and components. For example, a developer who wants to add support for a new
network multimedia protocol can create a new transport component and register it
with the Component Manager. Applications can then find that component and specify its
use in a conference. Developers who want to improve on the QTC stream controller can
capture the standard controller, delegate many of the functions, and replace the ones of
interest.
THE CONFERENCE COMPONENT
The conference component is the key player in a QTC conference. It acts as a central
hub and does the bulk of the work required to orchestrate the comings and goings of the
conference. It's responsible for listening in on the various networks, placing and
answering calls, managing and merging multiple conferences, and more. The
conference component can also provide some higher-level functionality, such as
setting up media capture, handling user events, and even creating and managing
conference windows.
Applications create a conference component instance and let the conference component
do much of the work needed to create, manage, and end conferences. Applications can
then tell the conference component to listen on the networks for incoming calls or to
place a call to another member.
Conference components create conference events when they need to express some
change in a conference to the application. For example, when an incoming call is made
to a conference, the conference component will generate an event of type
mtIncomingCallEvent to notify the application of the call. Applications call the
component routine MTConferenceGetNextEvent periodically to get the events from the
conference component, much as applications call the system routine WaitNextEvent to
get user and system events from the Event Manager.
In response to these conference events, applications work with the conference
component to respond appropriately -- for example, creating a window to display a
new conference member or send messages to other conference members. Details of
working with the conference component will be discussed later when we look at our
sample applications, Watcher and Caster.
THE STREAM CONTROLLER COMPONENT
Stream controllers are responsible for handling the default user interface for
controlling QTC media streams as well as managing their display on the screen and
through the speaker. The conference component is responsible for creating and
managing stream controller components. Applications are passed references to the
stream controllers by the conference component so that they can keep track of where
and how the media is being displayed.
The standard stream controller looks quite a bit like the standard QuickTime movie
controller, with buttons to control the flow of media, resize the visual portion of the
stream, and adjust the sound levels. The stream controller adds some utility buttons
that the movie controller doesn't have: a snapshot button for capturing the current
image displayed in the controller and a record button that provides a standard way for
a user to record the media in a stream controller. (The conference component or the
application is responsible for actually handling the snapshots or recorded movies after
the controller has initiated them.)
Controllers associated with the sending side of a media stream (known as source
controllers) have a slightly different appearance and behavior from those associated
with the receiving side (known as sink controllers), as shown in Figure 2. The source
controller may have a microphone "gain" button that's animated to indicate the level of
the audio being sent across the connection. Users who click this button can adjust the
volume of the sound being sent across the connection. On the receiving end, the sink
controller may display a volume control button that behaves like the speaker button on
the standard movie controller, allowing the user to adjust the volume of the incoming
stream.
Figure 2. Source and sink controller user interfaces
THE BROWSER COMPONENT
To place a call or add another member to a conference, the user needs to specify the
other member to call. Browser components provide a simple way for users to browse
the network and identify other members. Browser components come in two flavors:
network-specific browsers and the PowerTalk browser. The PowerTalk browser and
browsers specific to TCP/IP and AppleTalk are shown in Figure 3.
Figure 3. Browsers
For each different network type -- such as TCP/IP or AppleTalk -- unique browser
components are provided that allow the user to specify a network-specific address. For
example, as shown in Figure 3, the AppleTalk browser presents the user with a
Chooser-style interface whereby the user can choose the zone and then the registered
name within that zone on an AppleTalk network, similar to using the Chooser to pick a
LaserWriter on an AppleTalk network. The TCP/IP browser provides a simple type-in
interface that can accept TCP/IP addresses in numerical or text form.
The PowerTalk browser, on the other hand, is considered a generic or universal
browser, not tied to a particular network or addressing scheme. Users who have
PowerTalk installed can take advantage of the various PowerTalk catalogs and business
cards; these provide an integrated way for users to organize and find other QTC users
in the same way that they access electronic mail addresses via PowerTalk. The
PowerTalk browser allows the user to choose a business card from a PowerTalk catalog
that contains a QTC entry (provided by the QTC PowerTalk Template). This works for
local user catalogs and catalogs provided by PowerShare servers, as well as the
generic AppleTalk network catalog, which allows the user to look out onto the network
and into AppleTalk zones for other users. Users can edit their personal catalogs from
within the Finder, consistent with the standard PowerTalk human interface.
______________________________
ABOUT APPLETALK MULTICAST
Digital video and sound can generate a great deal of data, even when
compressed. Hard disk space is getting to be quite cheap, but network
bandwidth is still an expensive and shared commodity. To keep your fellow
users and network administrators happy, we developed multicast extensions to
AppleTalk that allow a single copy of QuickTime Conferencing media sent out
onto a network to be received and displayed by any number of users.
AppleTalk Multicast consists of a special packet format and a routing protocol
that makes efficient use of the network bandwidth. On a single network
segment, AppleTalk Multicast uses multicast packets that can be received by
anyone on that local network. On an AppleTalk internet, multicast-aware
routers communicate with each other with a new protocol called SMRP, the
Simple Multicast Routing Protocol, as shown in Figure 4. The routers deliver
copies of the media data only to other networks in which there's a user who
wants to receive that data. Networks with no users interested in the broadcast
aren't burdened with the network usage.
Apple has licensed AppleTalk Multicast and the SMRP protocol to Cisco
Systems, Inc. Cisco's router software as of version 11.0 supports this
multimedia protocol.
Figure 4. AppleTalk Multicast routing
______________________________
OTHER QUICKTIME CONFERENCING COMPONENTS
QTC defines and uses many other kinds of components besides the three just mentioned.
Several of these component types may be of interest to developers who want to add
support for new networks or new media protocols; others may be of use to developers
who want to have more control over their conferences. Some of these are listed here.
• Stream director components are responsible for managing the media
streams that flow between conference members. Stream directors are of two
types: source stream directors and sink stream directors. Source stream
directors work with media sources, such as QuickTime sequence grabbers, to
capture audio and video data to be sent across the network. Sink stream
directors are responsible for setting up and displaying incoming media data: