A rchive Date
[ 14-04-2001 ]
Category
[ Information Technologies ]
sub-Categoy
[ Computers ]

A Reason to SMIL Part 2: Coding in SMIL

Introduction to SMIL: how to assemble your first SMIL document.

By Jackson West, courtesy of CNET Builder

We hope that this project has motivated you to imagine what you could do using SMIL and dynamic server applications. While the example is fairly rudimentary and admittedly a little trite, it demonstrates a functional dynamic multimedia environment. We at Builder.com don't claim responsibility for your business plan or artistic inspiration; we just deliver the knowledge necessary to realize them. Some points to consider: Create longer-format pieces: SMIL is ideally suited to linking together sequences of large and small video clips and other media.

An ideal situation is an ad banner image with an audio track, followed by a single video piece, and then segued with another short clip, and so on - making it easier to lace your streaming video with commercial content that can generate click-throughs. Use the a tag: SMIL also supports use of the a tag to hyperlink media to other SMIL documents, anchors within those documents, or other sites on the Web. And because a Uniform Resource Indicator is always used, you might generate another Perl script that records a user's movement through a series of different paths using CGI. At the time this article was written, we found the QuickTime Player's implementation of this functionality problematic and decided not to address it.

If you must add

hyperlinks

in your QuickTime Player-formatted SMIL documents, we recommend adding it to the video content via QScript, or creating a simple Flash overlay with an ActionScript GetURL call. Leave the http protocol behind: SMIL is actually best suited for the rtsp protocol for streaming media, whether formatted with QuickTime or Real. Using a packet-streaming server such as RealServer or Darwin lets you ensure reliable, high-quality content delivery. Use a permission-based system: While SMIL's switch element is supposed to take the sting out of alternate language and bit rate content choices, its implementation is far from universal. But since we are generating documents on the fly here, from user input no less, there is no reason that we can't use a permission-based system - just ask users what language they speak, which player they're using, and what bit rate their connection supports, then amend the code and file references accordingly.

This is generally a more reliable, user-friendly approach. Build with scalability: Everyone wants to know how scalable a technology is these days, and they should, because if they want to reach a broad market they'll have to support a whole mess of computing power. This article employs Perl, but any back-end software that supports text-file generation should be suitable. You could also write a program similar to ours in C or C++ and run it precompiled for better server performance as well.

Now that our basic presentation structure is stored on the server in a number of independent variables, we can begin to assemble our SMIL document. You should keep two things in mind when creating a SMIL document since, as a subset of XML, it has a slightly different syntax than HTML. First, you must use lowercase for all tag and attribute names. Second, regions and elements without closing tags close themselves with space, backslash, and then close angle bracket (/>).

The SMIL Source

Let's take a look at an example generated from art_generator.pl and we'll explain what's going on line by line:

<smil xmlns:qt="

http://www.apple.com/quicktime

/resources/smilextensions" qt:autoplay="true">

This line declares the document type, as well as the XML Namespace that defines the proprietary QuickTime extensions, such as the final attribute, qt:autoplay, which takes a true or false value.

These three lines present the file structure (<head> and <layout>) and window properties for the QuickTime Player (<root layout />). Most importantly, QuickTime converts root-layout into a video track with the dimensions and color defined by width, height, and background-color. The video track functions as a background behind the other media elements. The layout element contains nested descriptions for all of the regions used in the presentation. We should assign new regions for each element we'll use to help QuickTime understand the exact layout of the generated creations.

Since audio requires no spatial dimension, we add attributes for the sake of clarity, so that our player doesn't make any assumptions about how to lay out the media that we're asking it to handle.

Each image will require its own region to allow repositioning during playback. The id attribute is critical for later assigning media to separate layers, and each value must be unique. The fit attribute specifies exactly how to scale and/or crop the image during playback. A complete description of the fit attribute is available in the

SMIL 1.0 Specification

Even though we'll be using only one clip, we can place each instance of it anew by using multiple regions. Notice that the z-index of the video clips is higher than that of the image regions. QuickTime has difficulty rendering alpha transparency over video clips, as it requires a huge demand on the processor. Hence, we use z-index to make sure that no video region lies underneath our transparent GIFs.

  </layout>
  /head>
  <body>
    <seq begin="0s">
    <par begin="15s">

