Volume Number: 15 (1999)
Issue Number: 11
Column Tag: Multimedia

QuickTime 4 For Programmers

by Tim Monroe, Apple Computer, Inc.

What's new in the latest version of Apple's flagship multimedia software

QuickTime 4, the latest incarnation of Apple's digital multimedia playback and authoring software, was released to the public in its final form earlier this summer and, thanks to a little help from the Star Wars: Episode I craze, achieved an astounding 13 million downloads by the end of August. As you might know, George Lucas chose QuickTime as the sole distribution medium for the Internet versions of the trailers promoting the new Star Wars movie. Over 25 million downloads - over 450 terabytes of data - crossed the wires in the first few months, making this the largest Internet-related event in history.

What did the millions of people who chose the trailers encoded especially for QuickTime 4 get? Primarily they got a better user experience, owing both to some higher-quality video and audio codecs contained in QuickTime 4 and to an improved user interface for the basic QuickTime movie playing application. But they also got something they perhaps didn't realize or even care too much about at the time: the ability to receive video and audio streamed across the Internet. Among all the various improvements in QuickTime 4, this one stands out as the crown jewel: real-time audio and video streaming.

This streaming capability is important for several reasons. First, it gives users the ability to watch live events remotely. (Didn't get a seat in the hall at the latest MacWorld conference keynote address? No problem: just fire up your computer, connect to the Internet, and watch Apple's latest news and product announcements from the privacy of your own workspace.) Second, and just as important, it gives users the ability to view non-live events without downloading potentially huge files onto their computers; this permits applications such as video-on-demand and rebroadcast streaming.

In this article, I'll discuss some of the major innovations in QuickTime 4. I'll start by surveying the user-level enhancements, which mainly concern the new QuickTime Player application. Then I'll describe the important features of QuickTime's new streaming architecture and outline what you might need to do to make your existing QuickTime application streaming-savvy. Finally, I'll describe a few of the other API-level additions in QuickTime 4, which allow you to manage wired actions, multi-image files, network file transfers, and other useful tasks.

The first thing most people notice once they've installed QuickTime 4 is that the main movie-playing application bundled with the software sports a completely new look and feel. Indeed, the application is so different from earlier versions that it sports a new name as well; what used to be known as "MoviePlayer" is now known as "QuickTime Player". Figure 1 shows the new brushed-metal appearance of a QuickTime Player movie window.

As you can see, the controller bar has a new look, complete with a built-in graphic equalizer to the right of the progress bar. The volume slider has been replaced with a thumbwheel, and the play/pause button is larger and more centrally located. Just underneath the play/pause button is a rectangle that the user can grab and drag to open a "drawer" containing a set of favorite movies and Internet channels, as seen in Figure 2. Clicking on an item in the favorites drawer either opens the selected movie or connects to the selected Internet channel.

QuickTime Player includes a few other features not found in earlier player applications. The File menu now contains an "Open URL..." command; when the user selects this item, the player displays a dialog box (see Figure 3) that allows the user to specify a URL to open. The URL should specify the location of a movie file.

Finally, QuickTime Player incorporates a new dynamic, web-based method for installing and updating QuickTime software. The Help menu contains an item labeled "Check for QuickTime Updates". If the user selects this item and the installed software is up-to-date, then QuickTime Player displays the dialog box shown in Figure 4.

If, on the other hand, one or more components of the user's installed software has changed, or if new channels have been added to the favorites drawer, then QuickTime Player displays the dialog box shown in Figure 5. As you can see, the user can decide to go ahead and update the software or else defer updating to some later time.

If the user does decide to perform the update, QuickTime opens an Internet connection to a server containing the updated software and then downloads the necessary updates. While it performs the download, it displays a screen like the one shown in Figure 6.

