A Realist's SMIL Manifesto
by Fabio Arciniegas A.
|
Pages: 1, 2
Establishing event duration
In our boxing example we used the dur attribute to specify the total duration of each clip. You can also specify the beginning and end of the clip using the begin and end attributes. With elements inside a sequence, the begin attribute specifies a time after the end of the previous element and the end attribute specifies a time after the clip started to play. Figure 4 and Listing 2 summarize the point.
 |
<smil> <head> <!-- Layout exactly as in Table 2 --> </head> <body> <seq> <img src="Intro-Names.gif" region="video" dur="2s"/> <img src="Intro-Date.gif" region="video" begin="1.0s" end="3.0s"/> </seq> </body> </smil> |
| Figure 4. Alternative Timeline | Listing 2. Implementing the alternative with begin and end. |
Transitions
SMIL 2.0 supports transitions like horizontal and vertical wipes. To preserve SMIL 1.0 compatibility, wipes must be incorporated in the video. Lack of transitions is an example of SMIL 1.0's over-simplification, a problem corrected technically in version 2.0, but with serious image consequences for SMIL in the mind of many creative professionals.
Concurrent Media
Apart from sequences, you can organize your media elements in two other blocks: par and switch. The following section deals with par blocks; switch will be explained when we localize and customize our presentation.
The par element is used to group together media elements that are played concurrently. For media elements inside a par, the begin attribute is relative to the beginning of the whole group. In the code below we synchronize the names of the fighters (appearing on the "title" region) with a voice-over explaining who is who. As you can see in Listing 3, seq and par blocks can be arbitrarily nested.
 |
<seq> <par> <audio src="jake.wav"/> <img src="title-jake.gif" region="title" dur="4s"/> </par> <par> <audio src="jake.wav"/> <img src="title-sugar.gif" region="title" dur="4s"/> </par> </seq> |
| Figure 5. Timeline for fighter names audio | Listing 3. Implementing the names in graphics and audio |
More About Regions
In the previous example we've been working with conveniently designed graphics that fit nicely into the regions of the layout. Clean fits are not always the case, so it is important to understand the different clipping options we can use on an area. When the size and shape of a visual element doesn't match that of an area, some kind of cropping or resizing mechanism intervene. The particular mechanism used depends on the fit attribute of the region. The options are better explained with some examples; Figure 6 shows how an image will look if we change the fit attribute in the target region.
 |