Here we've closed the layout and head elements and opened the body of the presentation. The seq tag specifies a sequential temporal layout (A then B then C, and so on), the par tag specifies parallel temporal layout (while A, play B and C). These two tags pad the document by 15 seconds, which just happens to be QuickTime's default preload interval.

While in our par tags, we lay out our images, assigning them to regions, declaring their MIME type, using the QuickTime extension qt:composite-mode to declare transparency rendering, as well as the in point and duration of each image in seconds.

Now we do the same for each instance of our video clip.

And now we've looped our audio clip.

  </par>
    </seq>
  </body>
</smil>

Here we close all of our tags, and we're done!

Let's take a short look at our Perl source again and see how we generated some of the tags. Here we'll open our file, write the first lines, and determine the root layout from our generated values:

$random_presentation = '>../' . $piece_id . '.smi';

open (SMIL, $random_presentation) or
die 'Could not open smil document';

print SMIL <<END;

<smil xmlns:qt="

http://www.apple.com/quicktime/

  resources/smilextensions"
qt:autoplay="true">n
t<head>n
tt<layout>n
ttt<root-layout width="$aspect{'width'}"
  height="$aspect{'height'}"
background-color="$tone" />n
ttt<region id="audio" height="0"
  width="0" top="0" left="0"
z-index="0" />

END

First, we assign a handle to random_presentation that declares write mode, relative path, and filename. We then open the document (or if that's not possible, quit the program - a common debugging device), giving it the handle SMIL. Next we begin printing to SMIL until we reach the string END. The first line is our file type declaration, followed by the head element, the layout, and finally our root layout and audio region. Notice the use of the variables aspect and tone to declare the size and background color of the presentation.

The rest of the presentation is generated from while loops that write new regions and elements for every temporal interval, until the duration is met or exceeded. Each region is assigned an id attribute from the loop index, guaranteeing that each element will have a corresponding region to assign it. The audio loops within a single region, and the video clip is repeated and repositioned.

If you don't specify an explicit duration or end for the QuickTime Video elements, QuickTime will loop them to fill time. As new regions are declared, another looped video will begin while the other continues to play. Eventually the overlap will cause the player (and the client's computer) to become unstable due to memory and CPU demand. Be sure to close your video clips in time!

The last portion of art_generator.pl pushes the HTML necessary to render our presentation in the user's browser. Rendering in a browser is actually a very simple process in Perl.

We begin by creating the string we'll use as the embed tag: See

Listing A

Now we start pushing the HTML code to the client, starting with a Content-Type declaration to make sure that the client's browser knows what it's getting:

Listing B

We have to send our embed tag string, of course:

print $embed_tag;

Finally, as we close out our document, a little personalization. We use a standard time and date function to get our month and year:

($second, $minute, $hour, $dayofmonth, $month, $year,
$weekday, $dayofyear, $IsDST) = localtime(time);
my $realmonth = $month + 1;
my $realyear = $year + 1900;

And under the presentation, add the user's last name, as well as the month and year (just like a real artist!):

print <<CLOSE;
    <br>
    <font style="geneva,univers,helvetica,arial" size="3">
   $user_input{'lastname'}, $realmonth/$realyear</font>
  </td>
  </tr>
</table>
</body>
</html>

CLOSE

And voilà! About now, the author should be sound asleep, satisfied that the script works, and users should be getting uniquely personalized content delivered to their browser.

Notice that in the embed tag, the type attribute is set to the MIME type video/quicktime, even though the document is really of type application/smil. By changing the MIME type, we are attempting to force the browser to choose the QuickTime player over other players that may also support SMIL documents. Unfortunately, many of these players also think that they support QuickTime media, and if your file associations are set wrong, you might just see the Windows Media Player or RealPlayer logo screens and nothing else. Loading failure is a troublesome issue that can best be avoided by warning or asking the user about player differences before they are presented with SMIL content.