Streaming is the process whereby one computer (the "server") chops a file up into discrete chunks ("packets") and sends them across a network to another computer (the "client"). The client's job is to reassemble the packets and do the right thing with them. It's important to keep in mind that QuickTime has supported a kind of streaming, called "HTTP streaming", ever since version 3 was released over a year ago. QuickTime's HTTP streaming allows the QuickTime browser plug-in to begin playing a movie embedded in a web page before the entire movie has downloaded. HTTP streaming is essentially a file transfer protocol, in the sense that the entire movie must be downloaded to the user's computer. The main advantage of QuickTime's HTTP streaming is that a user can begin interacting with web-based content before the entire movie arrives on the user's computer.

QuickTime 4 introduces a different kind of streaming, called "real-time streaming". With real-time streaming, packets are sent out over the network in real time (so that, for instance, a 10-minute movie would take 10 minutes to download). When packets are received by the client application (for instance, by QuickTime Player), they are reassembled into a QuickTime movie and played for the user. In general, packets are discarded as soon as they have been played, so no file is ever created on the user's local storage.

QuickTime's real-time streaming uses an open streaming protocol known as Realtime Transport Protocol (RTP) to send the packets of video and audio data. For control information, such as establishing a connection between the client and server or telling the server to jump to a new time in a video-on-demand movie, QuickTime uses a different protocol known as Realtime Streaming Protocol (RTSP). Figure 7 shows the basic network protocols used by QuickTime's streaming architecture. RTSP uses the TCP/IP transport layer, while RTP uses the lower-level UDP/IP transport layer.

Because RTP uses UDP/IP, it does not guarantee delivery of packets. So it's possible for some packets to get lost in transit and never arrive at the client computer. If you need guaranteed delivery of packets, you should use HTTP streaming, which uses TCP/IP to ensure that all transmitted packets are in fact received (retransmitting any lost packets).

QuickTime 4 supports streaming of video and audio data in any of the formats that can be played locally by QuickTime, including AVI, Sorenson, QDesign, MP3, and MIDI. It cannot currently stream movies containing sprite tracks or that incorporate features that depend on track references, such as QuickTime video effects, chapter lists, and some tweening effects. To handle these sorts of movies, you can either use HTTP streaming or you can create movies that store some data locally and combine that data with data received via RTP streaming.

The files that reside on the streaming server are standard QuickTime movies, with one important addition: each track in the movie that is to be streamed across the network must be accompanied by a "hint track". The hint track contains information that tells the server how to packetize the corresponding streamed track. In other words, the hint track is a sort of blueprint for creating streams of data. Without the hint track, the server software would have to know a great deal about the particular audio or video format contained in the streamed track, so that it would know how best to chop the data up into packets (for instance, possibly duplicating some of the packets to protect against losing important frames of video). The hint track essentially insulates the server software from having to know anything about the actual video or audio data it's serving.

This is especially important because it allows streaming servers to run on operating systems that don't even run QuickTime. Indeed, the first commercially available QuickTime server application, Apple's QuickTime Streaming Server (QTSS), debuted on machines running the Mac OS X Server software, where QuickTime client software is not yet supported. Moreover, Apple has released the source code for the QuickTime Streaming Server under the Apple Public Source License, which conforms to the Open Source community guidelines. You can expect to see versions of QTSS running under Windows NT and various flavors of UNIX (such as BSD, Linux, and Solaris).

Making Your QuickTime Application Streaming Savvy

Now let's suppose that you've written an application that plays QuickTime movies. The simplest way to handle QuickTime movie playback is to open the movie file (by calling the OpenMovieFile function), get the movie data from the movie file (by calling the NewMovieFromFile function), and then associate a movie controller with the movie (by calling the NewMovieController function.) The movie controller provides whatever user interface is appropriate for the type of movie being played (unless you explicitly request that no user interface be displayed). The movie controller also handles the entire interaction with the user (starting or stopping the movie, navigating within a QuickTime VR node, and so forth).

