Volume Number: 22 (2006)
Issue Number: 2
Column Tag: Programming

QuickTime Toolkit

Timeline

by Tim Monroe

Mapping the Evolution of QuickTime Programming

The QuickTime programming landscape looks pretty good nowadays. In terms of what you can do with QuickTime, the story has never been better. In the nearly 15 years since its introduction in December 1991, QuickTime has gained a truly impressive set of multimedia capabilities. It now provides services for displaying and creating movies, capturing audio and video data, compressing and transcoding media data, broadcasting saved movies and live captured data across a network, displaying and modifying still images, and other tasks too numerous to list here exhaustively. With the recent appearance of QuickTime 7, the QuickTime programming APIs now comprise more than 2500 actively-supported functions.

Introduction

But that of course is only half of the story, and in many ways it is the less interesting half. We would expect this sort of continual feature expansion from any software architecture that has been around for a decade and a half. What is perhaps more interesting is the wealth of tools that we as software developers can use to access those multimedia capabilities. For almost three full years, believe it or not, this QuickTime Toolkit column has focused more or less directly on the issue of how to use various different programming languages and development environments to construct QuickTime applications. We've built applications using a wide variety of alternate languages and IDEs, including Cocoa, REALbasic, Revolution, Visual Basic, AppleScript Studio, Java, Tcl/Tk, and others. From modern object-oriented application frameworks to old-school scripting languages, we've pretty much run the gamut of possibilities for developing applications and tools to create and modify and display QuickTime content.

It would be nice to pause and reflect on these tools and languages and to see how they compare with one another in terms of ease-of-use and feature completeness and extensibility. It would also be nice to run some benchmarks to see if some of these development environments produce particularly more efficient and resource-friendly applications than others. (Java, for instance, has a reputation for being slow; it would be nice to actually test our sample Java-based player application against our other sample applications.) But those reflections will have to wait for some other opportunity, since in this article I want to discuss a somewhat different issue. In particular, I want to look at how QuickTime programming itself has evolved in the years since its introduction. What did it look like in the beginning, and what is its general character now? What sorts of forces have prompted changes in the QuickTime programming model?

I think that this is an interesting set of questions because not every QuickTime developer -- and in fact probably a minority of current QuickTime developers -- has been using QuickTime for a significant portion of those 15 years. In addition, most developers are probably using one or more of the QuickTime-savvy RAD tools or application frameworks. Since none of these tools or frameworks provides access to all the existing QuickTime capabilities, it's likely that some QuickTime developers will need to venture outside the limits of their chosen tools to develop plug-ins or libraries for those tools. And then they land squarely in the realm of those 2500 functions.

MacOS

So let's begin at the beginning. QuickTime was originally released on the Macintosh Operating System (specifically, on MacOS version 6.0.7). Quite sensibly, the original QuickTime APIs were heavily dependent on the data types and structures used by the Macintosh Operating System and the Macintosh User Interface Toolbox. A chunk of memory was typically specified using a Handle data type, and files were typically specified using FSSpec records. Data to be drawn on the screen was accessed using bitmaps drawn into graphics ports and graphics worlds (specified using GrafPtr and GWorldPtr data types). The intention was very clearly that the QuickTime APIs should fit into the existing programming model on Macintosh computers.

At the same time, the QuickTime architects did not hesitate to drive that programming model forward in certain important ways. One of the big departures from existing practices was to make C the language of choice for developing QuickTime applications, in spite of the fact that Pascal still dominated MacOS software development during the time QuickTime was being developed. The original developer CD for QuickTime 1.0 provided 18 sample projects using C but only half that many using Pascal. More importantly, the technical documentation for QuickTime provided all sample code and reference material in C, not Pascal. Indeed, the books Inside Macintosh: QuickTime and Inside Macintosh: QuickTime Components were the very first books in that series to relegate Pascal to the programming summaries at the end of the chapters.

Listing 1 shows what a typical routine to open a movie file might have looked like. It uses the Standard File Package to display the file-opening dialog box to the user, and then it calls OpenMovieFile and NewMovieFromFile to create a Movie identifier for the data in the movie file.

Listing 1: Loading a movie from a file

Movie GetAMovie (void)
{
   OSErr                        myErr; 
   SFTypeList                   myTypes = {MovieFileType, 0, 0, 0}; 
   StandardFileReply            myReply;
   Movie                        myMovie = NULL; 
   short                        myRefNum; 
   short                        myResID = 0; 

   StandardGetFilePreview(NIL, 1, myTypes, &myReply); 

   if (myReply.sfGood) { 
      myErr = OpenMovieFile(&myReply.sfFile, &myRefNum, 
                                          fsRdPerm); 
      if (myErr == noErr) { 
         NewMovieFromFile(&myMovie, myRefNum, &myResID, NULL, 
                                          newMovieActive, NULL); 

         CloseMovieFile(myRefNum); 
      }
   }

   return myMovie; 
}

