September 93 - SOMEWHERE IN QUICKTIME
SOMEWHERE IN QUICKTIME
DYNAMIC CUSTOMIZATION OF COMPONENTS
QuickTime's component architecture lets you do a number of amazing and useful things by
customizing components, which you can do by deriving one component based on another. Because
QuickTime components are dynamically linked, preexisting applications can take advantage of a new,
derived component without recompiling or rebooting. And because QuickTime is an extension of
system software, the derived component will provide systemwide functionality.
In this column I'll describe how to use object-oriented techniques to customize components using a
derived component. To illustrate, I'll show you how to customize the Apple text media handler to
"speak" text tracks in movies using Apple's new Text-to-Speech Manager. You'll find the derived
component on this issue's CD, along with a generic derived component that you can use as a basis
for doing your own customizing. I've also supplied an application to help you debug your
component. This application uses the debugging technique of registering the code inline. It's very
basic and simply plays back a movie, but it gives you access to the full debugging environment of
ABOUT THOSE OBJECT-ORIENTED TECHNIQUES
As any MacApp or class library programmer knows, there are three main steps to adding or altering
functionality in an object-oriented program:
- Identify the class responsible for the behavior you want to alter.
- Identify the specific methods you need to add or override.
- Create a new class derived from the original class and implement the new methods or enhance the
Because components can be overridden much like C++ classes, these object-oriented techniques can
be applied to customizing components. (For a more in-depth comparison of components and C++
classes, see the "Be Our Guest" column indevelop Issue 12.)
So, the three steps to customizing components are:
- Identify the component to use as a starting point.
- Identify the routines in the component to override.
- Create a derived component.
Before we get into a discussion of these steps, let's drop back and look at the nuts and bolts of
QuickTime component architecture with its dynamic linking capabilities. This should give you a
clearer idea of how it's possible to alter QuickTime's behavior at run time.
DYNAMIC LINKING OF COMPONENTS
The QuickTime movie file format depends on the dynamic linking capabilities of the Component
Manager. To play a QuickTime movie, you need more than just the movie data (video frames,
digitized audio samples, text, and such): you also need a time source, code to read/write the data, and
code to act on or interpret the data. It would be impractical to store all this information in each and
every QuickTime movie. Instead, the time source and code are dynamically linked in as components,
while the movie data remains in a QuickTime movie file.
When a movie is opened in an application like MoviePlayer, the movie file is opened first, followed
by a NewMovieXXX call (such as NewMovieFromFile). The major purpose of the NewMovieXXX
call is to dynamically link to all the components listed in the movie resource and return a handle to
this "new" data structure.
When a NewMovieXXX call is made, QuickTime invokes the Component Manager to load the
handlers described in the media. A clock component is loaded first (type 'clok', subtype 'micr'). Then
the media handler for each track is brought in (type 'mhlr'). If you have video and sound, for
example, video and sound media handlers are loaded (subtypes 'vide' and 'soun', respectively).
You may notice that the media handlers open other media handlers to do chores for them. The video
and sound media handlers open the standard media handler (type 'mhlr', subtype 'mhlr'), which is a
high-throughput media handler. The text media handler, though, opens the base media handler (type
'mhlr', subtype 'gnrc'). The base media handler is a public, general-purpose media handler with a
lower throughput that is nevertheless fast enough for text.
Next a data handler is loaded. Note that at present there's only one kind of data handler (type 'dhlr',
subtype 'alis') supporting streams of data from HFS files. If necessary, a decompressor component is
loaded for video; its type depends on the compression format.
Thus, a media handler and a data handler are loaded for each track. QuickTime movies use data
handlers and media handlers to load, interpret, and manage the movie data. The alias data handler is
responsible for opening and closing data files and for reading and writing sample data. It doesn't
understand the format
of the data but merely hands off the data to the media handler to interpret.
The media handler is the component that's responsible for interpreting data retrieved from the data
handler and for scheduling the rendering of this data at the correct time during movie playback. For
example, the text media handler interprets text samples and renders the text track in the movie based
on the current time value of the movie. The media handler interfaces with the data handler using file
offsets and with the rest of QuickTime through a time value. Thus, a major media handler chore is
to convert time values into file offsets.
You now know how and why a QuickTime movie dynamically links with its media handlers. With
that background on QuickTime component architecture behind us, we now embark on the process of
customizing the text media handler to speak its text.
IN SEARCH OF A BASE COMPONENT
The first step in customizing a component is to identify the base component -- the component to
Not all components can be customized. There are two requirements. First, the component must
implement the target request; that is, it must allow another component instance to intercept all its
messages. To determine whether a particular component instance implements the target request, you
can use the call
The second requirement is that a component must have a public API before it can be inherited from.
When a component is called, it's passed the routine's selector in the ComponentParameters
structure. The component parses this selector and jumps to the appropriate function. If there's no
public API, you
can't know the parameters and behavior of any of the component's routines and thus can't override
them. The interface file QuickTimeComponent.h contains the APIs for all public QuickTime
To speak text as it streams by, we'll want to customize the Apple text media handler, which both
implements the target request and has a public API. The Apple text media handler itself is a derived
media handler that uses the services of the base media handler supplied by Apple. Consequently, its
interface is defined in the MediaHandlers.h file. (For more on the intricacies of derived media
handlers, see the "Somewhere in QuickTime" column indevelop Issue 14.)
IN SEARCH OF THE ROUTINES TO OVERRIDE
Our next step is to find the routines to override. In our example, one routine we need to override is
the routine in the Apple text media handler where the text is rendered. In addition to rendering the
text, we want to grab the text and speak it.
A media handler is normally called in response to a MoviesTask call. MoviesTask is the QuickTime
workhorse routine that gives time to the media handler to get the data and render it. In turn,
MoviesTask calls the MediaIdle routine to do the bulk of the processing in a media handler.
MediaIdle is the main routine in MediaHandlers.h. Thus, MediaIdle is the main routine we want to
override. Additionally, we'll need to override the MediaInitialize routine, which supplies us with an
initial reference to the media.
CREATING A DERIVED COMPONENT
So far we've chosen a base component from which to derive our customized component, and we've
identified the routines we want to override. Now we're ready to take the third step of writing a new
component that targets the base component and overrides the
identified routines. If you're curious about the design of the generic derived component, you can
investigate it on the CD. I'm only going to point out a couple of things about its design before
moving on to discuss what you need to do to make your own derived component.
To capture or not to capture. You have two possible approaches when deriving a component. First, you
can simply open and target a component, which lets your component use the services of that
component. The component is still available to other clients, but you're using an instance of it.
Second, in addition to targeting the component, you can capture it. The base component will then be
replaced by your component in the component registration list and will no longer be available to
clients (although current connections are retained). The CaptureComponent routine returns a special
ID so that the captured component can still be used by your component.
We'll use CaptureComponent because we want to replace the functionality of all instances of the text
media handler (conceptually, you can think of capturing as patching). However, targeting without
capturing is just as effective -- and it has a few advantages: it doesn't require you to keep track of the
captured component's ID, and it allows clients looking for a specific component to be successful.
Let's walk through the steps you'd take to make your own derived component using the generic code
on this issue's CD, which are the same steps used to create our text-speaking example. You need to
make changes in specific places: the component resource, the global data file, the OpenComponent
routine, and the override routines.
Changing the component resource. The first thing to change is the resource file for the component.
The essential part of this file is the component description, which is a structure that describes the
component type, subtype, manufacturer, and flags. The Component Manager looks at this
information when it's handling an application's request for a component. You want the right
information here so that QuickTime will grab your derived component instead of the base
You should change the component type and subtype to match those of the component you're
inheriting from. In our example, when a QuickTime movie with a text track is opened, QuickTime
asks the Component Manager for a text media handler, which has type 'mhlr' and subtype 'text'.
Since we want QuickTime to grab our derived component instead, we need to make its type and
subtype the same.
In our case, we have to change the component manufacturer to match that of the base component as
well. This isn't the ideal situation, because it would be most desirable for each component to have a
unique manufacturer. But clients may look for a component of a specific manufacturer and won't
grab your derived component if its manufacturer is different. Because it would be better to be able to
identify a derived component, it's strongly suggested that component clients always perform a default
search, avoiding asking for specifics other than type and subtype.
You may also need to set the componentFlags field, which identifies specific functionality for a
component. For example, video digitizers use componentFlags to identify the type of clipping the
digitizer performs, among other things.
If you don't know how a client searches for a component, you can find out by running that
application and trapping on FindNextComponent. The last parameter pushed on the stack is the
component description, and you can find its values in a debugger (see "Inside QuickTime and
Component-Based Managers" indevelop Issue 13). In our example, we know that QuickTime
performs a simple type and subtype search for a text media handler, so we only have to change the
type and subtype in the component resource.
The global data file. The ComponentData.h file contains the declaration of the data structure for each
component instance and the global component data structure. You'll need to fill out a component
description structure describing your chosen base component, which will be used to ask the
Component Manager to find it.
Now you're left with defining the global data for your derived component. The generic capturing
component on this issue's CD has one item that's shared across all its instances: a reference to the
captured component. If you need data that's shared across instances, declare it here, but in general
you shouldn't need it.
The data local to each instance is allocated in the OpenComponent routine. By default, three
component instances will be kept track of: a self copy, a delegate copy, and a target copy. These
instances will be stored for you, and you won't need to do any work. The target copy is the instance
of a component that may capture yours. If your component calls itself, it should use this instance in
case the target overrides the routine.
The other data that you allocate is specific to the type of your derived component. For our example,
we'll allocate room for a speech channel, a media reference, a handle to the text to be spoken, and a
StdTTSParams structure, which is filled out by the Standard Text to Speech dialog. This dialog lets
the user choose voice, pitch, and modulation.
The OpenComponent routine. OpenComponent performs three major operations. First, it allocates
storage for each instance. Second, it checks for QuickTime, the Text-to-Speech Manager, and other
dependencies; if they're not installed, the component can't open and an error is returned. Note that
software dependencies are checked here instead of in RegisterComponent to bypass possible load
order conflicts. Finally, OpenComponent captures the Apple text media handler and stores a
reference to it in the component globals.
The override routines. Now it's time to implement the override routines. You'll need to get the
selectors for the routines from the original component's header file.
In our example, we look at MediaHandlers.h and find the MediaInitialize routine. The selector has a
constant, kMediaInitializeSelect. We need to make the parameters of our override routine match
those of the MediaInitialize routine.
pascal ComponentResult MediaInitialize
MediaInitialize performs these tasks: it stores the media reference from the
GetMovieCompleteParams structure in our private storage; it queries the user for a voice with the
Standard Text to Speech dialog; and, with this information, it allocates and sets up the speech
Next we implement the MediaIdle routine, which has a selector of kMediaIdleSelect. Our MediaIdle
looks like this:
pascal ComponentResult MediaIdle
(PrivateGlobals **storage, TimeValue
atMediaTime, long flagsIn, long *flagsOut,
const TimeRecord *movieTime)
This routine retrieves the media sample for the time passed in and then speaks it. The important
parameter is atMediaTime, which contains the current time value of the media for the movie. We get
the media sample for that time using GetMediaSample, and then we use the nifty new Text-to-
Speech Manager to speak.
In this case, we'll use SpeakText, which takes three parameters: a speechChannel (allocated earlier in
the OpenComponent routine), a pointer to the beginning of the text that we want to speak, and the
length of the text. SpeakText is an asynchronous routine, so it won't hold up processing (or the
movie) while it speaks. On the other hand, the text can't be disposed of until speaking is finished. To
accommodate this requirement, a reference to the text is stored in our instance storage, and the text
is disposed of when the component closes.
LETTING USERS LINK AND UNLINK COMPONENTS
Thanks to dynamic linking, a large number of users can easily take advantage of new functionality
provided by customized components. Three methods can be used to register and unregister
components. First, a component is registered at system startup if the component resides in the
System Folder, or in the Extensions folder of the System Folder. To unregister this component, a
user can remove it and reboot. Second, an application can dynamically register components as
needed, and then unregister them when finished. Third, you can use the drag-and-drop applications
Komponent Killer and Reinstaller II included on this issue's CD. Using these applications, you don't
have to reboot. (Of course, your typical user won't do it this way; this method is for you, the
Now you know how to customize a component using a derived component, which will be
dynamically linked at run time and thus can extend systemwide functionality. Just think of the
possibilities! You can override the movie controller and implement an Apple event handler. And you
can override other base components as well. Fiddle around with the generic derived component on
the CD to get an idea of the exciting prospects before you.
- "Somewhere in QuickTime: Derived Media Handlers" by John Wang, develop Issue 14.
- "Inside QuickTime and Component-Based Managers" by Bill Guschwan, develop Issue 13.
- "Techniques for Writing and Debugging Components" by Gary Woodcock and Casey King, develop Issue 12.
- "Be Our Guest: Components and C++ Classes Compared" by David Van Brink, develop Issue 12.
BILL GUSCHWAN (AppleLink ANGUS) hung out with Robert Schumann to discuss their symphonic feats. Robert: "Angus, I
understand you compare your jobs to symphonies." Angus: "I guess so, though I'd rather compare operas to pasta. You
know, Wagner is lasagna, Mozart is fettucine, Verdi is ravioli, . . ." Robert: "So on your opera pasta scale, how do you
rate my symphonic music?" Angus: "Linguini." Robert: "Yo mama!" Angus: "Listen, Mr. Concerto Psycho Ward, at least
my mother knows the meaning of life beyond success. Can't say the same about your wife." Robert: "You mean my
beloved Clara." Angus: "Yep, Clara, the dogcow. Well, gotta go, I hear Symphony No. 2." Robert: "Before you go,
what's the key?" Angus: "C Major." Robert: "No, what's the key?" Angus: "As Wittgenstein says, the key to life is that
language is a game." Robert: "No, what's the key?" Angus: "Oh, it's the key to my new office in PIE DTS." Robert: "Then
let the music begin, allegro." Angus: "Pass the parmesan." *
To see information about a track in a hierarchical manner, you can use Dumpster, a QuickTime tool that's included on this
You can watch the components of a movie load if you set A-trap breaks as outlined in the section "Breaking on Common
Component Manager Routines" in the article "Inside QuickTime and Component-Based Managers" in develop Issue 13.*
QuickTime 1.6 adds a new Component Manager selector, componentWantsUnregister, that you can take advantage of
when you want to free a captured component. Set componentWantsUnregister in the componentRegisterFlags field. When
the captured component is unregistered, your derived component can call UncaptureComponent and dispose of the global
To identify a captured component in a debugger, you can use the thing dcmd. The component ID of a captured component
will begin with two periods (..). *
A version of the Text-to-Speech Manager can be found on this issue's CD. *
Thanks to Ken Doyle, Tim Schaaff, and Gary Woodcock for reviewing this column. *