ActiveMovie provides a comprehensive set of services for playback of MPEG movies, bringing users the best-quality video available today on mainstream systems. For machines without hardware MPEG decoding hardware, ActiveMovie will decode MPEG entirely in software using technology Microsoft licensed from Mediamatics, Inc. On an Intel® 90 Mhz Pentium®-based PC with a low-cost graphics adapter, ActiveMovie is capable of playing back MPEG movies at 24 frames-per-second with 11 KHz stereo.

To provide the power to play interactive MPEG-based titles and emerging high-quality MPEG II movies, ActiveMovie has been designed to take advantage of MPEG decoding hardware transparently. With MPEG-based hardware, consumers will be able play a wide variety of digital video disk (DVD) MPEG II-based movies and titles on their computers.

For Internet applications and content, ActiveMovie provides easy-to-integrate video and audio playback services. The beta software development kit (SDK) includes an easy-to-use OLE Control that Internet developers can use to add video playback and real-time media streaming to Internet applications. ActiveMovie is scheduled to be integrated with and included in the next release of Microsoft Internet Explorer, enabling Internet users to play back popular media formats on the Web efficiently, including MPEG Audio and Video, .AVI files, QuickTime®, AU, .WAV, and AIFF.

With a few exceptions, ActiveMovie replaces digital video technology and APIs provided by Microsoft in previous versions of the Windows Software Development Kit (SDK). However, for applications that use the older Microsoft media streaming services, such as Microsoft Video for Windows, libraries will continue to be available and supported. In some cases, such as video capture, the first release of ActiveMovie does not provide a direct replacement. In these cases, developers may find an opportunity to use ActiveMovie to provide their own solutions with the help of the many samples provided in the ActiveMovie SDK.

The ActiveMovie architecture defines how streams of time-stamped multimedia data can be controlled and processed by using modular components called filters connected in a configuration called a filter graph. An object called the filter graph manager is accessed by applications via programatic interfaces and controls how the filter graph is assembled and how data is moved through the filter graph. Additionally, a simple application-level visual programming utility, called the filter graph editor, is included in the ActiveMovie SDK, This utility allows developers to construct and test filtergraphs simply and easily. The following illustration shows the relationship of applications and the components of ActiveMovie.

A filter graph is a configuration of filters of different types. Most filters can be categorized into one of the following three types:

• A source filter, which takes the data from some source, such as a file on disk, a satellite feed, an internet server, or a VCR and introduces it into the filter graph.
• A transform filter, which takes the data, typically processes it, and then passes it along.
• A rendering filter, which renders the data; typically this is rendered to a hardware device, but potentially could be rendered to any location that accepts media input (such as memory or a disk file).

For example, the Microsoft MPEG filter graph uses the following filters:

• A source filter to read the data off the disk.
• A splitter transform filter to separate the video and audio.
• A video transform filter to decompress the video data.
• A video rendering filter to display the data on the screen.
• An audio transform filter to decompress the audio data.
• An audio rendering filter to send the audio data to the sound card.

The following illustration shows the MPEG filter graph.

The following filters are provided as part of the ActiveMovie SDK.

• MPEG, AVI, and QuickTime source filters.
• MPEG, AVI and QuickTime video decompression filters.
• MPEG audio decompression filter
• MPEG stream splitter
• DirectX-compatible video and audio rendering filters
• Additional sample code filters delivering special effects such as video contrast.

Developers who wish to add to the above list, may easily create their own filters using tools and samples provided in the SDK.

Filter graphs are used to stream media data, in units called samples, through filters. In the media stream, one filter passes media samples downstream to the next filter. Media samples flow downstream from source filter to renderer, but other information is passed upstream from renderer to source filter, as will be described later.

The filter graph manager connects filters and controls the media stream. For a filter graph to work, filters must be connected in the proper order. The filter graph manager can load preconfigured filter graphs, or can search for filters and assemble a filter graph that will render a particular media type.

When searching for filters to be used to render a media type, the filter graph manager uses a filter mapper object, which reads the system registry and determines the types of filters available. The filter graph manager then uses information registered with the filters to select and connect the correct filters in the proper order to render a defined media type.

ActiveMovie is accessible at many levels, and the approach used depends on the requirements of the application and the investment in development that is desired. The filter graph manager provides a set of Component Object Model (COM) interfaces to allow communication between the filter graph and the application. Applications can make direct calls to the filter graph manager interfaces to control the media stream or retrieve filter events. Or they can use the ActiveMovie OLE control for higher-level programming. The OM-1 MPEG MCI command set is also supported, which provides backward compatibility to applications that used the MCIAVI commands in Microsoft Video for Windows 1.x. The following illustration shows how applications can access ActiveMovie services.

Typically, existing applications that use the MCI command set are easily ported, whereas applications that access lower-level multimedia services will take more work to rewrite.

When writing a new application, developers have several options. To add ActiveMovie services like MPEG and QuickTime video playback to an exiting application developers can incorporate the ActiveMovie OLE control into their applications or access the COM interfaces on the filter graph manager directly. Both Visual Basic version 4.0 and Visual C++ allow access to the control or the COM interfaces. Filters within a filter graph are typically written in C or C++ for best performance. The ActiveMovie SDK provides a C++ class library for writing filters, the ActiveMovie OCX control, and tools for constructing and testing filter graphs. It also provides many sample filters as well as comprehensive documentation.