Create longer-format pieces: SMIL is ideally suited to linking together sequences of large and small video clips and other media. An ideal situation is an ad banner image with an audio track, followed by a single video piece, and then segued with another short clip, and so on - making it easier to lace your streaming video with commercial content that can generate click-throughs.
Use the a tag: SMIL also supports use of the a tag to hyperlink media to other SMIL documents, anchors within those documents, or other sites on the Web. And because a Uniform Resource Indicator is always used, you might generate another Perl script that records a user's movement through a series of different paths using CGI. At the time this article was written, we found the QuickTime Player's implementation of this functionality problematic and decided not to address it. If you must add hyperlinks in your QuickTime Player-formatted SMIL documents, we recommend adding it to the video content via QScript, or creating a simple Flash overlay with an ActionScript GetURL call.
Leave the http protocol behind: SMIL is actually best suited for the rtsp protocol for streaming media, whether formatted with QuickTime or Real. Using a packet-streaming server such as RealServer or Darwin lets you ensure reliable, high-quality content delivery.
Use a permission-based system: While SMIL's switch element is supposed to take the sting out of alternate language and bit rate content choices, its implementation is far from universal. But since we are generating documents on the fly here, from user input no less, there is no reason that we can't use a permission-based system - just ask users what language they speak, which player they're using, and what bit rate their connection supports, then amend the code and file references accordingly. This is generally a more reliable, user-friendly approach.
Build with scalability: Everyone wants to know how scalable a technology is these days, and they should, because if they want to reach a broad market they'll have to support a whole mess of computing power. This article employs Perl, but any back-end software that supports text-file generation should be suitable. You could also write a program similar to ours in C or C++ and run it precompiled for better server performance as well.

Serving HTML and the Embed tag

my $embed_tag = '<embed height="' . $aspect{'height'} . '" width="' . $aspect{'width'} . '" src="../' . $piece_id . '.smi" pluginspage="

http://www.apple.com/quicktime/download

" type="video/quicktime" autoplay="true" controller="false">';

The resulting string, stored in the variable embed_tag, should look like this: <embed height="283" width="392" src="../6969697045.smi" pluginspage="

http://www.apple.com/quicktime/download

" type="video/quicktime" autoplay="true" controller="false">

Sending it all to the client

print <<END; Content-Type: text/htmlnn <html> <head> <title>Your Multimedia Masterpiece</title <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body bgcolor="#FFFFFF"> <table width="100%" height="99%" border="0" cellspacing="0" cellpadding="0"> <tr align="center" valign="middle"> <td> <font style="geneva,univers,helvetica,arial" size="3"> <a href="

http://www.apple.com/quicktime/download/

">Requires QuickTime 4.1</a> </font> <br> <br> END

Let's take a short look at our Perl source again and see how we generated some of the tags. Here we'll open our file, write the first lines, and determine the root layout from our generated values: $random_presentation = '>../' . $piece_id . '.smi'; open (SMIL, $random_presentation) or die 'Could not open smil document'; print SMIL <<END; <smil xmlns:qt="

http://www.apple.com/quicktime/

resources/smilextensions" qt:autoplay="true">n t<head>n tt<layout>n ttt<root-layout width="$aspect{'width'}" height="$aspect{'height'}" background-color="$tone" />n ttt<region id="audio" height="0" width="0" top="0" left="0" z-index="0" /> END

The Source

Leave the http protocol behind: SMIL is actually best suited for the rtsp protocol for streaming media, whether formatted with QuickTime or Real. Using a packet-streaming server such as RealServer or Darwin lets you ensure reliable, high-quality content delivery. Use a permission-based system: While SMIL's switch element is supposed to take the sting out of alternate language and bit rate content choices, its implementation is far from universal.

But since we are generating documents on the fly here, from user input no less, there is no reason that we can't use a permission-based system - just ask users what language they speak, which player they're using, and what bit rate their connection supports, then amend the code and file references accordingly. This is generally a more reliable, user-friendly approach. Build with scalability: Everyone wants to know how scalable a technology is these days, and they should, because if they want to reach a broad market they'll have to support a whole mess of computing power. This article employs Perl, but any back-end software that supports text-file generation should be suitable. You could also write a program similar to ours in C or C++ and run it precompiled for better server performance as well.

]

Cross-Indexed:

Sharing Cable Modems

Some pages may require Adobe Acrobat Reader^™