MPEG Playback Technologies Explained

MPEG playback for multimedia titles is a feature of interest to many developers, but there are several different technologies available to enable it. Which one is more adequate to your specific product? This article attempts to discuss the technical characteristics of each technology and the typical usage for each one. For a less technical discussion please consult technote GN002. It has a table with the most common development scenarios, and the Xtra/solution that is better suited for it.

1. Macintosh
Macintosh computers play MPEG1 files by using Quicktime 3 or later. Just import the .mpg file in Director on the Macintosh, and it will be instantly recognized as a Quicktime media type, using the Quicktime Xtra included with Director. MPEG2 can be played if Quicktime 5 or later is installed, and the optional Quicktime MPEG2 extension is also present. This extension is available directly from Apple, and costs around U$ 20 per platform and copy. MPEG4 support is available starting with Quicktime 6, and no additional extensions are required.

Mpeg Advance Xtra uses the Quicktime engine services to play MPEG files on the Macintosh platform, exactly like the Quicktime Xtra. It also supports MPEG2/4 playback, and has extended facilities for editing of cuepoints and image support compared with the standard Quicktime Xtra supplied with Director.

2. Windows
There are two native interfaces used to play MPEG files on Windows : MCI (Media Control Interface) and ActiveMovie/DirectShow. The Quicktime engine can also be used to play MPEG on Windows starting with Quicktime 5.

The original (discontinued) MpegXtra used the MCI interface, while DirectMediaXtra (also discontinued) and Mpeg Advance Xtra are DirectShow-based players when running on Windows. We will discuss the characteristics of each interface below.

2.1 ActiveMovie/Directshow
The ActiveMovie/DirectShow engine in theory does not suffer from MCI's major flaw: once installed, it can coexist with other MPEG players, since all invocation of its services is done directly using its register GUID. What this means is that if an application is coded to use its services directly, it will work if the services are installed, period. No messing with win.ini and system.ini files. Microsoft's standard installation of ActiveMovie/DirectShow contains MPEG1 decompression filters since version 1, so you are guaranteed to get MPEG1 playing if the services are installed. ActiveMovie shipped with all Windows 95B machines (since Nov/96), and its successor, DirectShow, is installed with Internet Explorer 4 and later, and comes pre-installed with Windows 98. DirectShow is also the only media playback device supported officially in Windows 2000 and XP, and the one that works best in Windows NT4 machines.

For older machines you can still include the latest DirectShow installer on your CD, free of royalties. Most MPEG1 projects target at least a Pentium 133 as a minimum requirement. It is safe to assume that over 90-95% of Windows systems with Pentium 133 and higher processors did ship with at least ActiveMovie 1 pre-installed. So the installed based is big, and as we move on the number of machines that do not have it will be reduced dramatically. This clearly puts the ActiveMovie/DirectShow engine as the preferred way to get guaranteed MPEG1 playback for projects that will get distributed in large quantities, for the average multimedia user.

And if you are committed to using the ActiveMovie/DirectShow engine, you probably should consider talking to it directly from your code, in order to remove the MCI driver layer, and its associated configuration issues. There are two ways to talk to the DirectShow engine directly from your Director application: one is to use our Mpeg Advance Xtra, and the other is to embed the ActiveMovie ActiveX control using Macromedia's ActiveX Xtra. The later is discussed in a technote at Macromedia's site. I should point out that this solution, while free, does have some drawbacks: there are no easy ways to customize the appearance of the ActiveX control, and to resize it easily, or get around the border issue. The control also does not pass mouse and key events to Director, and using it requires intermediate to advanced Lingo skills. But the biggest problem is that this method really does not address the DirectShow engine directly: you get to it via an ActiveX control, which in turn calls the DirectShow API. What happened? The new Windows Media Player replaced the original ActiveX control on newer systems, with a different set of methods, so if you had a job coded for the original ActiveX control this movie does not work any longer in the new, upgraded machine! This somehow defeats the whole purpose of using the DirectShow API, but it is still an option worth investigating for some projects.