One interesting thing about this code is that it is almost completely deprecated on current Macintosh computers. The Standard File Package never made the jump from the "classic" MacOS to Mac OS X, and (as we saw in the previous article, "State Property 2" in MacTech, December 2005) the NewMovieFromProperties function is now recommended in place of NewMovieFromFile. After all, the parameters to NewMovieFromFile include oddities like a file reference number and a pointer to a resource ID, which are not standard ways of accessing files or file data on Mac OS X.

It's worth remarking that first QuickTime developer CD also included a small set of HyperCard add-ons, called external commands or XCMDs, that allowed HyperCard developers to access QuickTime functionality in their stacks. This then marks the first integration of QuickTime into what might be called a rapid application development (RAD) tool. There were four XCMD modules:

(1) The QTMovie XCMD, which could be used to play QuickTime movies in a window or directly onto the screen;

(2) The QTRecordMovie XCMD, which displayed data from a video digitizer;

(3) The QTEditMovie XCMD, which supported editing operations on a QuickTime movie;

(4) The QTPict XCMD, which performed a variety of still image operations, including displaying a picture on a card, compressing pictures, and allowing control over the clipping region of the card window.

(The perceptive reader will notice that, by pure historical accident, one of these XCMDs shares its name with the principal class in the new Cocoa QTKit framework, QTMovie.)

Windows

In the early 1990's, Apple released a version of QuickTime (called "QuickTime for Windows") that provided support for playing QuickTime movies on Windows computers. While it was a significant step forward, this version had some severe limitations. Most importantly, it provided a playback engine only; there was no way to create QuickTime movies on the Windows platform. Also, many of the APIs for playing movies back differed from their Macintosh counterparts. For instance, on the Mac, NewMovieController is declared essentially like this:

MovieController NewMovieController (Movie theMovie, 
                        const Rect *movieRect, long someFlags);

But under QuickTime for Windows, it had this declaration:

MovieController NewMovieController (Movie theMovie, 
                        const LPRECT lprcMovieRect, long someFlags, 
                        HWND hWndParent);

You'll notice that the Windows version took an additional parameter (hWndParent) and that the type of the second parameter was a pointer to the standard Windows rectangle type (RECT), not the Macintosh rectangle type (Rect).

QuickTime 3.0, released in 1998, changed all that. It provided a set of APIs that were virtually identical -- in both parameter lists and feature completeness -- on Macintosh and Windows platforms. It was then possible to write Mac and Windows applications that used the same source code, at least for the QuickTime-specific portions of the application.

The magic provided by the Windows version of QuickTime 3.0 was accomplished principally by a library called the QuickTime Media Layer (or, more briefly, QTML). The QuickTime Media Layer provides an implementation of a number of the parts of the Macintosh Operating System (including the Memory Manager and the File Manager) and the Macintosh User Interface Toolbox (including the Dialog Manager, the Control Manager, the Resource Manager, and the Menu Manager). In other words, QuickTime was ported to Windows mainly by way of transplanting large portions of system software from the MacOS to Windows.

For existing Macintosh developers, this scheme had some profound benefits. First and foremost, this greatly reduced the need to learn the intricacies of a new operating system. To display the standard Windows file-selection dialog box to elicit a movie file from the user, a developer could just use the familiar StandardGetFile function that he or she had been using all along on MacOS. And custom application icons, sounds, and fonts could be stored in resources, just as they are with MacOS applications. And existing QuickTime code could, as noted above, simply be recompiled for Windows applications. (Indeed, the code in Listing 1 would still compile and link just fine on Windows computers.)

But for Windows developers, this scheme was less than optimal. It required working with unfamiliar data types, like Handle and FSSpec and GrafPtr, and also working with command-line tools to create resources or add them to application files. A better solution, which Apple and several third-party developers pursued, was to develop Component Object Model (COM) plug-ins that support QuickTime APIs in Windows applications. One type of COM object is an ActiveX control, which can display a user interface and process events directed at that interface. The developer can then support QuickTime in a COM-aware application (for instance, one developed using Visual Basic) by using an appropriate ActiveX control. For instance, Listing 2 shows some Visual Basic code to handle the Open menu item in the File menu.

Listing 2: Handling the Open menu item

Private Sub FileOpen_Click()
   Dim openDial As New DialogWindow
   On Error GoTo bail

   openDial.CommonDialog1.Filter = "All Files (*.*)|*.*|Movie Files (*.mov)|*.mov|Flash Files 
      (*.swf)|*.swf"
   openDial.CommonDialog1.FilterIndex = 2
   openDial.CommonDialog1.Flags = 4

   ' hide the "Read Only" check box
   openDial.CommonDialog1.CancelError = True
   openDial.CommonDialog1.ShowOpen

   OpenFile (openDial.CommonDialog1.FileName)
   Unload openDial
   Exit Sub

bail:

   ' the user pressed the Cancel button

   Unload openDial
   Exit Sub
End Sub

The FileOpen_Click handler uses standard Visual Basic methods, except for the application defined OpenFile method, shown in Listing 3.

Listing 3: Opening a movie file

Sub OpenFile(fileNm As String)
   Dim movieWind As New MovieWindow

   If Len(fileNm) = 0 Then
      movieWind.Caption = "Untitled"
   Else
      movieWind.Caption = BaseName(fileNm)
      movieWind.QTActiveXPlugin1.SetURL (fileNm)
   End If

   movieWind.Show
End Sub

It's important to note that a QuickTime-savvy ActiveX control does not so much remove the dependence on QTML as hide it. That is to say, although the Visual Basic developer doesn't need to know about MacOS data types, the person who wrote the ActiveX control does. And even the VB developer might need to know about MacOS data types when using the declare statement to reference external procedures in the QTML library. This would happen if the developer needs to access QuickTime functionality that was not implemented in whichever ActiveX control he or she is using.

Mac OS X

QuickTime's migration from MacOS to Mac OS X is remarkably similar in spirit to its migration from MacOS to Windows. Once again, a software layer was added to support the Macintosh Operating System and User Interface Toolbox managers that originated on MacOS and which are used extensively throughout the QuickTime source code. Mac OS X is a UNIX-based operating system and provides no more native support for QuickTime than does Windows. In this case, the implementation of the Macintosh Operating System and Toolbox managers is provided by a library called Carbon. The only real difference between QTML and Carbon is that Carbon has evolved more swiftly than QTML. For instance, as mentioned earlier, the Standard File Package has long since been deprecated on Macintosh computers, having been replaced by the Navigation Services (which supports longer filenames and alternate text encoding schemes such as Unicode).

The move to Mac OS X has prompted two additional sorts of changes to QuickTime APIs, above and beyond the changes required for it to keep pace with enhancements in the Carbon library. First, a reasonably extensive Cocoa framework, QTKit, was developed to replace the existing QuickTime-related classes, NSMovie and NSMovieView. We investigated QTKit in several recent articles (MacTech, May, June, and July 2005) and saw that we can develop full-featured Cocoa applications with only minimal need to venture outside of the methods it provides. And venturing outside of Cocoa is easy, because Objective-C is a superset of ANSI C. This means that we can easily call Carbon APIs within our Cocoa code. For example, Listing 4 shows a method for setting the magnification level of a Flash movie opened using QTKit. Notice that we call GetMovieIndTrackType to find the first Flash track in the movie, and then we call GetTrackMedia, GetMediaHandler, and FlashMediaSetZoom to set the zoom level of that track.

Listing 4: Setting the zoom level of a Flash movie

- (void)setZoom:(float)zoomPct
{
   Track flashTrack = NULL;
   Media flashMedia = NULL;
   MediaHandler flashHandler = NULL;
   
   flashTrack = GetMovieIndTrackType([self quickTimeMovie], 
                        1, FlashMediaType, movieTrackMediaType | 
                        movieTrackEnabledOnly);
   if (flashTrack) {
      flashMedia = GetTrackMedia(flashTrack);
   flashHandler = GetMediaHandler(flashMedia);
      FlashMediaSetZoom(flashHandler, zoomPct);
   }
}

The second principal way in which Mac OS X has affected QuickTime, on the API level, is the adoption within QuickTime of Core Foundation data types. Core Foundation is a procedural C framework that is modeled on the object-oriented Foundation framework in Cocoa. It provides, among other things, some very nice collection classes (such as arrays and dictionaries) and Unicode-compatible strings. QuickTime 6.4 introduced, for instance, several functions for creating data references from Core Foundation data types like CFString and CFURL, including these:

QTNewDataReferenceFromFullPathCFString
QTNewDataReferenceFromURLCFString
QTNewDataReferenceWithDirectoryCFString

And we saw in an earlier article ("State Property" in MacTech, November 2005) that the QuickTime property function QTGetMoviePropertyInfo can return reference-counted Core Foundation objects that need to be released (by calling CFRelease). Interestingly enough, these Core Foundation data types and functions are supported now on Windows as well as on Mac OS X.

Conclusion

So where do we stand here in early 2006? The good news is that Apple and third-party developers have invested considerable resources into making sure that the major programming tools and development environments support some level of QuickTime movie playback and editing. Moreover, the QuickTime APIs have kept pace with changes in the Carbon library and have expanded to provided support for Cocoa and Core Foundation programming paradigms.

The bad news, if there is any, is that some important parts of QuickTime are still accessible only using functions and data types are arose on MacOS, a now-deprecated operating system. It would be nice to never have to allocate another Handle object. We aren't quite there yet. But surely some day we will be.

Tim Monroe is a member of the QuickTime engineering team at Apple. You can contact him at monroe@mactech.com. The views expressed here are not necessarily shared by his employer.