Summer 91 - QUICKTIME 1.0: "YOU OUGHTA BE IN PICTURES"
QUICKTIME 1.0: "YOU OUGHTA BE IN PICTURES
GUILLERMO A. ORTIZ
QuickTime is Apple's new architecture for enabling the Macintosh to handle time-
based data. The recently introduced QuickTime 1.0 makes it easy for you to add dynamic
media like video and sound into your applications--and that's just the beginning. Two
sample programs show you how to do the two most basic (and important) QuickTime
tasks: playing existing movies and creating new ones.
The world isn't standing still--it's moving,fast --and Apple intends to stay at the
front of the race. When Apple came out with the Lisa® and then the Macintosh, the
idea of a document file that mimicked a piece of paper was a big deal. But now it's not.
Users have taken the "paper" metaphor for granted and are now looking for new
metaphors that increase their ability to communicate. One way to do that is to allow
documents and applications to contain and display data thatchanges .
QuickTimeTM is more than just the ability to record and play back movies--it's a
fundamental addition to the Macintosh Operating System. Just as QuickDrawTM gave
the original Macintosh the edge of sophisticated graphics in 1984, QuickTime will give
the Macintosh another edge over other computers: thebuilt-in ability to handle data
that changes with time.
Until now, the Macintosh Toolbox has not provided a standard way of dealing with
dynamic media, and some developers have come up with their own solutions, especially
in the areas of video and sound. Unfortunately, this has resulted in confusion and a lack
of standards and basic system support for these data types. Apple has created
QuickTime to provide a standard way of dealing with data that changes with time. Even
more important, QuickTime gives you the necessary support software so that you can
spend your timeusing new data types instead of designing, implementing, and
maintaining them.
QuickTime 1.0 works on all color-capable Macintosh computers running Color
QuickDraw (models with either a 68020 or 68030 processor) and either System
6.0.7 or System 7.0; a later version will add QuickTime support for monochrome,
68000-based Macintoshes. As a result, you, the developer, can take it for granted that
QuickTime will be available onany Macintosh running your software.
QuickTime 1.0 makes it possible for your program to manipulate the audio/video
sequences we callmovies . (The size, duration, and quality of the average movie largely
depends on how much disk space you have for movie files.) It also includes routines for
the compression and decompression of still and dynamic images (which should
encourage you to use color images without worrying about how much space they take
up).
The result of all this is something that you'll like very much: applications and
documents that give users a richer experience with your product than they can get
with non-QuickTime Macintosh applications or applications on other platforms.
QuickTime will make possible a new generation of Macintosh software and hardware
solutions that until now have been available only using expensive and narrow-purpose
hardware.
ENOUGH MARKETING STUFF! NOW THE DETAILS . . .
QuickTime 1.0 contains the following parts:
• Movie Toolbox . This contains the calls needed for playing and recording
dynamic media. It communicates with the necessary components for the type of
media being used.
• Component Manager . Previously called the Thing Manager in internal
circles, this piece of QuickTime provides a high-level interface that allows
applications to communicate during run time with a collection of software
objects. These components, affectionately called Things, provide a variety of
functions. At present, these functions include image compressing and
decompressing, movie data handling, video digitizing, and playback
controlling.
• Image Compression Manager . This tool handles the interaction among the
components that compress and decompress image data. Its services are
available both for movie making and playing and for the compression and
decompression of still images.
MOVIE TOOLBOX
The basic component of QuickTime is themovie . At its highest level, a movie contains
one or more tracks , each of which points to data of one type (see Figure 1). A movie
also includes its time scale, duration, size, location and poster information, current
selection and insertion point (if any), preferred volume, image scaling and positioning
matrix, and other information (more on this later).
Figure 1 A Movie and Its Tracks
A movie contains any number of tracks (it's true that a movie can have zero tracks,
but that's kind of a boring case). Each track has amedia associated with it, which points
to the "raw" data that the track draws from when it plays. Other track parameters
include time scale, duration, time offset within the movie, audio volume, and track
type. Thetrack edit list is the list of media subsegments that define the track's output.
Each media references a file that contains its raw data; the file can be any place you
can put a random-access stream of data--it can be in the file containing the movie, a
nearby file, or even a file elsewhere on the network! If more than one media in the
movie references the same data file, the different types of data may be interleaved
within the file.
As Figure 2 shows, each media is associated with exactly one track and vice versa.
Because the track can map nonlinearly to the media (as is the case in Figure 2), you
can edit a movie by simply changing a few pointers rather than having to move large
pieces of data around. Two or more tracks can be members of a movie'salternate group
; when the user picks one of these tracks to be active, QuickTime does not use any of
the other alternate tracks.
Each media references "raw" data of one type--for QuickTime 1.0, either video or
sound. It also contains its duration, time scale, priority, language, quality, media type,
and handler. The media handler knows how to play back its data at the right time.
best conveying the spirit of the movie. You can think of it as the frame you would like
to show if motion were not possible--for example, when printing the document that
contains the movie. The poster is usually a frame from the movie the user sees, but it
can be an arbitrary frame from a video track that is not visible in the normal movie.
Figure 2 Basic Components of a Movie
Note that although a preview is associated with a movie, the data (frames) associated
with the preview may not be part of the movie the user sees. In movie terms, the track
associated with the preview may not be part of the regular movie playback.
Although in the normal situation a movie file contains the data for its tracks (in which
case it's called self-referenced data ), it's possible for the data associated with a media
to reside in a file separate from the movie, anywhere on the network.
Future releases of QuickTime are expected to extend the referencing capabilities of
media to allow for data being acquired as the movie plays along--as, for example, data
coming from a CD player or a video digitizer board.
To recap: A movie may contain any number of tracks. These tracks do not need to be
playing at the same time, and as a matter of fact, a track doesn't need to become active
at all. Several tracks can belong to a movie's alternate group, and only one of them can
play at a time.
COMPONENT MANAGER
One very important architectural feature of QuickTime 1.0 is its extensibility. Let's
take a video track as an example. When the Movie Toolbox (the subset of QuickTime
that deals with movies) finds out it needs to play back this track, it calls the video
media handler (which is a component). The handler in turn calls the Image
Compression Manager, telling it the type of compression used. The Image Compression
Manager then calls the Component Manager to find out if a corresponding decompressor
component is available. If so, the Image Compression Manager can use this component
without having to know all the details about the particular decompressor component
needed. Of course, this is just one example; several different compression and
decompression techniques are available, and the Component Manager allows the caller
to choose a certain type of component by supplying additional information about it.
Let's study the decompressor component with subtype 'rpza', which has the following
structure:
ComponentResource:
ComponentDescription /* Registration Parameters */
componentType: imdc
componentSubType: rpza
componentManufacturer: appl
componentFlags: 0x00000447 /* binary 0100 0100 0111 */
componentFlagsMask: 0
resourceSpec /* resource where component code is
found */
type: cdec /* the code is in a resource of type
'cdec' */
id: 0x000A /* with id of 10 */
resourceSpec /* resource with name string */
type: STR /* 'STR ' resource */
id: 0x000B /* with id of 11 */
resourceSpec /* resource with info string */
type: STR /* 'STR ' resource */
id: 0x000B /* with id of 11 */
resourceSpec /* resource with icon */
type: ICON /* 'ICON' resource */
id: 0x000B /* with id of 11 */
The registration parameters allow the Component Manager searching for a component
of type 'imdc' (image decompression) to narrow the search to a component of subtype
'rpza', made by 'appl' (Apple Computer, Inc.). The parameters include the
componentFlags and componentFlagsMask fields, which help determine how to search
for a given component. Note that the subtype field can be omitted if no more
information is considered necessary for the type of component in question.
For example, the componentFlags field in the example above indicates that the
decompressor can do the following:
bit 0 scale on decompress
bit 1 mask on decompress
bit 2 use matrix for blending on decompress
bit 6 spool (used for compression and decompression)
bit 10 do fast dithering
The cleared bits have meaning, too. For example, the cleared bit 3 means that this
component cannot use a matrix for the placement and scaling of the decompressed
image.
The ComponentResource (shown above) also contains the type and ID of the resource
where the code that performs the actual work is located. In addition, it contains the
type and ID for resources containing the name string, info string, and icon associated
with the component.
In short, the Component Manager can help applications access certain services by
function rather than by name; Figure 3 shows how an application can call the
Component Manager to interact with different types of components. When an
application registers a component, it's guaranteeing that the component supports the
basic set of calls defined for the type. This enables applications to find components by
their function without having to know exact names or locations.
COMPRESSION AND DECOMPRESSION
Following the basic concepts of the Component Manager, the Image Compression
Manager provides applications with a common interface to compression and
decompression "engines" that's independent of devices and drivers. Figure 4 shows how
the Image Compression Manager interacts with the Movie Toolbox, the Component
Manager, and the application.
The services provided through the Image Compression Manager allow applications to
compress still images as well as sequences of images (such as those found in video
track media). In the case of image sequences, the Image Compression Manager also
provides optional support for thedifferencing of frames--that is, storing only the
pixels that differ from the previous frame to reduce the size of the movie data.
Given that these compression techniques are tightly coupled to the type of data they're
supposed to handle, the Image Compression Manager does not work for sound, text, or
any type of data other than images.
Figure 3 Component Manager Interactions
The Image Compression Manager accepts the input data as either a PICT or a pixMap;
obviously, the first format is most often used for still images and the second for
sequences of video. Since images can be very large (even when compressed), in both
cases the Image Compression Manager allows for the calling application to provide
spooling routines that feed the Image Compression Manager source data as needed and
write the resulting compressed data to disk. The Image Compression Manager can also
translate between pixMaps of varying bit depth. This simplifies the manipulation of an
image split across monitors of two different bit depths; it also extends a compressor or
decompressor's ability to manipulate images that (because of incompatible pixel bit
depths) it would otherwise not be able to handle.
In the case of pictures, the Image Compression Manager provides a set of high-level
calls that allow applications to compress and play back PICT resources and files.
Although these compression facilities are available to applications that call them, even
applications that know nothing about QuickTime's compression facilities can play back
pictures containing compressed images. (This can occur because QuickTime-unaware
applications calling DrawPicture will automatically invoke the Image Compression
Manager, which will decompress the image automatically and hand the application the
uncompressed PICT image it was expecting.) In other words, when QuickTime is
present, you can use compressed PICTs as part of your application and know that any
PICT-reading application can open them correctly.
Figure 4
Image Compression Manager Interactions
The Image Compression Manager provides a simple and at the same time powerful
system for compressing images. Since the mechanism is based in the workings of the
Component Manager, adding new compression engines is as simple as dropping a 'thng'
file into the Extensions folder of the System Folder (for System 7.0, or into the
System Folder itself for System 6.0.7). Even when the exact decompressor component
is not available to decompress the data, the Image Compression Manager will find a
substitute if any is available. High-level calls are provided for applications to access
these features in a nearly effortless manner.
QUICKTIME SAMPLE CODE
We'll now directly explore the QuickTime features that you can immediately put into
your applications. We'll follow two samples, each of which accomplishes one of the two
basic QuickTime functions:playing back a movie (which most applications should be
able to do) andcreating a movie (which you'll need to know how to do if your
application creates new movies).
PLAYING BACK A MOVIE
To show the basic steps necessary to open movie files and play them back, we'll use the
sample application SimpleInMovie. (You can find the source code for this on the
latestDeveloper Essentials disc.) This program presents the user with a dialog for
opening a movie and plays the movie back in awindow. SimpleInMovie uses
QuickTime's standard movie controller (which is itself a component) to let the user
start or stop the movie as well as scan back and forth within it. Some commands for the
movie controller are implemented as menu commands to show how a program can
control the controller component.
But first, a few words . . . Before we look at the SimpleInMovie source code, we
need to make several new distinctions. The most important distinction is that of
apublic movie versus a playable movie . A playable movie is what the Movie Toolbox
manipulates; it has all the information needed for it to be played or edited. In contrast,
a public movie is used only for data interchange, and it contains all the information
needed to create a playable movie. A playable movie must be converted to a public
movie (which is stored as a resource of type 'moov', pronounced "moo-vee") before it
Referenced by (1):