|
| Fit Value | Result |
| fill | Resize thee clip so that it fills the region exactly (even if distorted) |
| hidden | Keep the proportions of the clip and resize until the clip fits completely in the region |
| meet | Keep original size. Cut content outside the boundaries of the region |
| slice | Keep the proportions of the clip and resize until the clip fills completely the region. Cut content outside the boundaries |
Figure 6. Different Fits in the Same Region
Localizing and Customizing
SMIL provides a declarative syntax for limited localization based on the switch element. A switch element contains media or group elements, each with a test attribute(e.g. system-language). When the interpreter finds the switch element it begins trying, one by one, the test attributes of the enclosed elements; the first element to have a test attribute that matches the environment is chosen. Listing 4 illustrates the point, allowing Russian, Spanish, and English audio in our annotated video.
<par>
<switch>
<audio src="jake-ru.wav" system-language="ru"/>
<audio src="jake-fr.wav" system-language="fr"/>
<audio src="jake-en.wav"/>
</switch>
<img src="title-jake.gif" region="title" dur="4s"/>
</par>Listing 4. Localization of audio
Since the options are evaluated in the order they appear, it's a good practice to leave a sensible default, in this case the English clip, as the last entry, with no test attribute.
Another useful test attribute is system-bitrate, used to choose different content based on the available bandwith. Listing 5 shows the use of system-bitrate to customize the quality of our boxing video.
<switch>
<video src="LaMottaRobinson51-High.avi" region="video"
system-bitrate="150000" />
<video src="LaMottaRobinson51-Low.avi" region="video"/>
</switch>Listing 5. Choosing media for different bandwidths
The other test attributes are system-captions, system-overdub-or-caption, system-required, system-screen-size, and system-screen-depth (see details on the spec). However, only system-language and system-bitrate are reliably supported by the existing 1.0 players.
Since only a few test-attributes are provided and no client-side scripting can be used to change the DOM of the SMIL document in 1.0 players, all customizations based on other criteria must be implemented on the server side, forcing the need for server-side programming:
<video
src="cgi-bin/getVideoBasedOnUserAgeCookie.pl" region="video"/>
This is exactly what we can do in our example to bring random statistic
content into the video every time you watch
it. /cgi-bin/getRandomStatistic.pl returns either the fight record,
the history of fights between these two boxers, or the temperature conditions in
the arena. Since there is no test attribute to do random choices, we don't use
switch; rather, the url of the CGI is called:
<img
src="cgi-bin/getVideoBasedOnUserAgeCookie.pl" region="stats"
/>
Note that I've an image to display stats; text would be easier to produce. The reason is text formatting is not supported in SMIL 1.0, and all current players will either display it in a dull system font or force you into using a proprietary text markup format, like RealText. HTML is not supported in either RealPlayer or Quicktime or in any other SMIL 1.0 player. (GRiNS is a limited exception but there are no trial licenses available, and it probably isn't realistic to expect your users to buy GRiNS before downloading your media.) The lack of HTML support is one of the key reasons behind SMIL 1.0 failure as a mainstream technology.
Where Does This Work?
The annotation, localization, and customization possibilities of SMIL are interesting and make a great pitch for the technology in the abstract. But the fact is that SMIL 1.0 has had problems being accepted. The result must be stated clearly: the subset of SMIL which works on current players (that is SMIL 1.0 plus some proprietary extensions) is applicable mostly to static pieces of data in controlled environments, where the chosen player is known in advance and the code can be tuned to accomodate player idiosyncrasies.
But you cannot rely on the behavior of just one player if you plan to put SMIL content on the Web. And be prepared for significant differences between the way your content is presented, even if you don't use vendor extensions. In short, if you can't guarantee a particular SMIL 1.0 player is going to be used by your audience, the realistic advice is to not use SMIL. If you want to use SMIL, try to embed the player rather than merely referencing the file, which is about all you can do to make the file playable under a controlled environment.
Another main problem of SMIL 1.0 is the lack of support for HTML and the unexpected behavior when displaying transparent GIF89. The fact that text formatting is restricted to proprietary extensions limits the technology, especially for common uses like having a tool to replace Powerpoint presentations.
That being said, there are many environments where the player conditions are closed and the shortcomings are acceptable, making SMIL a reasonable alternative:
- Sequencing of advertisement and content inside a particular player. RealPlayer developers use SMIL for this purpose often.
- Simple prototyping and storyboarding of video content, by elongating the duration of still images. This is an inexpensive and often nice use of SMIL.
- Closed environments where the elements of content don't change much, but they need to be reorganized in many ways, easily and inexpensively. Think for example of a kiosk in a large museum with pictures of each room, providing directions to users. The pictures don't change at all but depending on where you are and where you want to go, the system must show you a different sequence of pictures. It is a lot cheaper to create and maintain simple text files with SMIL sequences than to edit each sequence as a long video in Premiere (or some other video tool)
Summary
This article catches up with three years of SMIL, studying the elements in version 1.0 of the language for solving a real and practical problem: inexpensive and flexible annotation of videos. It also examined the real state of SMIL and its mainstream players, as well as recommended how to deal with some problems, given the current support and the language shortcomings.
In the next article we will look ahead and see how the new modularization and content-related additions to the SMIL language make it an interesting new tool to improve narrative technology on the Web.
- Wow - now I know what is going on SMIL
2002-09-13 15:06:03 Mike Mega - Minor inconsistencies (but interesting reading)
2002-06-05 20:33:30 Robert Barta - Good stuff
2002-05-30 05:38:22 Rich Andrews - great article
2002-05-30 02:36:53 Luis Maya
