This section defines the SMIL media object module. This module contains elements and attributes used to describe media objects. Since these elements and attributes are defined in a module, designers of other markup languages can reuse the SMIL media module when they need to include media objects into their language.
Changes with respect to the media object elements in SMIL 1.0 provide additional functionality that was brought up as Requirements of the Working Group, and those differences are explained in Appendix A.
ref, animation, audio, img, video, textand
The media object elements allow the inclusion of media objects into a SMIL presentation. Media objects are included by reference (using a URI).
There are two types of media objects: media objects with an intrinsic duration (e.g. video, audio) (also called "continuous media"), and media objects without intrinsic duration (e.g. text, image) (also called "discrete media").
Anchors and links can be attached to visual media objects, i.e. media objects rendered on a visual abstract rendering surface.
When playing back a media object, the player must not derive the exact type of the media object from the name of the media object element. Instead, it must rely solely on other sources about the type, such as type information contained in the "type" attribute, or the type information communicated by a server or the operating system.
Authors, however, should make sure that the group into which of the media object falls (animation, audio, img, video, text or textstream) is reflected in the element name. This is in order to increase the readability of the SMIL document. When in doubt about the group of a media object, authors should use the generic "ref" element.
Languages implementing the SMIL Media Object Module must define which attributes may be attached to media object elements. In all languages implementing the SMIL Media Object Module, media object elements can have the following attributes:
A brief description of the content contained in the element.
For user agents that cannot display a particular media-object, this attribute specifies alternate text. It is strongly recommended that all media object elements have an "alt" attribute with a meaningful description. Authoring tools should ensure that no element can be introduced into a SMIL document without this attribute.
If the content of these attributes is read by a screen-reader, the presentation should be paused while the text is read out, and resumed afterwards.
The name of the author of the content contained in the element.
Defined in SMIL Timing Module
The clipBegin attribute specifies the beginning of a sub-clip of a continuous
media object as offset from the start of the media object.
Values in the clipBegin attribute have the following syntax:
Clip-value ::= [ Metric ] "=" ( Clock-val | Smpte-val ) | "marker" "=" name-val Metric ::= Smpte-type | "npt" Smpte-type ::= "smpte" | "smpte-30-drop" | "smpte-25" Smpte-val ::= Hours ":" Minutes ":" Seconds [ ":" Frames [ "." Subframes ]] Hours ::= Digit Digit /* see XML 1.0 for a definition of ´Digit´*/ Minutes ::= Digit Digit Seconds ::= Digit Digit Frames ::= Digit Digit Subframes ::= Digit Digit name-val ::= ([^<&"] | [^<&´])* /* Derived from BNF rule  in [XML10] Whether single or double quotes are allowed in a name value depends on which type of quotes is used to quote the clip attribute value */
The value of this attribute consists of a metric specifier, followed by a time value whose syntax and semantics depend on the metric specifier. The following formats are allowed:
The time value has the format hours:minutes:seconds:frames.subframes. If
the frame value is zero, it may be omitted. Subframes are measured in
one-hundredth of a frame.
Example: Assume that a recorded radio transmission consists of a sequence of songs, which are separated by announcements by a disk jockey. The audio format supports marked time points, and the begin of each song or announcement with number X is marked as songX or djX respectively. To extract the first song using the "marker" metric, the following audio media element can be used:
<audio clipBegin="marker=song1" clipEnd="marker=dj1" />
"clipBegin" may also be expressed as "clip-begin" for compatibility with SMIL 1.0. Software supporting the SMIL Boston Language Profile must be able to handle both "clipBegin" and "clip-begin", whereas software supporting only the SMIL media object module only needs to support "clipBegin". If an element contains both a "clipBegin" and a "clip-begin" attribute, then "clipBegin" takes precedence over "clip-begin". When used in conjunction with the timing attributes from the SMIL Timing Module, this attribute is applied before any SMIL Timing Module attributes.
<audio src="radio.wav" clip-begin="5s" clipBegin="10s" />
The clip begins at second 10 of the audio, and not at second 5, since the "clip-begin" attribute is ignored. A strict SMIL 1.0 implementation will start the clip at second 5 of the audio, since the clipBegin attribute will not be recognized by that implementation. See Changes to SMIL 1.0 Media Object Attributes for more discussion on this topic.
The clipEnd attribute specifies the end of a sub-clip of a continuous media
object (such as audio, video or another presentation) that should be played.
It uses the same attribute value syntax as the clipBegin attribute.
If the value of the "clipEnd" attribute exceeds the duration of the media object, the value is ignored, and the clip end is set equal to the effective end of the media object. "clipEnd" may also be expressed as "clip-end" for compatibility with SMIL 1.0. Software supporting the SMIL Boston Language Profile must be able to handle both "clipEnd" and "clip-end", whereas software supporting only the SMIL media object module only needs to support "clipEnd". If an element contains both a "clipEnd" and a "clip-end" attribute, then "clipEnd" takes precedence over "clip-end". When used in conjunction with the timing attributes from the SMIL Timing Module, this attribute is applied before any SMIL Timing Module attributes.
See Changes to SMIL 1.0 Media Object Attributes for more discussion on this topic.
The copyright notice of the content contained in the element.
This attribute specifies a link (URI) to a long description of a media object. This description should supplement the short description provided using the alt attribute. When the media object has associated hyperlinked content, this attribute should provide information about the hyperlinked content.
If the content of these attributes is read by a screen-reader, the presentation should be paused while the text is read out, and resumed afterwards.
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 attribute specifies the position of the current element in the order
alt text are read out by
a screen reader for the current document. This value must be a number between
0 and 32767. User agents should ignore leading zeros. The default value is
Elements that contain
are read by a screen reader according to the following rules:
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.
The value of the src attribute is the URI of the media object.
Strip the intrinsic repeat value of the underlying media object. For example,
many animated GIFs intrinsically repeat indefinitely. The stripRepeat attribute
allows an author to remove the intrinsic repeat behavior of an animated GIF
on a per-reference basis, causing the animation to display only once, regardless
of the repeat value embedded in the GIF. When stripRepeat is used in conjunction
with SMIL Timing Module attributes, this attribute is applied first, so that
the repeat behavior can then be controlled with the SMIL Timing Module attributes
repeatDur. Values: "true"
or "false". Default: "false".
This attribute offers advisory information about the element for which it is set. Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tool tip" (a short message that appears when the pointing device pauses over an object). It is strongly recommended that all media object elements have a "title" attribute with a meaningful description. Authoring tools should ensure that no element can be introduced into a SMIL document without this attribute.
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
Content type of the media object referenced by the "src" attribute. This
value takes precedence over other possible sources of the media type (for
instance, the "Content-type" field in an HTTP or RTSP exchange, or the file
extension). When the content represented by a URL is available in many data
formats, implementations MAY use the
type value to influence
which of the multiple formats is used. For instance, on a server implementing
HTTP content negotiation, the client may use the
to order the preferences in the negotiation.
(@@ need to think through if this is what we really want to say; current SMIL implementations probably do not implement this behavior, though it's hard to imagine current implementations rely on any other behavior.).
Used to identify the natural or formal language for the element. For a complete description, see section 2.12 Language Identification of [XML10].
xml:lang differs from the
attribute in one important respect.
xml:lang provides information
about the content's language independent of what implementations do with
the information, whereas
system-language is a test attribute
with specific associated behavior (see
SMIL Content Control Module for details)
Languages utilizing the SMIL Media Object Module must define the complete set of elements which may act as children of media object elements. In all languages implementing the SMIL Media Object Module, the following elements must be part of the supported set of child elements:
@@Links below incorrectly point to the HTML spec
(CDATA) This attribute defines the name of a run-time parameter, assumed to be known by the inserted object. Whether the property name is case-sensitive depends on the specific object implementation.
[cdata] This attribute specifies the value of a run-time parameter specified by name. Property values have no meaning to SMIL; their meaning is determined by the object in question.
[data|ref|objectThis attribute specifies the type of the value attribute. Possible values:
This attribute specifies the content type of the resource designated by the value attribute only in the case where valuetype is set to "ref". This attribute thus specifies for the user agent, the type of values that will be found at the URI designated by value. See 6.7 Content Type in [HTML40] for more information.
param elements specify a set of values that may be required by a media object at run-time. Any number of param elements may appear in the content of a media object element, in any order, but must be placed at the start of the content of the enclosing media object element.
The syntax of names and values is assumed to be understood by the object's implementation. This document does not specify how user agents should retrieve name/value pairs nor how they should interpret parameter names that appear twice.
<ref src="http://www.facethingy.com/herbert.face"> <param name="mood" value="surly" valuetype="data"> <param name="accessories" value="baseball-cap,nose-ring" valuetype="data"> </ref>
<ref classid="http://www.gifstuff.com/gifapplication"> <param name="Init_values" value="./images/elvis.gif"> valuetype="ref"> </ref>
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.
"rtpmap" is an empty element
<audio src="rtsp://www.w3.org/foo.rtp" 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" /> </audio>
A media object referenced by a media object element is often rendered by software modules referred to as media players that are separate from the software module providing the synchronization between different media objects in a presentation (referred to as synchronization engine).
Media players generally support varying levels of control, depending on the constraints of the underlying renderer as well as media delivery, streaming etc. This specification defines 4 levels of support, allowing for increasingly tight integration, and broader functionality. The details of the interface will be presented in a separate document.
With regards to the clipBegin/clip-begin and clipEnd/clip-end elements, SMIL Boston defines the following changes to the syntax defined in SMIL 1.0:
Using attribute names with hyphens such as "clip-begin" and "clip-end" is problematic when using a scripting language and the DOM to manipulate these attributes. Therefore, this specification adds the attribute names "clipBegin" and "clipEnd" as an equivalent alternative to the SMIL 1.0 "clip-begin" and "clip-end" attributes. The attribute names with hyphens are deprecated.
Authors can use two approaches for writing SMIL Boston presentations that use the new clipping syntax and functionality ("marker", default metric) defined in this specification, but can still can be handled by SMIL 1.0 software. First, authors can use non-hyphenated versions of the new attributes that use the new functionality, and add SMIL 1.0 conformant clipping attributes later in the text.
<audio src="radio.wav" clipBegin="marker=song1" clipEnd="marker=moderator1" clip-begin="0s" clip-end="3:50" />
SMIL 1.0 players implementing the recommended extensibility rules of SMIL 1.0 [SMIL10] will ignore the clip attributes using the new functionality, since they are not part of SMIL 1.0. SMIL Boston players, in contrast, will ignore the clip attributes using SMIL 1.0 syntax, since they occur later in the text.
The second approach is to use the following steps:
<switch> <audio src="radio.wav" clipBegin="marker=song1" clipEnd="marker=moderator1" system-required= "@@http://www.w3.org/AudioVideo/Group/Media/extended-media-object19990707" /> <audio src="radio.wav" clip-begin="0s" clip-end="3:50" /> </switch>
Added the recommendation that if the content of these attributes is read by a screen-reader, the presentation should be paused while the text is read out, and resumed afterwards.
New Accessibility Attributes
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:
The following attributes were added to SMIL Boston:
<audio src="rtsp://www.w3.org/test.rtp" port="49170-49171" transport="RTP/AVP" rtpformat="96,97,98" />
In addition to these new attributes, the "rtpmap" element was added to complete the SDP functionality.
stripRepeat attribute was added to provide better timing
control over media with intrinsic repeat behavior (such as animated GIFs).
SMIL 1.0 only allowed "anchor" as a child element of a media element. In
addition to "anchor" (now defined in the Linking module), the
rtpmap elements are now allowed as children
of a SMIL media object. Other new children may also be defined by the host
A new section describing the "param" element provides a generalized mechanism to attach media-specific attributes to media objects.
A new section describing the "rtpmap" element provides functionality needed to use SMIL as a replacement for SDP.
SMIL Boston introduces the concepts of levels of functionality, which are explained in this section.
Listed below are the features that haven't been integrated yet, and may not make it into the final version of SMIL Boston: