State Property
Volume Number: 21 (2005)
Issue Number: 11
Column Tag: Programming
QuickTime Toolkit
State Property
by Tim Monroe
Working with QuickTime Properties and Property Listeners
In the previous QuickTime Toolkit article ("The Informer" in MacTech, October 2005), we took a look at the
QuickTime metadata functions, which are a replacement for the existing user data functions. We saw that we can
use the functions QTMetaDataGetItemProperty and QTMetaDataSetItemProperty to get and set metadata item
properties, and that we can use the function QTMetaDataGetItemPropertyInfo to get information about a metadata
item property (such as the type or the size of its data).
Introduction
You should get used to this pattern of function naming: SetProperty, GetProperty, and GetPropertyInfo.
That's because, as of QuickTime version 6.4, this is now the preferred pattern of naming for functions that
inspect and set properties. QuickTime 6.4 introduced the trio of functions QTSetComponentProperty,
QTGetComponentProperty, and QTGet ComponentPropertyInfo for working with component properties. It also
introduced the functions QTSetMovieProperty, QTGetMovie Property, and QTGetMoviePropertyInfo for working with
movie properties. And QuickTime 7 has accelerated this trend. A quick search through the latest QuickTime
header files reveals about a dozen additional triples of property-related functions, from ICMImage
DescriptionGetProperty (and its siblings) to MovieAudioExtractionGetProperty (and its siblings).
We've already seen some of the advantages of this new scheme for querying and setting properties. In the
case of movie metadata, we could iterate through all metadata items associated with a movie, for instance, and
retrieve and display the values of those items without knowing in advance either the size or the type of those
values. That's because we could use the QTMetaDataGetItemPropertyInfo function to query the metadata item for
that information. Also, QuickTime can add new properties to the target objects (movies, tracks, metadata
items, image descriptions, and so on) without having to add new functions to get or set those new properties.
And, of course, the advantages of conforming all these various property accessor functions to a single calling
pattern should be obvious. Once we've learned the parameter list for one of the GetProperty functions, we've
effectively learned it for the other dozen similar functions.
But, for several of these target objects, there is an additional payoff. Not only does QuickTime provide a
unified mechanism for getting and setting the object's properties, it also provides a mechanism for our
applications to be notified when one of these properties changes. That is to say, we can install a movie
property listener, an application-defined callback procedure that is executed when the value of a specified
property changes. In my mind, this is very important, as it relieves us of the necessity to continually poll
the movie for the value of a property we are interested in.
In this article, we'll investigate the movie property functions QTSetMovieProperty, QTGetMovieProperty, and
QTGetMoviePropertyInfo, as well as the function to install a movie property listener,
QTAddMoviePropertyListener.
QuickTime Properties
Let's begin by looking at the declarations of the three principal movie property functions, from the header
file Movies.h. QTGetMoviePropertyInfo is declared like this:
OSErr QTGetMoviePropertyInfo (
Movie inMovie,
QTPropertyClass inPropClass,
QTPropertyID inPropID,
QTPropertyValueType * outPropType,
ByteCount * outPropValueSize,
UInt32 * outPropertyFlags);
And the functions QTGetMovieProperty and QTSetMovieProperty are declared like this:
OSErr QTGetMovieProperty (
Movie inMovie,
QTPropertyClass inPropClass,
QTPropertyID inPropID,
ByteCount inPropValueSize,
QTPropertyValuePtr outPropValueAddress,
ByteCount * outPropValueSizeUsed);
OSErr QTSetMovieProperty (
Movie inMovie,
QTPropertyClass inPropClass,
QTPropertyID inPropID,
ByteCount inPropValueSize,
ConstQTPropertyValuePtr inPropValueAddress);
As you can see (and as you may recall from the previous article on movie metadata), we specify a particular
movie property by providing a property class and a property ID. These values, as well as the property value
type returned by QTGetMoviePropertyInfo, are all declared as OSTypes:
typedef OSType QTPropertyClass;
typedef OSType QTPropertyID;
typedef OSType QTPropertyValueType;
In addition, the parameters in which data values are passed or returned are declared in the obvious manner:
typedef void * QTPropertyValuePtr;
typedef const void * ConstQTPropertyValuePtr;
So all we really need to know, to be able to use these functions, are the available property classes and
their associated property IDs. The file Movies.h contains definitions of quite a number of constants beginning
with "kQTPropertyClass_"; currently, however, most of these classes of movie properties cannot be used with
the movie property functions. In this article, we'll look at only two of those classes, for accessing audio
and video properties:
enum {
kQTPropertyClass_Audio = 'audi',
kQTPropertyClass_Visual = 'visu'
};
Most of the other currently defined property classes (for instance, kQTPropertyClass_DataLocation) and
their associated properties are intended for use with the new function NewMovieFromProperties, which we'll
investigate in the next QuickTime Toolkit article. (If perchance we did try to read or write one of those
other properties using QTGetMovieProperty or QTSetMovieProperty, we would receive the error code
kQTPropertyNotSupportedErr.)
For the class kQTPropertyClass_Visual, these property IDs are defined:
enum {
kQTVisualPropertyID_Hue = 'vhue',
kQTVisualPropertyID_Saturation = 'vsat',
kQTVisualPropertyID_Brightness = 'vbrt',
kQTVisualPropertyID_Contrast = 'vcon'
};
All these properties can be gotten or set, and all return or take parameters of type Float32.
For the class kQTPropertyClass_Audio, Movies.h contains enumerated constants for just over a dozen
properties. However, most of those properties cannot be accessed using QTGetMovieProperty or
QTSetMovieProperty. The following properties are accessible using those functions:
enum {
kQTAudioPropertyID_Gain = 'gain',
kQTAudioPropertyID_Mute = 'mute',
kQTAudioPropertyID_Balance = 'bala'
};
The gain and balance properties operate on values of type Float32, and the mute property operates on values
of type Boolean.
Getting and Setting Property Values
It's quite straightforward to get and set these properties on a QuickTime movie. Consider for example the
kQTVisualPropertyID_Brightness property, which governs the brightness adjustment of a movie. This property can
takes values ranging from -1.0 (which means the image has no brightness and is hence totally black) to 1.0
(which means the image has maximum brightness and is hence totally white); normal brightness is 0.0. We can
programmatically fade a movie to black using the function defined in Listing 1.
Listing 1: Setting a movie's brightness
void FadeMovieToBlack (MovieController mc)
{
Float32 origValue, value;
Movie movie = MCGetMovie(mc);
// get the current value of the brightness adjustment
QTGetMovieProperty(movie, kQTPropertyClass_Visual,
kQTVisualPropertyID_Brightness, sizeof(origValue),
& origValue, NULL);
// gradually decrease the brightness to total darkness
for (value = origValue; value >= -1.0; value -= 0.01) {
QTSetMovieProperty(movie, kQTPropertyClass_Visual,
kQTVisualPropertyID_Brightness, sizeof(value),
&value);
usleep(10000);
MCDraw(mc, nil);
}
}
Figure 1 shows a QuickTime movie in a movie window, and Figure 2 shows the half-way point of the fading
that movie to black.
Figure 1: A movie with the default
brightness
Figure 2: A movie with halved
brightness
This is very cool. Even cooler perhaps is to gradually increase the movie's brightness to total white,
which we can do by stepping up from the current brightness to 1.0. (Try it; you'll like it.) Keep in mind that
the brightness adjustment is only a temporary adjustment and is not saved into the movie file, even if you
update the movie file on disk. Ditto for all the other audio and visual properties listed above.
You should also know that the new properties-based APIs are not meant to exclude more classic style APIs.
That is, instead of QTGetMovieProperty and QTSetMovieProperty with the specified property class and ID, we
could use GetMovieVisualBrightness and SetMovieVisualBrightness. So we could replace the call to
QTSetMovieProperty in Listing 1 by this line:
SetMovieVisualBrightness(movie, value, 0);
The third parameter here is a set of flags, which is currently unused.
Deallocating Property Values
Consider now this question: once we're finished working with a piece of property data, what do we do with
it? Surely, the answer depends on the type of value returned by QTGetMovieProperty, which we can determine by
inspecting the outPropType parameter in QTGetMoviePropertyInfo. Simple values like Booleans or integers or
OSTypes are just copied into the local storage pointed to by the inPropValueAddress parameter and will be
cleaned up when the stack frame is destroyed. But what about things like strings or handles or structures?
The answer lies in the QTGetMoviePropertyInfo function. Its last parameter is a pointer to a set of
property flags that contain useful information about the property values returned by a call to
QTGetMovieProperty. Currently these flags are defined (in the header file ImageCompression.h):
enum {
kComponentPropertyFlagCanSetLater = (1L << 0),
kComponentPropertyFlagCanSetNow = (1L << 1),
kComponentPropertyFlagCanGetLater = (1L << 2),
kComponentPropertyFlagCanGetNow = (1L << 3),
kComponentPropertyFlagHasExtendedInfo = (1L << 4),
kComponentPropertyFlagValueMustBeReleased = (1L << 5),
kComponentPropertyFlagValueIsCFTypeRef = (1L << 6),
kComponentPropertyFlagGetBufferMustBeInitialized = (1L << 7),
kComponentPropertyFlagWillNotifyListeners = (1L << 8)
};
As you might guess, the interesting flags right now are the ValueMustBeReleased and ValueIsCFTypeRef flags.
If the ValueMustBeReleased flag is set in the returned set of property flags, then we need to release the
property value once we are done with it. And if the ValueIsCFTypeRef flag is set, then the returned property
value is a reference-counted Core Foundation type and we should release that value by calling CFRelease.
There is one complication here, which is that the values returned in the outPropType parameter to QTGet
MoviePropertyInfo are to my knowledge not currently documented. So in cases where the ValueMustBeReleased flag
is set but the Value IsCFTypeRef flag is clear, we wouldn't know what routine to call to release the property
value. Happily, the values for the property classes and IDs described above are either Float32 or Boolean,
which require no deallocation. So for the moment we really don't need to worry about checking those flags.
In the future, however, as the list of gettable and settable movie properties expands, it would be nice to
have available a more satisfying way to know how to release the property values. I assume that at that point
the relevant data type constants will be exposed. In the meantime, here are a few constants we can use for the
principal allocated types:
enum {
kMyTypeCFTypeRef = 'cfty',
kMyTypeQDPicture = 'pict',
kMyTypeTextHandle = 'text',
kMyTypeHandle = 'hndl',
kMyTypeQTAtomContainer = 'qtat',
kMyTypeUserData = 'udat'
};
Listing 2 shows a function ReleasePropertyValue that we can use to determine whether a property value needs
to be released and, if so, to deallocate values of these types. As you can see, we pass in the values we
receive from QTGetMoviePropertyInfo.
Listing 2: Handling value deallocation
void ReleasePropertyValue (QTPropertyClass propClass,
QTPropertyID propID, QTPropertyValueType propType,
QTPropertyValuePtr propValueAddress,
ByteCount propValueSize, UInt32 flags)
{
// make sure there is storage that must be released
if (propValueSize == 0)
goto bail;
if ((flags & kComponentPropertyFlagValueMustBeReleased)
== 0)
goto bail;
if (flags & kComponentPropertyFlagValueIsCFTypeRef) {
// we've got a CFTypeRef; release it
CFRelease((CFTypeRef)propValueAddress);
goto bail;
} else {
// not a CFTypeRef; look for handles and atom containers
switch (propType) {
case kMyTypeHandle:
case kMyTextHandle:
case kMyTypeQDPicture:
if (propValueAddress)
DisposeHandle((Handle)propValueAddress);
break;
case kMyTypeQTAtomContainer:
if (propValueAddress)
QTDisposeAtomContainer
((QTAtomContainer)propValueAddress);
break;
default:
break;
}
}
bail:
return;
}
Property Listeners
There is, as far as I can see, no particular advantage to using the new movie property functions instead of
specific APIs like SetMovieVisualBrightness. The real power of this new set of functions arises from the
ability to be informed of changes in movie properties by installing movie property listeners. That is, these
new functions allow us to monitor the value of a specific movie property without having to continually poll
its value. For instance, we could install a listener for the property class kQTPropertyClass_Audio and the
property ID kQTAudioPropertyID_Gain in order to be informed about changes to the movie's volume.
We install a property listener for a specific property class and ID by calling the
QTAddMoviePropertyListener function, declared like this:
OSErr QTAddMoviePropertyListener (
Movie inMovie,
QTPropertyClass inPropClass,
QTPropertyID inPropID,
QTMoviePropertyListenerUPP inListenerProc,
void * inUserData);
As you can see, we need to indicate the class and ID to be monitored, as well as a pointer to the function
to be called when that property changes. We can also pass in a pointer to some application-specific data (that
is, a reference constant or refcon). So, for instance, to listen for volume changes, we could execute this
code:
QTAddMoviePropertyListener(movie,
kQTPropertyClass_Audio, kQTAudioPropertyID_Gain,
(QTMoviePropertyListenerUPP)&PropChangedCallback,
NULL);
The callback function PropChangedCallback might be defined as in Listing 3.
Listing 3: Handling property changes
void PropChangedCallback (Movie movie,
QTPropertyClass propClass, QTPropertyID propID,
void *refcon)
{
switch (propClass) {
case kQTPropertyClass_Audio:
switch (propID) {
case kQTAudioPropertyID_Gain:
// do something interesting, like update a volume slider
break;
default:
break;
}
break;
default:
break;
}
}
You might recall that QuickTime already provides a similar capability in the form of the movie controller
action filter procedure, which is informed of actions associated with a movie controller. In a movie
controller action filter procedure, we can watch for actions of type mcActionSetVolume and respond
accordingly. But there are several important differences between using a movie controller action filter
procedure and using a movie property callback function. First, the property callback is executed only when the
associated property actually changes value; by contrast, the action filter procedure receives a
mcActionSetVolume whenever an mcActionSetVolume command is issued to the movie controller, even if the
specified volume is the same as the current volume. Also, mcActionSetVolume is sent to a filter procedure only
by movie controller-related calls or user actions; in particular, it is not sent when Movie Toolbox calls
(such as SetMovieVolume) are made. By contrast, the movie property callback is executed for movie controller
and Movie Toolbox volume changes. In both respects, the movie property listening behaviors seems preferable to
the movie controller action filter procedure behaviors.
When we are finished listening to a specific movie property, we should unhook the property listener by
calling QTRemoveMoviePropertyListener, like this:
QTRemoveMoviePropertyListener(movie,
kQTPropertyClass_Audio, kQTAudioPropertyID_Gain,
(QTMoviePropertyListenerUPP)&PropChangedCallback,
NULL);
This is stop PropChangedCallback from being called when the volume of the specified movie changes.
One final point: not all movie properties are currently listenable. We can determine whether a specific
property is listenable by calling QTGetMoviePropertyInfo and inspecting the set of property flags returned. If
the kComponentPropertyFlagWillNotifyListeners flag is set, then that property is indeed listenable.
Conclusion
The movie property functions introduced in QuickTime version 6.4 provide a standard way for us to get and
set some of the properties associated with QuickTime movies. And, perhaps more important, they provide an easy
and reliable way for us to monitor changes in those properties, by installing property listeners. In this
article, we've seen how to work with the handful of audio and visual properties that are currently supported
by these functions. In the next article, we'll continue working with movie properties, by looking at a new
function for opening a QuickTime movie specified by a collection of properties, NewMovieFromProperties.
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.