Developers who want to modify the media stream in some way, for example, to create special video effects, or source video from a special source, can incorporate both the filter graph manager object and a custom filter. The instantiated filter graph manager is used to generate and manage the filter graph, and the custom filter can be inserted in a preconfigured filter graph, which can then be loaded by the filter graph manager.

Alternately, an application can dynamically insert a custom filter into an existing filter graph that has been created by the filter graph manager. For example, an application that plays MPEG movies and introduces a video effects filter into the media stream can instantiate the filter graph manager, instruct it to build an MPEG playback filter graph, and can then insert the effects filter into the filter graph.

ActiveMovie defines objects and interfaces that exchange streams of time-based data. In particular, it defines interfaces for the following requirements:

• Connecting filters to other filters
• Negotiating data types
• Transporting data between filters
• Synchronizing presentation of data
• Graceful degradation of rendering in cases of insufficient resources

The two basic components used to stream media are filters and pins. A filter is a COM object that performs a single task such as reading media from a disk file or performing an effect on a video stream. For each media stream it handles, a filter creates one at least one pin. A pin is a COM object that represents a point of connection for a unidirectional data stream on the filter, as shown in the following illustration.

An input pin receives media samples and an output pin passes media samples on to the next filter. A source filter provides one output pin for each stream of data in the file. A typical transform filter, such as a decompression filter, provides one input pin and one output pin, while an audio output filter typically exposes only one input pin. More complex arrangements are also possible.

Interfaces on a filter are provided to allow the filter graph manager to query the filter for status information, to access pins, and to issue run, stop, and pause commands when controlling the media stream. Filters also provide interfaces to allow themselves to be saved as part of a persistent filter graph and can optionally provide interfaces to support property pages that allow end users to select filter properties.

Pins are responsible for providing interfaces to connect with other pins and for transporting the data. The pin interfaces support the following services:

• The transfer of time-stamped data using shared memory or another resource.
• Negotiation of data formats at each pin-to-pin connection
• Buffer management and buffer allocation negotiation designed to minimize data copying and maximize throughput.

Pin interfaces differ slightly, depending on whether they are output pins or input pins. Both type of pins support interfaces to connect to other pins, to allow media types to be enumerated by a connected pin, to pass media samples between pins, and to pass quality control notifications upstream, from renderer to source filter. The input pin exposes an additional interface to provide a buffer for transporting the media samples on a connection if the output pin does not already have one. The output pin exposes an additional interface to allow media positioning commands (such as where to start and stop playing a stream) to be passed up stream from renderer to source filter.

Negotiation of media types and buffers between pins is an important part of the pin connection model. The ability to enumerate, propose, and select common media types allows filters to be plugged in to streams that support their media types. The negotiation of buffers is essential in reducing unnecessary copying. Many transform filters in a filter graph perform their transformation of the media in buffers belonging to another filter and eliminate the need to copy each sample. The connection model handles the connection, negotiation, and reconnection necessary when filter graphs are constructed.

ActiveMovie provides for graceful adaptation of media rendering to overloaded or underloaded media streams. A quality control interface is used to send quality control notification messages upstream to a filter that can affect the quality of rendering in the most efficient manner. For example, a video rendering filter that is getting too many frames to process can notify an upstream filter, often the source filter, to cut down on the number of frames it is sending. This is usually more efficient than simply dropping frames at the renderer since filters in between do not waste CPU cycles on samples that will not be rendered. Likewise, when the renderer filter senses it could handle more data, it sends notifications to increase the number of samples. Quality control messages are passed upstream using an interface implemented on all pins. A filter can also register itself as a quality sink and get the quality message directly.

Reference clock synchronization is accomplished by implementing a reference interface on any filter that has a reference clock. For example, because sound cards are predominantly used for reference clocks, the audio renderer filter implements this interface, which essentially allows any caller to register for time notifications.

ActiveMovie allows applications to communicate with the filter graph manager, and the filter graph manager to communicate with individual filters to control the movement of the data through the filter graph. It also allows filters to post events that can be retrieved by the application, so an application can, for example, retrieve status information about a special filter it has installed.

The filter graph manager exposes media control and media positioning interfaces to the application. The media control interface allows the application to issue commands to run, pause, and stop the stream. The media positioning interface lets the application specify what section of the stream to play. Additionally, the filter graph manager has interfaces that let the application queue commands to be played at a future time.

Individual filters expose a media control interface so that the filter graph manager can issue the run, pause, and stop control commands. The filter graph manager is responsible for calling these methods in the correct order on all of the filters in the filter graph.

The position commands are handled less directly. Unlike the media control interface, only the renderer filter exposes a media position interface. The filter graph manager calls the renderer filter with positioning information, such as when to start and stop a media stream. The renderer then passes this position control information upstream through media position interfaces exposed on the pins to the source filter, which is responsible for selecting the media samples to play. Position information is passed serially upstream because there may be filters between the renderer and the source filter that need to know about positioning information. Of course, a source filter that is getting data from a source such a streaming internet server like the Microsoft Multimedia Server, or a satellite feed, may not be able to select positioning of the media as it can when reading from a file.