We recommend Mpeg Advance Xtra, for several reasons: the code calls the DirectShow API directly. It works with ActiveMovie version 1, version 2, and with all incarnations of the DirectShow engine, including several minor revisions. It will work if you have the original ActiveMovie control or the new Media Player, or any future player technology built on top of the same API, as long as the core services are still supported by Microsoft. The media appears as a true castmember in Director: you can drag it to stage and resize/position it freely, with WYSIWYG feedback. You have access to mouse and key events that occurs over the sprite area. Cuepoints can be created easily, and you can use the tempo channel to wait for a cuepoint or the end of playback. The Xtra also keeps track of linked media for you, gives you the ability to play only segments of the media, hide/show the cursor, etc... Playback of MPEG1 files is guaranteed on every system that has the ActiveMovie/DirectShow engine installed, even if you have multiple, conflicting MCI-based MPEG players in the system. There is a drawback... you do pay a price for the Xtra, since it is a commercial product. We believe it will pay for itself many times in the first project that you use it into, but one of the free alternatives presented above may be more indicated for some projects, depending on the complexity of it.

Mpeg Advance Xtra is also currently the only cross-platform DirectShow based Xtra. What it means is that your movie using Mpeg Advance Xtra castmembers can be moved to a Macintosh machine without any modifications. On the Macintosh the Mpeg Advance Xtra will use Quicktime to play the MPEG files. This all happens transparently to the Director developer, with no additional work required. Other solutions (like the ActiveX Xtra) will not work on the Macintosh, and the developer will have to produce a different .dir file, using Quicktime Xtra castmembers.

2.2 Quicktime for Windows
Starting with Quicktime 5 it is possible to play MPEG files on Windows on every system that has Quicktime installed. The Director developer can import MPEG files as Quicktime castmembers directly. The drawback of this method is that an installation of the latest version of Quicktime is needed on every machine that will play your content. This is usually a restriction for some corporate users and other controlled environments, and some users may prefer to simply play your presentation directly from a CD, with no installations needed. That is the main reason for the existence of Mpeg Advance Xtra and other native Windows video Xtras.

2.3 MCI
Note: The MCI description is maintained in this technote for documentation purposes, since recent Windows systems and Director versions do not use it anymore.

MCI was created for Windows 3.1, and it is was deprecated by Microsoft in 1999. MCI is not officially supported in Windows 2000 and later, so if you plan to distribute your work in current Windows systems you should use DirectShow. Even if it is no longer recommended by Microsoft the MCI interface will still be around for several years, specially for projects directed primarily at Windows 95 machines. MCI devices are configured in the SYSTEM.INI and WINDOWS.INI file on a Windows 3.1/95/98 machine (we will talk about NT in a second.) Only one MCI device can be active for a given file extension at any given type, and this typically leads to misconfiguration issues when people start to install and uninstall MPEG players on their system and the installer mess with the .ini files. A properly configured system usually shows something like:

WIN.INI

[mci extensions]

....

mpg=MPEGVIDEO

vob=MPEGVIDEO

...

Here, you can see that the mpg extension is associated to the MPEGVideo device. It is not necessarily associated with this device on all machines. A given player may want to associate the mpg extension with another device, named MYPLAYERDEVICE, for example. What is important is that the name of the device will be used to determine which driver will kick in when you attempt to play a file ending with this extension using MCI. This is defined in SYSTEM.INI:

SYSTEM.INI

[mci]

cdaudio=mcicda.drv

sequencer=mciseq.drv

waveaudio=mciwave.drv

avivideo=mciavi.drv

videodisc=mcipionr.drv

vcr=mcivisca.drv

MPEGVideo=ctencmci.drv