As you've seen, QuickTime 4 introduces a new kind of movie: streamed movies, or movies whose contents are served to local client applications by a remote streaming server. An application generally starts receiving streamed content by opening a movie from an RTSP URL or from a local QuickTime movie file that contains a streaming track. In general, existing applications that play back QuickTime movie files should be able to handle QuickTime movie files that contain a streaming track without changes. (We'll show how to handle URL-specified movies in a little while.) However, for optimum user experience and movie playback, you will want to make several small changes to your application to make it fully streaming savvy. The main changes you'll want to make concern "preprerolling" your movies, reacting to any changes in the dimensions of streamed movies, and possibly intercepting the streaming status messages that are displayed in the movie's controller bar.

Prerolling and Preprerolling

Prerolling a movie is a technique for improving the playback performance of the movie. When you ask the Movie Toolbox to preroll a movie (typically by calling the function PrerollMovie), the Movie Toolbox opens the appropriate media handlers and tells them to prepare to play the movie. The media handlers may then load some of the movie data, set up sound channels, start up decompression sequences, and the like. (See <http://www.apple.com/quicktime/developers/icefloe/dispatch013.html> for an extensive discussion of prerolling movies.) With streamed movies, you may need to perform some additional actions even before you can preroll a movie, such as making network connections to the remote machine that is serving the streamed content, negotiating a streaming protocol, and setting up buffers to receive the streamed data. This process is known as "preprerolling".

When you are playing movies using QuickTime's standard movie controller and the movie is started as a result of a user action (such as clicking on the play button), the movie controller takes care of both preprerolling and prerolling. If you are playing movies using QuickTime's standard movie controller and you want to start the movie programmatically, then you can use the "preroll and play" action, like this:

MCDoAction(myMC, mcActionPrerollAndPlay, (void *)GetMoviePreferredRate(myMovie));

This is exactly the same thing you need to do for any QuickTime movie. In other words, when you are using the standard movie controller, you don't need to do anything special to handle streamed content. If the movie is a streamed movie, the movie controller first preprerolls it and then prerolls and starts it. Otherwise, if the movie doesn't contain any streamed data, the movie controller just prerolls and starts it.

If your application instead uses the Movie Toolbox to handle movie playback, then you do need to explicitly prepreroll your streamed movies before prerolling them. You can do this by calling the new PrePrerollMovie function. Here's one way to do this:

PrePrerollMovie(myMovie, 0, GetMoviePreferredRate(myMovie), NewMoviePrePrerollCompleteProc(MyMoviePrePrerollCompleteProc), (void *)0L);

PrePrerollMovie operates asynchronously. It returns (almost) immediately, thereby allowing your application to perform other processing while awaiting the completion of the preprerolling operations. When the preprerolling is finished, PrePrerollMovie calls the movie prepreroll completion procedure whose address you passed to it in the fourth parameter. In the simplest case, a movie prepreroll completion procedure will need to just preroll and start the movie, like this:

Listing 1: A simple movie prepreroll completion procedure

MyMoviePrePrerollCompleteProc

pascal void MyMoviePrePrerollCompleteProc (Movie theMovie, OSErr thePrerollErr, void *theRefcon)
{
	StartMovie(theMovie);
}

Note that StartMovie calls PrerollMovie internally, so there is no need to call both PrerollMovie and StartMovie in the movie prepreroll completion procedure. Also, there is no need to test that a movie is a streaming movie before calling PrePrerollMovie; for non-streaming movies, PrePrerollMovie calls the completion procedure immediately. It is important, however, to call MoviesTask on a preprerolling movie so that the Movie Toolbox has time to do the preprerolling operations.

Reacting to Size Changes

One interesting new feature of streamed movies is that their size may change dynamically during playback. In most cases, you'll want to adjust the size of the window or pane that contains the movie to reflect any such size changes. (Presumably, you already have code that knows how to adjust the size of a window or pane based on the size of a movie it contains.) To be able to support dynamic size changes, you first need to indicate to the Movie Toolbox that you want to be informed of any changes in the movie's size. You do this by setting a movie playback hint, as follows:

SetMoviePlayHints(myMovie, hintsAllowDynamicResize, hintsAllowDynamicResize);

Thereafter, whenever the size of myMovie changes, the associated movie controller sends the mcActionControllerSizeChanged controller action to your movie controller action filter procedure. You can intercept that action and respond to it as follows:

Listing 1: Dynamically resizing a window

MyMCActionFilterProc

pascal Boolean MyMCActionFilterProc (MovieController theMC, short theAction, void *theParams, long theRefCon)
{
	Movie		myMovie = MCGetMovie(theMC);

	switch (theAction) {
		// handle window resizing
		case mcActionControllerSizeChanged:
			MyResizeWindow(myMovie);
			break;
	}
	return(false);
}

If you allow the user to resize windows, you probably already have this code in your movie controller action filter procedure. In that case, you simply need to call SetMoviePlayHints as shown above (perhaps when you first open the movie).

Status Messages

The movie controller indicates the status of streaming operations by sending action messages to itself. By default, those messages are displayed in the message area of the controller bar, as illustrated in Figure 8.

You can intercept those messages in your movie controller action filter procedure by intercepting messages of type mcActionShowStatusString. The parameter data is a pointer to a structure of type QTStatusStringRecord, which is defined like this:

struct QTStatusStringRecord {
	long 						stringTypeFlags;
	char *						statusString;
};

You can identify streaming-specific messages by inspecting the stringTypeFlags field; if the bit kStatusStringIsStreamingStatus is set, then the message pertains to streaming operations. In addition, if the bit kStatusHasCodeNumber is set, then the high-order 16 bits of the stringTypeFlags field contain a result code.

The statusString field contains the actual text of the status message, which (if you do nothing to it) will be displayed in the controller bar status area. You can (if you like) suppress the display of the message or change the message to some other message. You can also display a message, at any time, in the controller bar of a streaming movie by calling the function QTStreamMsg_IssueMessage defined in Listing 2.

Listing 2: Displaying a streaming message

QTStreamMsg_IssueMessage

void QTStreamMsg_IssueMessage (MovieController theMC, char *theMessage)
{
	QTStatusStringRecord		myRecord;
	
	myRecord.stringTypeFlags = kStatusStringIsStreamingStatus;
	myRecord.statusString = theMessage;
	
	MCDoAction(theMC, mcActionShowStatusString, &myRecord);
}

As you can see, QTStreamMsg_IssueMessage simply fills in the fields of a status string record and calls MCDoAction to issue the action to the movie controller.

In QuickTime parlance, a data handler is a chunk of code that's responsible for reading (and perhaps also writing) a movie's data. For movies that reside on local storage volumes, you typically use the HFS data handler, which access a movie file using an alias to that file. It's also possible to build a movie completely in memory, in which case you can use QuickTime's handle data handler to access the movie's data. QuickTime 4 introduces another data handler that you might find useful, a URL data handler.

You can use the URL data handler to open movies that are specified using uniform resource locators (URLs). A URL is the address of some resource on the Internet or on a local disk. The QuickTime URL data handler can open HTTP URLs, FTP URLs, file URLs, and RTSP URLs. For instance, you can emulate QuickTime Player's Open URL menu item (see Figure 3) by passing a URL to the QTURL_NewMovieFromURL function defined in Listing 3. QTURL_NewMovieFromURL takes a URL as a parameter and opens the movie file found in that location.

Listing 3: Using the URL data handler

QTURL_NewMovieFromURL

Movie QTURL_NewMovieFromURL (char *theURL)
{
	Movie			myMovie = NULL;
	Handle			myHandle = NULL;
	Size				mySize = 0;
	
	// get the size of the specified URL
	mySize = (Size)strlen(theURL) + 1;
	if (mySize == 0) goto bail;
	
	// allocate a new handle
	myHandle = NewHandleClear(mySize);
	if (myHandle == NULL) goto bail;

	// copy the URL into the handle
	BlockMove(theURL, *myHandle, mySize);

	// instantiate a movie from the specified URL
	NewMovieFromDataRef(&myMovie, newMovieActive, NULL, myHandle, URLDataHandlerSubType);

bail:
	if (myHandle != NULL)
		DisposeHandle(myHandle);
		
	return(myMovie);
}

The main thing we need to do here is construct a data reference to the URL, which we can then pass to the NewMovieFromDataRef function. For the URL data handler, a data reference is simply a handle that contains the text of the URL and a terminating null byte. If you have worked with data references before, you'll recognize this as an exception to the usual practice with data references (where you need to pass a handle to a handle containing the relevant data).

Strictly speaking, a data handler can read and write any kind of data, not just movie data. So, for instance, you could use the URL data handler to read data from a file specified by a remote FTP URL while using the HFS data handler to write that data into a local file. The result would be a file-transfer application that did all its important work using QuickTime APIs alone. This is in fact fairly easy to write, even allowing for asynchronous file copying (copying where the application is free to perform other operations while the file is being transferred). See the accompanying sample code QTFileTransfer for exact details.

One of the coolest new features of QuickTime 3 was its support for wired sprites, or sprites that react to mouse (and certain other) events and that have various actions attached (or "wired") to them. QuickTime 4 extends this support for wiring by allowing you to wire actions to events that concern things other than sprites. There are three main new wiring capabilities in QuickTime 4: wiring to QuickTime VR nodes and hot spots, to text in text tracks, and to Flash content.

QuickTime VR now supports two general kinds of wired actions: actions that are specific to a particular node and actions that are specific to a particular hot spot in a node. The node-specific actions can be attached to either idle events (so that an action can be triggered after a certain amount of time has elapsed) or to frame-loaded events (so that an action can be triggered when the node is first entered). You could, for instance, attach an action to a frame-loaded event to set the initial pan and tilt angles that are displayed when the user enters a node. Or, you could attach an action to a frame-loaded event to start a sound track playing when the user first enters a node. Moreover, you could use idle event actions to dynamically adjust the balance and volume of that sound as the user changes the pan angle of the movie; this would provide an easy way to make a sound appear to emanate from a specific location in a movie (in other words, this would provide "directional sound").

You can also attach wired actions to hotspots inside of QuickTime VR nodes. You can configure these actions to be triggered by a variety of mouse events, including moving the mouse over a hot spot, moving the mouse out of a hot spot, and clicking the mouse within a hot spot. Once again, the actions that are triggered by these events can be any actions supported by the QuickTime wired action architecture, such as starting and stopping sounds, enabling and disabling tracks, changing pan and tilt angles, and so forth.

QuickTime 4 allows you to attach wired actions to selections in a text track. Consider, for instance, the movie shown in Figure 9. This movie contains only one track, a text track. The text track is wired so that clicking on the word "Apple" launches the user's default web browser and loads the URL <http://www.apple.com/> and clicking on the word "CNN" loads the URL <http://www.cnn.com/>.

The final new wiring capability provided by QuickTime 4 is the ability to attach wired actions to items in a Flash track. Flash is a file format developed by Macromedia for displaying vector-based graphics and animations. It's especially popular for web-based content delivery, since it combines rapid download speeds with an interactive browsing experience. Apple has licensed the Flash Player from Macromedia and has built it into QuickTime, thereby allowing QuickTime movies to include Flash graphics, animations, and interactivity. What's new in QuickTime 4 is the ability to attach wired actions to elements in a Flash track, thereby supplementing the native Flash interactivity. So, for instance, you can use Flash graphic elements (instead of sprites) to provide a user-interface for a QuickTime movie.

So now you might be wondering: how do I implement all these wonderful new wired action capabilities? The answer is that, in general, you don't need to use any new APIs. Instead, you just need to create the appropriate atom containers (which hold information about the desired actions) and attach them to the appropriate objects in the QuickTime movie. For instance, you would put a wired action container for a QuickTime VR node into the node information atom container that is contained in the media sample for that node in the QTVR track in the VR movie. Similarly, to add hypertext actions to a text sample, you simply add a text atom extension of the type kHyperTextTextAtomType to the end of the sample; the data of the text atom extension is the container that holds the information about the actions. The code showing how to do this is straightforward but not very exciting (and a tad lengthy). Take a look at the sample code on the QuickTime 4 SDK for some real-life examples.

One new use of wired actions in QuickTime 4 that we can easily illustrate is adding a new movie to QuickTime Player's favorites drawer (see Figure 2 once again). We do this by issuing a movie controller action of type mcActionExecuteOneActionForQTEvent, where the action to be executed is the new kActionAddChannelSubscription action. So we need to build an atom container that holds the desired atom and then send that atom container to a movie controller, as illustrated in Listing 4. (We've removed all error-checking to save some space.)

