previous   next   contents  

8. The SMIL Streaming Media Object Module

Philipp Hoschka (, W3C
Rob Lanphier (, RealNetworks

Table of contents

8.1 Introduction

This section defines the SMIL Streaming Media Object module. This module extends the SMIL Media Object Module by adding elements and attributes that make it possible to describe transport properties of streaming media. Implementations of this module depends on proper implementation of the SMIL Media Object Module Level 0.

When using SMIL in conjunction with the Real Time Transport Protocol (RTP, [RFC1889]), which is designed for real-time delivery of media streams, a media client is required to have initialization parameters in order to interpret the RTP data. In the typical RTP implementation, these initialization parameters are described in the Session Description Protocol (SDP, [RFC2327]). The SDP description can be delivered in the DESCRIBE portion of the Real Time Streaming Protocol (RTSP, [RFC2326]), or can be delivered as a file via HTTP.

Since SMIL provides a media description language which often references SDP via RTSP and can also reference SDP files via HTTP, a very useful optimization can be realized by merging parameters typically delivered via SDP into the SMIL document. Since retrieving a SMIL document constitutes one round trip, and retrieving the SDP descriptions referenced in the SMIL document constitutes another round trip, merging the media description into the SMIL document itself can save a round trip in a typical media exchange. This round-trip savings can result in a noticeably faster start-up over a slow network link.

This applies particularly well to two primary usage scenarios:

8.1.1 Element Attributes

The SMIL Streaming Media Object Module defines the following attributes for media objects:


This provides the RTP/RTCP port for a media object transferred via multicast. It is specified as a range, e.g., port="3456-3457" (this is different from "port" in SDP, where the second port is derived by an algorithm). Note: For transports based on UDP in IPv4, the value should be in the range 1024 to 65535 inclusive. For RTP compliance it should start with an even number. For applications where hierarchically encoded streams are being sent to a unicast address, this may be necessary to specify multiple port pairs. Thus, the range of this request may contain greater than two ports. This attribute is only interpreted if the media object is transferred via RTP and without using RTSP.


This field has the same semantics as the "fmt list" sub-field in an SDP media description. It contains a list of media format payload IDs. For audio and video, these will normally be a media payload type as defined in the RTP Audio/Video Profile (RFC 1890). When a list of payload formats is given, this implies that all of these formats may be used in the session, but the first of these formats is the default format for the session. For media payload types not explicitly defined as static types, the rtpmap element may be used to provide a dynamic binding of media encoding to RTP payload type. The encoding names in the RTP AV Profile do not specify a complete set of parameters for decoding the audio encodings (in terms of clock rate and number of audio channels), and so they are not used directly in this field. Instead, the payload type number should be used to specify the format for static payload types and the payload type number along with additional encoding information should be used for dynamically allocated payload types. This attribute is only interpreted if the media object is transferred via RTP.


This attribute has the same syntax and semantics as the "transport" sub-field in a SDP media description. It defines the transport protocol that is used to deliver the media streams. Currently defined values for this are: "src-attr" and "RTP/AVP", but alternate values may be defined by IANA. The default value for this is "src-attr", which indicates that the transport is derived from the URL given in the src attribute. The other defined value for this field is "RTP/AVP". RTP/AVP is the IETF's Realtime Transport Protocol using the Audio/Video profile carried over UDP. The complete definition of RTP/AVP can be found in [RFC1890].

@@ this may be better to derive from the "src" parameter, which could optionally be rtp://___. This would mean that an RTP URL format  would need to be defined.

@@ what does it mean when an HTTP URL is coupled with transport="RTP/AVP"? Example

<audio src="rtsp://" port="49170-49171"
       transport="RTP/AVP" rtpformat="96,97,98" />

8.1.2 Element Content

The SMIL Streaming Media Object Module adds the rtpmap elements which may act as children of media object elements:

8.1.3 The rtpmap element

If the media object is transferred using the RTP protocol, and uses a dynamic payload type, SDP requires the use of the "rtpmap" attribute field. In this specification, this is mapped onto the "rtpmap" element, which is contained in the content of the media object element. If the media object is not transferred using RTP, this element is ignored.



The value of this attribute is a payload format type number listed in the parent element's "rtpformat" attribute. This is used to map dynamic payload types onto definitions of specific encoding types and necessary parameters.


This attribute encodes parameters needed to decode the dynamic payload type. The attribute values have the following syntax:

encoding-val    ::= ( short-encoding | long-encoding )
short-encoding  ::= encoding-name "/" clock-rate 
long-encoding   ::= encoding-name "/" clock-rate "/" encoding-params
encoding-name   ::= name-val
clock-rate      ::= +Digit
encoding-params ::= ??

Legal values for "encoding-name" are payload names defined in [RFC1890], and RTP payload names registered as MIME types [draft-ietf-avt-rtp-mime-00].

For audio streams, "encoding parameters" may specify the number of audio channels. This parameter may be omitted if the number of channels is one provided no additional parameters are needed. For video streams, no encoding parameters are currently specified. Additional parameters may be defined in the future, but codec specific parameters should not be added, but defined as separate rtpmap attributes.

Element Content

"rtpmap" is an empty element


<audio src="rtsp://" port="49170" 
       transport="RTP/AVP" rtpformat="96,97,98">
  <rtpmap payload="96" encoding="L8/8000" />
  <rtpmap payload="97" encoding="L16/8000" />
  <rtpmap payload="98" encoding="L16/11025/2" />

8.2 SMIL Streaming Media Object Document Type Definition (DTD)

<!-- ======================================================================= -->
<!-- SMIL Streaming Media Objects Module  ================================== -->
<!-- file: SMIL-streamingmedia.mod

     This is Smil-Boston.
     Copyright 2000 W3C (MIT, INRIA, Keio), All Rights Reserved.

     Author:     Rob Lanphier
     Revision:   $Id: streaming-media-object.html,v 1.3 2000/06/22 17:42:00 hugo Exp $

     This DTD module is identified by the PUBLIC and SYSTEM identifiers:

     PUBLIC "-//W3C//ELEMENTS SMIL-Boston Streaming Media Objects//EN"
     SYSTEM "SMIL-streamingmedia.mod"

     ======================================================================= -->

<!-- ================== Profiling Entities ================================= -->
<!ENTITY % rtpmap.content "EMPTY">
<!ENTITY % rtpmap.attrib  "">

<!-- ================== Media Objects Entities ============================= -->

<!ENTITY % rtpmap-attributes "
  payload        CDATA   #IMPLIED
  encoding       CDATA   #IMPLIED

     Most info is in the attributes, media objects are empty or
     has children defined at the language integration level:

<!-- ================== Streaming Media Objects Elements ========= -->
<!ELEMENT rtpmap           %rtpmap.content;>
<!ATTLIST rtpmap           %rtpmap.attrib;

<!-- end of SMIL-media.mod -->

previous   next   contents