SMIL 1.0, the first specification of the Synchronized Multimedia Integration Language, was offered as a recommendation by the W3C in 1998 and is a model of simplicity. With only a few SMIL tags under your belt, you can easily create most SMIL presentations.
As stated in the specification, the goals of SMIL 1.0 were basic:
To describe the temporal (time) behavior of the presentation
To describe the layout of the presentation on the screen
To associate hyperlinks with media objects
The resulting language is probably best summed up as HTML for multimedia. With SMIL 1.0, you have a text-based language that is built for multimedia on the Web. What really makes it powerful is that right out of the box, it comes ready to handle time. After years of using CD-ROM multimedia presentation approaches that had been roughly patched up for Web use, SMIL 1.0 showed a new direction.
SMIL 1.0 controls the timing of media with two basic elements: <seq> for the sequential synchronization of media objects and <par> for the parallel synchronization of media objects.
<seq> (for sequential) is used to play one piece of media right after another. With it, you can tell your SMIL player that you want your first media clip to be followed by a second.
<par> (for parallel) ensures that two independent pieces of media play at the same time. For example, using the <par> element, you can instruct a music clip to play in synchronization with a set of images.
Of course, you can combine these two basic building blocks in almost any fashion. For example, by nesting two <par> elements inside a <seq> element, one grouping of media clips running at the same time will be followed by a second block of assorted media objects also running in parallel. See Figure 3.1 for an illustration.
The capability to give the viewer a cohesive presentation from assorted media objects is incredibly important when evaluating SMIL as a potential Web multimedia approach. With other Web multimedia environments, the presentation of media is authored and output as a fixed work. If you want to provide other playback options using those same media objects, you need to recombine and output your content to match your intent. An example of a fixed Web multimedia would be a QuickTime movie that includes an interactive Flash layer. Once the final movie file is created, the interactivity is fixed. Rearranging the media objects and changing the interactivity requires re-authoring the file.
Figure 3.1 In this example, each block of media clips will play in parallel, but the first block (clips 1-3) will play before the second (clips a-c).
With SMIL, all the media objects maintain their status as independent media objects that can be pulled together as needed. For example, if you desire a different look for your presentation, a simple rearrangement of the <par> and <seq> elements in the SMIL document can easily achieve this effect. So either by your hand or automatically by a program running on a server, the presentation's organization and use of available media objects can be changed instantly to suit your intent, the viewer's hardware and software parameters, or the viewer's interests.
Timing and synchronization of media objects is very important, but that is only half the problem. HTML authors have long struggled with how to get Web pages to look the way they want them to. Thankfully, SMIL comes with built-in layout control.
The <layout> element determines how objects are displayed in the presentation space. Within the <layout> element, playback areas can be specified using the <region> tag. For example, suppose that you want to display video at the top of the presentation window accompanied by descriptive text at the bottom as in Figure 3.2. The SMIL <layout> element can be employed to create two regions: one for the playback of the video segment and another to display the text.
Figure 3.2 Defining playback areas using <layout> and <region>.
The <layout> element adds to the object-oriented power of the SMIL timing and synchronization elements. To reach our goal in the preceding example (video accompanied by text) using other multimedia authoring tools, it would be necessary to "burn" the descriptive caption text into the video and output it as such. If you wanted to change that text, you would have to go back to the original source files and create a new version of your video. With SMIL, the descriptive text can be kept as a separate media object and positioned in a <region> below the video with <layout>. Now, changing the captioning requires modifying only your text.
Of course, multimedia on the Web is pretty limited if it stays only within the confines of one start-to-finish presentation. As a delivery mechanism, CD-ROM is currently still more effective at delivering multimedia efficiently. A Web multimedia language needs to offer a functionality that cannot be contained on a single CD-ROM: hyperlinking to other materials and presentations.
SMIL 1.0 did not disappoint. Like HTML, SMIL offers the capability to link through an anchor element to another Web element. Notice the term "Web element" instead of "media element." With a Web-based presentation, a SMIL object can link to another media object, but it can just as easily link to a Web page.
SMIL 1.0 also offers internal anchors. In this fashion, a link can jump within a SMIL document much like an internal reference in a long HTML page might move you down to a specific chapter.
Anyone for a <switch>?
Serving Web multimedia to an audience that might come to your presentation from a variety of places with a variety of equipment has the potential for creating authoring headaches. HTML authors have long faced this challenge and have used client-side scripting and server-side detection to offer up content that best matches the individual situations of their site visitors.
To help solve this problem for the multimedia author, SMIL offers the <switch> element. Do you have a visitor who speaks French? Give them a French version of your presentation with <switch>. Is the visitor using a slow modem or speeding along with a broadband connection? Determine the data rate and <switch> to the proper media files to match. Now site visitors can receive content tailored to their personal situations.
The <switch> element is indispensable in allowing the author freedom to work directly within the parameters of a specific audience member.
Limitations of SMIL 1.0
The SMIL 1.0 specification was a good starting point for a fledgling Web multimedia language. It is simple enough to learn quickly and generic enough that it can be adapted to almost any Web multimedia player. But, like any first effort, limitations existed.
RealNetworks enthusiastically jumped out front as the first major player to adopt SMIL. To get the most out of its G2 player, however, RealNetworks created two SMIL-based proprietary languages that met the need for low-bandwidth display of streaming text and images. RealText and RealPix provide text effects and transitions not available when using standard SMIL 1.0.
Whereas RealNetworks was a solid advocate for the first SMIL specification, Microsoft responded with criticism. Pulling out of the SMIL effort before the SMIL 1.0 recommendation was made by the W3C, Microsoft later offered a proposal to incorporate SMIL in with standard HTML.
These new interests would require a more powerful and complex language. SMIL 1.0 needed an update.