Listing 4: Adding a movie to QuickTime Player's favorites drawer

QTChan_AddMovieToFavorites
void QTChan_AddMovieToFavorites (Str255 theMovieName, char *theMovieURL, char *theMoviePictureURL)
{
	QTAtomContainer 			myActions = NULL;
	QTAtom								myActionAtom = 0;
	long									myAction;
	ResolvedQTEventSpec		myEventSpec;
	MovieController				myMC = NULL;
	
	// create a new atom container to hold a single action atom
	QTNewAtomContainer(&myActions);
	QTInsertChild(myActions, kParentAtomIsContainer, kAction, 1, 1, 0, NULL, &myActionAtom);
	
	// specify the action type
	myAction = EndianS32_NtoB(kActionAddChannelSubscription);
	QTInsertChild(myActions, myActionAtom, kWhichAction, 1, 1, sizeof(long), &myAction, NULL);
	
	// add the three parameters to the action atom
	QTInsertChild(myActions, myActionAtom, kActionParameter, 1, 1, theMovieName[0], &theMovieName[0], NULL);
		
	QTInsertChild(myActions, myActionAtom, kActionParameter, 2, 2, strlen(theMovieURL) + 1, theMovieURL, NULL);
		
	QTInsertChild(myActions, myActionAtom, kActionParameter, 3, 3, strlen(theMoviePictureURL) + 1, theMoviePictureURL, NULL);
	
	// fill in a ResolvedQTEventSpec structure
	myEventSpec.actionAtom.container = myActions;
	myEventSpec.actionAtom.atom = myActionAtom;
	myEventSpec.targetTrack = NULL;
	myEventSpec.targetRefCon = 0L;
	
	// instantiate a movie controller
	OpenADefaultComponent(MovieControllerComponentType, 0, &myMC);
		
	MCDoAction(myMC, mcActionExecuteOneActionForQTEvent, (void *)&myEventSpec);
	if (myActions != NULL)
		DisposeAtomContainer(myActions);
	if (myMC != NULL)
		CloseComponent(myMC);
}