In this particular machine the MPEGVideo device is associated with the ctencmci.drv file. What is this file? This is CreativeLabs PC_DVD Encore driver, a DVD decoder. So in this particular machine, every time a program try to open a .mpg or .vob file through MCI calls, the Creative Driver will kick in. You may have other decoders installed on this machine (Microsoft's ActiveMovie/DirectShow is usually present), but MCI does not know anything about them. Again, as far as MCI is concerned, .mpg files will be opened by the MPEGVideo device, and it is currently linked to a file named ctencmci.drv, which happens to be CreativeLabs driver.

A parenthesis: Microsoft includes a MPEG capable system architecture, formerly known as ActiveMovie, now renamed DirectShow, with every Windows 95B or Windows 98 system. This architecture was meant to replace MCI as the default way to play Media in Windows. To make the transition easier Microsoft included a MCI driver for the ActiveMovie/DirectShow engine with the default installation. Think of it as a compatibility layer: what this driver does is to make possible to use ActiveMovie/DirectShow services from applications that were coded to use MCI, provided the system has this driver enabled.

This driver usually shows up as:

MpegVideo=mciqtz.drv

in SYSTEM.INI. So in a system configured like this you can access the underlying ActiveMovie/DirectShow engine through MCI, and it will behave like any other MCI-driven MPEG decoder. While this is good, it will only work if the MCI configuration shown above is correct, and by default ActiveMovie/DirectShow does NOT register itself as the default player for MCI content if it finds another MPEG player already registered. To guarantee that your code will use ActiveMovie/DirectShow in all systems you would have to use an Xtra/technique that talks directly to the ActiveMovie/DirectShow engine, not via the MCI driver mciqtz.drv. These techniques are described in the next section of this technote. Back to MCI: you can use MCI directly from Director using the mci Lingo keyword, but the tricky part is to get the handle to the stage windows (can be done with Xtras like BuddyAPI, or using the technique described in the MPEGFAQ which by our team about 4 years ago, archived at www.mcli.dist.maricopa.edu/director).

If you need more control, then you should probably use an Xtra that wraps the MCI calls for you. There are a lot of advantages in doing so, even if you are a very good Lingo programmer. MpegXtra does exactly this. With the latest version you have the ability to create cuepoints, use the behaviors included to create slider bars, and most important, you can detect mouse and key events that occur over the MPEG video area reliably. You can also detect the end of playback reliably, even if your presentation is deployed to systems with different MCI drivers, which report slightly different durations for the same file. These are the things you can not do if you use the MCI-directly approach. Additionally, the Xtra also keeps track of the linked MPEG files for you, adjusting the presentation so that it will still work if you burn a CD and the user has it mounted in a strange drive letter. This saves you additional Lingo coding time and hassle. So for a project with moderate complexity, you should definitely consider using an Xtra: it will save you hours/days of work, and you can benefit from experiences shared by the developers that have been working with a bunch of MPEG MCI drivers using all versions of this software in the past 4 years, and ended up included as new features or workarounds for specific pitfalls built into the Xtra code.

There is another MCI-based Xtra to control MPEG: it's OnStage SE, from Visible Lights. They claim "Lingo emulation" of MpegXtra commands, but this is not accurate. This is in relation to MpegXtra 1 and 2, not MpegXtra 3. We don't feel comfortable talking about a competitor's product. Since both Xtras exist in trial form, the best thing to do is to get both, install them, and see which one fits your needs better. Visible Lights also offers a more expensive version of OnStage that includes the unique ability of bundling a MPEG player on your CD, paying a royalty fee per CD distributed. More information can be found at their site (www.visiblelights.com.) Now that Microsoft makes ActiveMovie/DirectShow freely redistributable this is no longer very cost-effective, but may be a good solution if you must target Windows 3.1 machines.p

Now for the bad part: even with a good Xtra or a solid MCI code, the presentation WILL break on some machines, if the MCI driver is not configured correctly. This is very common, unfortunately. We estimate (based on past experiences) that almost 25% of developer's machines are not configured correctly. This percentage drops to about 15-20% if you consider end-user's machines, since they typically do not have the habit of installing/uninstalling software that messes with the MCI configuration, but it is still a high number. This is caused by the inherent flaws of the MCI registration process, maintained in Win.ini and system.ini files, which can be easily corrupted. And you should pay special attention if your presentation is targeting Windows NT: MCI configuration in NT is even more complex, and you actually have to modify the registry to fix it if things do not work right out of the box. Not a pleasant experience. Still, almost all hardware-based MPEG decoders can only be used via MCI. Popular MPEG2-DVD decoder boards like CreativeLabs PC-DVD, Sigma Designs Hollywood Plus and others only provide MCI drivers, so you have to use MCI techniques if you want to take advantage of these decoders. MCI will still be around for at least a couple of years, mainly for MPEG2 projects that require hardware acceleration, but if your project calls for MPEG1 media only, and you can define a minimum hardware requirement of a Pentium 133MHz CPU, you can bypass MCI flaws by using the techniques described below, which address the ActiveMovie/DirectShow engine directly.