The data that we need to pass to the movie controller for the action mcActionExecuteOneActionForQTEvent is a pointer to a structure of type ResolvedQTEventSpec, which specifies an action atom and the container that holds that atom. The action atom, in turn, contains the action specifier and three parameters, which indicate the name of the movie being added to the favorites drawer, the location of that movie, and the location of the picture that is to be displayed in the drawer.

In addition to its support for motion and interactive content, QuickTime provides a powerful set of services for displaying still images. QuickTime 4 provides, in particular, enhanced capabilities for both importing and exporting PNG, TIFF, TARGA, MacPaint, and Macromedia Flash formats. QuickTime 4 also provides the ability to import (but not export) graphics in the FlashPix format defined by the Digital Imaging Group. Also, QuickTime 4 adds support for image files that contain more than one image. This is necessary for FlashPix files (which contain multiple resolutions of an image), and it is also useful for opening and displaying PhotoShop files (which store layers as separate images in a single file).

You can determine how many images a particular graphics file contains by using the GraphicsImportGetImageCount function. And you select which of numerous images will be displayed by calling the GraphicsImportSetImageIndex function. Listing 5 illustrates how to display all the images contained in a specified file.

Listing 5: Displaying all images in a graphics file

QTMulti_ShowAllImagesInFile

void QTMulti_ShowAllImagesInFile (FSSpecPtr theFile)
{
	Rect								myRect;
	unsigned long			myCount, myIndex, myIgnore;
	OSErr							myErr = noErr;
	// get a graphics importer for the file and determine how many images are in it
	myErr = GetGraphicsImporterForFile(theFile, &gImporter);
	if (myErr != noErr) goto bail;
	myErr = GraphicsImportGetImageCount(gImporter, &myCount);
	if (myErr != noErr) goto bail;
	// loop thru all images the image file, drawing each into a window
	for (myIndex = 1; myIndex <= myCount; myIndex++) {
		// set the image index we want to display
		myErr = GraphicsImportSetImageIndex(gImporter, myIndex);
		if (myErr != noErr) goto bail;
		// determine the natural size of the image
		GraphicsImportGetNaturalBounds(gImporter, &myRect);
		MacOffsetRect(&myRect, 50, 50);
		// create a window to display the image in
		gImageWindow = NewCWindow(NULL, &myRect, "\pUntitled", 
					true, movableDBoxProc, (WindowPtr)-1L, true, 0);
		if (gImageWindow == NULL) goto bail;
		// set the current port and draw
		GraphicsImportSetGWorld(gImporter, 
													(CGrafPtr)gImageWindow, NULL);
		GraphicsImportDraw(gImporter);
		Delay(kImageDisplayTime, &myIgnore);
		DisposeWindow(gImageWindow);
	}
bail:
	if (gImporter != NULL)
		CloseComponent(gImporter);
}

A shortcut is a QuickTime reference movie that references a single other movie. A typical reference movie references more than one other movie, and the target of the reference movie is determined at runtime depending on certain features of the user's machine, such as the actual components that are available on the machine or the speed of the user's connection to the Internet. (Reference movies that select a target depending on the speed of the Internet connection are also called "multiple data rate movies".) A shortcut is essentially the simplest possible reference movie; all it does is refer to some target, which is opened (or imported) when the reference movie is opened (or imported).

Shortcut movies can be useful as a cross-platform, media-centric aliasing mechanism. The data reference contained in a shortcut can be any one of the data reference types supported by QuickTime (an alias to a file, a URL to an FTP or HTTP movie, and so forth) and that reference can address any kind of data that can be opened by QuickTime. Thus, you could put shortcut movies on a server that point to files elsewhere on the server, on another server, or even on the user's local machine. When a user opens a shortcut movie, its target data is automatically opened. This indirection allows a server administrator to move the files targetted by some shortcut movies to new locations and then update the shortcuts. Any client references to the shortcuts (HTML embeddings, explicit URLs used by an application, and so forth) would be unaffected by this move.

Shortcut movies have been supported by QuickTime beginning with version 3. QuickTime version 4 introduced the Movie Toolbox function CreateShortcutMovieFile, which you can use to create a shortcut movie given a data reference, its type, and a specification of the output shortcut movie file.

QuickTime 4 provides a wealth of new features - both for the end user and for the applications developer - and of course we've only really scratched the surface in looking at any of them. The most important new addition is QuickTime's new real-time streaming architecture, which permits live broadcasts and video-on-demand services over existing networks using industry-standard networking protocols. In addition, the server-side component of the streaming architecture is implemented using non-proprietary file formats. This opens the door for a wide variety of server products that can deliver high-quality streamed content from virtually any computer in the world to any other computer that is running the QuickTime client software. The day of desktop broadcasting has arrived!

• The main source of QuickTime 4 software, documentation, sample code, and other information is the web site <http://www.apple.com/quicktime>.
• You can download the source code for the QuickTime Streaming Server at <http://www.publicsource.apple.com>.

Tim Monroe <monroe@apple.com> is a software engineer on Apple's QuickTime team. He is currently developing sample code and utilities for the QuickTime software development kit.