西安邮电学院
软件开发论文
基于RealSystem的远程教学系统
Remote Teaching System Based On RealSystem
基础知识及协议部分
系别：计算机系
专业：计算机电子信息科学与技术
班级：电科0101
开发者姓名： 徐兆元
指导教师：
起止时间：2003年10月至XX月
目录
一.流媒体基础知识
1.1 什么是流媒
1.2 流的传输基础
二.RTSP,PNA协议分析
2.1实时流协议RTSP
2.2实时传输协议RTP
2.3 实时传输控制协议RTCP协议
2.4资源预留协议RSVP
三.SMIL语言
3．1.SMIL语言简介
3.2 详细内容
3．3 SMIL前景展望
一． 流媒体知识
1．1什么是流媒体
随着现代网络技术的发展，作为第四媒体的网络开始带给人们的是更多形式的信息模式。从在网络上出现第一张图片，到现在各种形式的网络视频，三维动画，人们的视听觉感官在网络上得到了很大的满足。而同时面临的是另外一种不可避免的尴尬：正是由于人们需求的不断提高，上网人数的不断增加，加之网络硬件设备的局限性，使得文件的大小成为网络传输一个不可忽视的参数。一方面，人们希望能在网络上看到生动清晰的媒体演示，另一方面人们又不得不去面对如此慢的网络速度下文件传输所需的大量时间。为了解决这种矛盾，一种新的媒体技术应运而生，这就是“流媒体技术”。
不知道大家是从什么时候开始认识这样的技术，在我的印象里面，FLASH技术是最先带给我“流（STREAM）”这个概念的。包括后来的Shockwave for Authorware、Shockwave for Director等等。而最新的网络三维图象标准，同样采用的是流式的传播技术，例子就是最近被炒的很热，而且效果的确很好的Viewpoiint（Metastream）和Cult3D技术。当然象QTVR里面也用了流传输的概念，我们在这里就不多提了。
上面或许只能算些题外话，我们这次主要介绍的是把流媒体技术用于网络视频传输应用的系统，主要是Real System和Media Service，当然还有QuickTime。至于象CISCO IP/TV一类系统，由于使用范围不大，加之时间和场合所限，在此不做详细研究探讨。
无论是哪一种系统，他们的基本原理都是一样的：首先通过采用高效的压缩算法，在降低文件大小的同时伴随质量的损失，让原有的庞大的多媒体数据适合流式传输。然后通过架设流媒体服务器，修改MIME标识。通过各种实时协议传输流数据。
实时流传输协议包括：
实时传输协议RTP:RTP（Real-Time Transport Protocol）
实时传输控制协议RTCP:RTCP(Real-Time Transport Control Protocol)
实时流协议RTSP:RTSP(Real-Time Streaming Protocol)
RSVP协议:RSVP(Resource Reserve Protocol)
MMS协议： MMS Protocol (Microsoft Media Server protocol)
流媒体（Streaming Media）是现代网络传输的重要基础技术，它对远程教学系统的网上直播是至关重要。流媒体实际指的是一种新的媒体传送方式，而非一种新的媒体。
1．2流式的传输基础
在网络上传输音／视频等多媒体信息目前主要有下载和流式传输两种方案。A/V文件一般都较大，所以需要的存储容量也较大；同时由于网络带宽的限制，下载常常要花数分钟甚至数小时，所以这种处理方法延迟也很大。流式传输时，声音、影像或动画等时基媒体由音视频服务器向用户计算机的连续、实时传送，用户不必等到整个文件全部下载完毕，而只需经过几秒或十数秒的启动延时即可进行观看。当声音等时基媒体在客户机上播放时，文件的剩余部分将在后台从服务器内继续下载。流式不仅使启动延时成十倍、百倍地缩短，而且不需要太大的缓存容量。流式传输避免了用户必须等待整个文件全部从Internet上下载才能观看的缺点。
流媒体指在Internet/Intranet中使用流式传输技术的连续时基媒体，如：音频、视频或多媒体文件。流式媒体在播放前并不下载整个文件，只将开始部分内容存入内存，流式媒体的数据流随时传送随时播放，只是在开始时有一些延迟。流媒体实现的关键技术就是流式传输。
流式传输定义很广泛，现在主要指通过网络传送媒体（如视频、音频）的技术总称。其特定含义为通过Internet 将影视节目传送到PC机。实现流式传输有两种方法：实时流式传输（Realtime streaming）和顺序流式传输（progressive streaming）。一般说来，如视频为实时广播，或使用流式传输媒体服务器，或应用如RTSP的实时协议，即为实时流式传输。如使用HTTP服务器，文件即通过顺序流发送。采用那种传输方法依赖你的需求。当然，流式文件也支持在播放前完全下载到硬盘。
1．2．1 顺序流式传输(Progressive Streaming)
顺序流式传输是顺序下载，在下载文件的同时用户可观看再线媒体，在给定时刻，用户只能观看已下载的那部分，而不能跳到还未下载的前头部分，顺序流式传输不象实时流式传输在传输期间根据用户连接的速度做调整。由于标准的HTTP服务器可发送这种形式的文件，也不需要其他特殊协议，它经常被称作HTTP流式传输。顺序流式传输比较适合高质量的短片段，如片头、片尾和广告，由于该文件在播放前观看的部分是无损下载的，这种方法保证电影播放的最终质量。这意味着用户在观看前，必须经历延迟，对较慢的连接尤其如此。
对通过调制解调器发布短片段，顺序流式传输显得很实用，它允许用比调制解调器更高的数据速率创建视频片段。尽管有延迟，毕竟可让你发布较高质量的视频片段。
顺序流式文件是放在标准HTTP 或 FTP服务器上，易于管理，基本上与防火墙无关。顺序流式传输不适合长片段和有随机访问要求的视频，如：讲座、演说与演示。它也不支持现场广播，严格说来，它是一种点播技术。
1．2．2实时流式传输(Realtime Streaming)
实时流式传输指保证媒体信号带宽与网络连接配匹，使媒体可被实时观看到。实时流与HTTP流式传输不同，他需要专用的流媒体服务器与传输协议。
实时流式传输总是实时传送，特别适合现场事件，也支持随机访问，用户可快进或后退以观看前面或后面的内容。理论上，实时流一经播放就可不停止，但实际上，可能发生周期暂停。
实时流式传输必须配匹连接带宽，这意味着在以调制解调器速度连接时图象质量较差。而且，由于出错丢失的信息被忽略掉，网络拥挤或出现问题时，视频质量很差。如欲保证视频质量，顺序流式传输也许更好。实时流式传输需要特定服务器，如QuickTime Streaming Server、RealServer与Windows Media Server。这些服务器允许你对媒体发送进行更多级别的控制，因而系统设置、管理比标准HTTP服务器更复杂。实时流式传输还需要特殊网络协议，如：RTSP (Realtime Streaming Protocol)或MMS (Microsoft Media Server)。这些协议在有防火墙时有时会出现问题，导致用户不能看到一些地点的实时内容。
1．3 流媒体的播放方式
u 单播
单播是客户端与服务器之间的点到点连接。“点到点”指每个客户端都从服务器接收远程流。仅当客户端发出请求时，才发送单播流。在客户端与媒体服务器之间需要建立一个单独的数据通道，从一台服务器送出的每个数据包只能传送给一个客户机。每个用户必须分别对媒体服务器发送单独的查询,而媒体服务器必须向每个用户发送所申请的数据包拷贝。这种巨大冗余首先造成服务器沉重的负担，响应需要很长时间，甚至停止播放；管理人员也被迫购买硬件和带宽来保证一定的服务质量。
u 多播
多播是通过启用多播网络传递的内容流；网络中的所有客户端共享同一流。ＩＰ组播技术构建一种具有组播能力的网络，允许路由器一次将数据包复制到多个通道上。采用组播方式，单台服务器能够对几十万台客户机同时发送连续数据流而无延时。媒体服务器只需要发送一个信息包，而不是多个；所有发出请求的客户端共享同一信息包。信息可以发送到任意地址的客户机，减少网络上传输的信息包的总量。网络利用效率大大提高，成本大为下降。
u 点播
点播连接是客户端与服务器之间的主动的连接。在点播连接中，用户通过选择内容项目来初始化客户端连接。用户可以开始、停止、后退、快进或暂停流。点播连接提供了对流的最大控制，但这种方式由于每个客户端各自连接服务器，却会迅速用完网络带宽。
u 广播/组播
广播指的是用户被动接收流。在广播过程中，客户端接收流，但不能控制流。例如，用户不能暂停、快进或后退该流。广播方式中数据包的单独一个拷贝将发送给网络上的所有用户。使用单播发送时，需要将数据包复制多个拷贝，以多个点对点的方式分别发送到需要它的那些用户，而使用广播方式发送，数据包的单独一个拷贝将发送给网络上的所有用户，而不管用户是否需要，上述两种传输方式会非常浪费网络带宽。组播吸收了上述两种发送方式的长处，克服了上述两种发送方式的弱点，将数据包的单独一个拷贝发送给需要的那些客户。组播不会复制数据包的多个拷贝传输到网络上，也不会将数据包发送给不需要它的那些客户，保证了网络上多媒体应用占用网络的最小带宽。
二．协议分析
2．1 实时流协议RTSP
实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。
实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。
2.1.1 简介
2.1.1.1 目的
实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交叉是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可靠传输连接以发出RTSP 请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和操作上与HTTP/1.1类似，因此HTTP的扩展机制大都可加入RTSP。协议支持的操作如下：
从媒体服务器上检索媒体：
用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。
媒体服务器邀请进入会议：
媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
将媒体加到现成讲座中：
如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。
2.1.1.2 协议特点
RTSP 特性如下：
可扩展性：
新方法和参数很容易加入RTSP。
易解析：
RTSP可由标准 HTTP或MIME解吸器解析。
安全：
RTSP使用网页安全机制。
独立于传输：
RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。
多服务器支持：
每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在传输层执行。
记录设备控制：
协议可控制记录和回放设备。
流控与会议开始分离：
仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下， SIP或H.323
可用来邀请服务器入会。
适合专业应用：
通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑
演示描述中立：
协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包含一个RTSP URI。
代理与防火墙友好：
协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个"缺口"。
HTTP友好：
此处，RTSP明智的采用HTTP观念，使现在结构都可重用。结构包括Internet 内容选择平台（PICS）。由于在大多数情况下控制连续媒体需要服务器状态， RTSP不仅仅向HTTP 添加方法。
适当的服务器控制：
如用户启动一个流，他必须也可以停止一个流。
传输协调；
实际处理连续媒体流前，用户 可协调传输方法。
性能协调：
如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。
2.1.1.3扩展RTSP
由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。RTSP 可以如下三种方式扩展，这里以改变大小排序：
以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。
加入新方法。如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共响应头列出支持的方法。
定义新版本协议，允许改变所有部分。（除了协议版本号位置）
2.1.1.4操作模式
每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义。使用HTTP或其它途径用户可获得这个文件，它没有必要保存在媒体服务器上。
为了说明，假设演示描述描述了多个演示，其中每个演示维持了一个公共时间轴。为简化说明，且不失一般性，假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：
单播：
以用户选择的端口号将媒体发送到RTSP请求源。
组播，服务器选择地址：
媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。
组播，用户选择地址：
如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。
2.1.1.5 RTSP状态
RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的连接状态。RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：
SETUP：
让服务器给流分配资源，启动RTSP连接。
PLAY与RECORD：
启动SETUP 分配流的数据传输。
PAUSE：
临时停止流，而不释放服务器资源。
TEARDOWN：
释放流的资源，RTSP连接停止。
标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连
接产生连接标识。
2.1.1.6 与其他协议关系
RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP 服务器与用户不全依靠HTTP。
但是，RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作出响应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。
当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。RTSP假设存在演示描述格式可表示包含几个媒体流的演示的静态与临时属性。
2.1.2 协议参数
2.1.3 RTSP 信息
RTSP是基于文本的协议，采用ISO 10646 字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。如仔细研究，文本协议很容易以脚本语言（如：Tcl、Visual Basic与Perl）实现研究原型。
10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通过任何低层传输协议携带。
请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度有如下因素决定：
不管实体头段是否出现在信息中，不包括信息体的的响应信息总以头段后第一和空行结束。
如出现内容长度头段，其值以字节计，表示信息体长度。如未出现头段，其值为零。
服务器关闭连接。
注意：RTSP目前并不支持HTTP/1.1"块"传输编码，需要有内容长度头。假如返回适度演示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。
从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，而没有定义任何HTTP代码。
2.1.4 实体
如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体由实体头文件和试题体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。
实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽略，而让代理转发。
2.1.5 连接
RTSP请求可以几种不同方式传送：
1、持久传输连接，用于多个请求/响应传输。
2、每个请求/响应传输一个连接。
3、无连接模式。
传输连接类型由RTSP URI来定义。对 "rtsp" 方案，需要持续连接；而"rtspu"方案，调用RTSP 请求发送，而不用建立连接。
不象HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途径。
2.1.6 方法定义
方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。
某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和服务器操作复杂，并强加附加开销，除非有必要，应避免这样做。插入二进制数据仅在RTSP通过TCP传输时才可使用。流数据（如RTP包）用一个ASCII美圆符号封装，后跟一个一字节通道标识，其后是封装二进制数据的长度，两字节整数。流数据紧跟其后，没有CRLF，但包括高层协议头。每个$块包含一个高层协议数据单元。
当传输选择为RTP，RTCP信息也被服务器通过TCP连接插入。缺省情况下，RTCP包在比RTP通道高的第一个可用通道上发送。客户端可能在另一通道显式请求RTCP包，这可通过指定传输头插入参数中的两个通道来做到。当两个或更多流交叉时，为取得同步，需要RTCP。而且，这为当网络设置需要通过TCP控制连接透过RTP/RTCP提供了一条方便的途径，可能时，在UDP上进行传输。
2.1.7 流水线操作
支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出响应。如果请求不是发送给组播组，接收者就确认请求，如没有确认信息，发送者可在超过一个来回时间（RTT）后重发同一信息。
RTT在TCP中估计，初始值为500 ms。应用缓存最后所测量的RTT，作为将来连接的初始值。如使用一个可靠传输协议传输RTSP，请求不允许重发，RTSP应用反过来依赖低层传输提供可靠性。如两个低层可靠传输（如TCP 和RTSP）应用重发请求，有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收着者前不会发送应用层重传，接收者也不能充分利用应用层重传。如包损失由阻塞引起，不同层的重发将使阻塞进一步恶化。时标头用来避免重发模糊性问题，避免对圆锥算法的依赖。每个请求在CSeq头中携带一个系列号，每发送一个不同请求，它就加一。如由于没有确认而重发请求，请求必须携带初始系列号。
实现RTSP的系统必须支持通过TCP传输RTSP ，并支持UDP。对UDP和TCP，RTSP服务器的缺省端口都是554。许多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与RTP和RTCP包交叉。不象HTTP，RTSP信息必须包含一个内容长度头，无论信息何时包含负载。否则，RTSP包以空行结束，后跟最后一个信息头。
2.2实时传输协议RTP
2.1.1实时传输协议RTP
2.1.1.1RTP协议：
RTP（ Real-time Transport Protocol）协议最初是在70年代为了尝试传输声音文件，把包分成几部分用来传输语音，时间标志和队列号。经过一系列发展，RTP第一版本在1991年8月由美国的一个实验室发布了。到本世纪1996年形成了标准的的版本。很多著名的公司如Netscape ,就宣称“Netscape LiveMedia”是基于RTP协议的。. Microsoft 也宣称他们的“NetMeeting”也是支持RTP协议.
RTP被定义为传输音频、视频、模拟数据等实时数据的传输协议。最初设计是为了数据传输的多播，但是它也用于单播的。与传统的注重的高可靠的数据传输的运输层协议相比，它更加侧重的数据传输的实时性。此协议提供的服务包括时间载量标识、数据序列、时戳、传输控制等。RTP与辅助控制协议RTCP一起得到数据传输的一些相关的控制信息。
2.1.1.2 RTP协议是如何工作的：
在前面说明过，威胁多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。RTP协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据的流放。
在流的概念中”时间标签”是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是RTP本身并不负责同步，RTP只是传输层协议，为了简化了运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保证实时地传输数据，不支持资源预留，也不保证服务质量。RTP报文甚至不包括长度和报文边界的描述。同时RTP协议的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。
RTP协议和UDP二者共同完成运输层协议功能。UDP协议只是传输数据包，是不管数据包传输的时间顺序。RTP的协议数据单元是用UDP分组来承载的。在承载RTP数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而UDP的多路复用让RTP协议利用支持显式的多点投递，可以满足多媒体会话的需求。
RTP协议虽然是传输层协议但是它没有作为OSI体系结构中单独的一层来实现。RTP协议通常根据一个具体的应用来提供服务， RTP只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。目前，RTP的设计和研究主要是用来满足多用户的多媒体会议的需要，另外它也适用于连续数据的存储，交互式分布仿真和一些控制、测量的应用中。基于RTP的实验和商业产品也层出不穷。
2.3 实时传输控制协议RTCP协议
2.3.1. RTCP协议：
RTCP（Real-time Transpor、Control Protocol）是设计和RTP一起使用的进行流量控制和拥塞控制的服务控制协议。
2.3.2. RTCP协议如何工作：
当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。在RTP的会话之间周期的发放一些RTCP包以用来传监听服务质量和交换会话用户信息等功能。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。
RTCP协议处理机根据需要定义了五种类型的报文——
RR: receiver report
SR: sender report
SDES: source description items.
BYE: indicates end of participation.
APP: application specific functions
它们完成接收、分析、产生和发送控制报文的功能。
2.4资源预留协议RSVP
由于音频和视频数据流比传统数据对网络的延时更敏感，要在网络中传输高质量的音频、视频信息，除带宽要求之外，还需其他更多的条件。RSVP(ResourceReserveProtocol)是正在开发的Internet上的资源预订协议，使用RSVP预留一部分网络资源（即带宽），能在一定程度上为流媒体的传输提供QoS。在某些试验性的系统如网络视频会议工具vic中就集成了RSVP。
2.4.1 背景
资源预订协议（RSVP）是网络控制协议，它使Internet应用传输数据流时能够获得特殊服务质量（QoSs），RSVP是非路由协议；它同路由协议协同工作，建立与路由协议计算出路由等价的动态访问列表， RSVP属OSI 七层协议栈中传输层，开始是研究人员构造的，IETF正朝标准化方向努力，图3.4 说明了RSVP运行环境。
图3.4 RSVP中主机信息通过数据流发送给接收者示意图
2.4.2 RSVP数据流
在RSVP中，数据流是一系列信息，有着相同的源、目的（可有多个）和服务质量，QoS要求通过网络以流说明形式通讯。流说明是互连网主机用来请求特殊服务的数据结构，保证互连网处理主机传输。RSVP支持三种传输类型：最好性能（best-effort），速率敏感（rate-sensitive）与延迟敏感（delay-sensitive）。用来支持这些传输类型的数据流服务依赖QoS实施，以下部分陈述传输类型与相关服务。
最好性能传输为传统IP传输。应用包括文件传输（如邮件传输）、磁盘映像、交互登录和事务传输。支持最好性能传输的服务称为最好性能服务。速率敏感传输放弃及时性，而确保速率。例如：速率敏感传输请求100 kbps带宽，如在扩展期实际发送200 kbps，路由器可能延迟传输。速率敏感传输目的不在通过电路交换网络传输，但它通常与电路交换网络（ISDN）应用有联系，现在正运行在数据报网络（IP）上。这类应用如H.323视频会议，设计运行在ISDN （H.320）或ATM（H.310）上，但发现在Internet上也有应用。H.323编码是常数速率或准常数速率，它需要常数传输速率。RSVP服务支持速率敏感传输，称为位速率保证服务。延迟敏感传输要求传输及时，并因而改变其速率。例如：MPEG-II视频根据图象改变量大小平均流量为3 到7 Mbps，3 Mbps可能对应一堵上色的墙，而7 Mbps 可能是海洋的波浪。MPEG-II视频源发送关键和增量帧。典型的，每秒一个或两个关键帧，描述整个图象，而每秒13或28帧描述关键帧之间的变化，增量帧通常比关键帧小。因此，帧与帧之间速率变化较大。但由于单个帧要求在一帧时间内发送出去，或解码器速度跟不上，必须对增量帧传输进行特定优先级别协调。RSVP服务支持延迟敏感传输，被看作控制延迟服务（非实时服务）与预报服务（实时服务）。
2.4.3 RSVP 数据流处理
RSVP数据流基本特征是连接，数据包在其上流通。连接是具有相同单播或组播目的数据流，RSVP分别处理每个连接。RSVP支持单播和组播连接（这里连接是一些发送者与另一些接收者的会话），而流总是从发送者开始的。特定连接的数据包被导向同一个IP目的地址或公开的目的端口。IP目的地址可能是组播发送的组地址，也可能是单个接收者的单播地址。公开目的端口可用UDP/TCP目的端口段、另外传输协议等价段或某些应用特定信息定义。
RSVP数据发布是通过组播或单播实现的。组播传输将某个发送者的每个数据包拷贝转发给多个目的。单播传输特征是只有一个接收者。即使目的地址是单播，也可能有多个接收者，以公开端口区分。多个发送者也可能存在单播地址，在这种情况下，RSVP可建立多对一传输的资源预订。每个RSVP发送者和接收者对应唯一的Internet主机。然而，单个主机可包括多个发送者和接收者，以公开端口区分。
RSVP服务质量(QoS):
在RSVP中，服务质量（QoS）是流规范指定的属性，流规范用于决定参加实体（路由器、接收者和发送者）进行数据交换的方式。主机和路由器使用RSVP指定QoS；其中主机代表应用数据流使用RSVP从网络申请QoS级别，而路由器使用RSVP发送QoS请求给数据流路经的其它路由器。这样做，RSVP就可维持路由器和主机状态来提供所请求的服务。
RSVP连接启动:
为了初始化RSVP组播连接，接收者首先使用Internet组成员协议（IGMP）加入IP目的地址指定的组播组。对单播连接，单播路由就象IGMP结合协议无关组播（PIM）在组播时的作用。接收者加入组后，潜在的发送者就开始发送RSVP路径信息给IP目的地址。接收者应用收到路径信息，开始发送相应资源预订请求信息，使用RSVP指定欲点播的流描述。发送者应用接收到资源预订请求信息后，发送者开始发送数据包。
2.4.4 RSVP资源预订类型
资源预订类型指一套指定所支持参数的控制选项。RSVP支持两种主要资源预订：独占资源预订和共享资源预订。独占资源预订为每个连接中每个相关发送者安装一个流；而共享资源预订由互不相关的发送者使用。表3.10说明这两种资源预订协议的应用范围及所支持的范围与类型的组合情况。
2.4.5 RSVP软状态实现
对RSVP，软状态指可被某些RSVP信息更新的路由器和终端结点的状态。软状态特征允许RSVP网络支持动态组成员变化，并适应路由变化。一般说来，软状态由基于RSVP网络维护，使网络可在没有查询终端结点的情况下改变状态。对比电路交换结构，终端结点进行依次呼叫，如失败，进行依次新呼叫。
RSVP协议为创建和维护组播和单播混合发送路径的分布式资源预订状态提供了一个通用功能。为维护资源预订状态，RSVP跟踪路由器和主机结点的软状态。路径与资源预订请求信息创建并周期更新RSVP软状态。如在清除时间间隔到期前没有收到相应更新信息，就删除该状态，显式teardown 信息也可删除软状态。RSVP周期扫描欲建立的软状态，并转发路径与预订请求更新信息给下一跳。
当路由改变，下一个路径信息初始化新路由的路径状态，将来资源预订请求信息建立资源预订状态。现在未使用的网段状态标记为超时。（RSVP规范要求在拓扑改变后两秒通过网络初始化新资源预订）。当发生状态变化，RSVP无延迟的将变化从RSVP网络的一个终端传到另一个终端。如接收到的状态与存储状态不同，就更新存储状态。如结果改变了欲产生的更新信息，更新信息立即生成并转发出去。
2.4.6 RSVP 操作模型
在RSVP下，资源为简单数据流（单向数据流）预订起来。每个发送者逻辑上与接收者不同，但任何应用都可充当发送者和接收者，接收者负责请求资源预订。图3.5说明了其基本操作环境，紧接部分将提供特定事件序列的框架。
图3.5 RSVP 操作环境：为单向数据流预订资源
2.4.6.1基本RSVP协议操作
RSVP资源预订处理初始化开始于RSVP 后台服务查询本地路由协议以获得路由。主机发送IGMP消息加入组播组，而发送RSVP消息预订沿组路径的资源。每个能加入资源预订的路由器将收到的数据包传递给包分类器，然后将它们在包调度器中排队。RSVP包分类器决定每个包的路由和QoS类；RSVP调度器给每个接口所使用的特殊数据链路层媒介上传输分配资源。如数据链路层媒介有自身的QoS管理能力，包调度器负责协调数据链路层，获得RSVP所请求的QoS。调度器本身分配无源QoS媒介上包传输能力，如双铰线；也可分配其它系统资源，如CPU时间与缓存。QoS请求一般发源于接收者主机应用，而被传递到本地RSVP应用，如RSVP 后台服务。RSVP协议接着将对所有结点（路又器与主机）的请求沿逆向数据路径传到到数据源。在每个结点处，RSVP程序应用一个称为进入允许控制的本地决定程序决定是否能提供所请求的QoS。如进入允许控制成功，RSVP程序设置包分类和调度器的参数，以获得所申请的QoS。如进入允许控制在某结点处失败，RSVP程序给产生此请求的应用返回一个错误指示。
2.4.6.2 RSVP 隧道
在整个Internet上同时配置RSVP或任意其他协议都是不可能的。实际上，RSVP决不可能在每个地方都被配置。因此，RSVP必须提供正确协议操作，即使只有两个支持RSVP的路由器与一群不支持RSVP的路由器相连。一个中等规模不支持RSVP的网络不能执行资源预订，因而服务保证也就不能实现。然而，如该网络有充足额外容量，也可以提供可接受的实时服务。
为了支持RSVP网络连接通过不支持RSVP的网络，RSVP支持隧道技术。隧道技术要求RSVP和非RSVP路由器用本地路由表转发到目的地址的路径信息。当路径信息通过非RSVP 网络时，路径信息拷贝携带最后一个支持RSVP的路由器的IP地址。预订请求信息转发给下一个上游支持RSVP的路由器
2.4.7 加权平均排队方案
用技术来加强出现瓶颈处的有效资源预订（如Cisco的加权平均排队方案）有着正面影响。隧道技术仅在瓶颈出在非RSVP 域且不可避免时才有风险。图3.6表示基于RSVP网络间采用隧道技术的RSVP环境
图3.6 ：应用隧道技术的RSVP环境
2.4.8 RSVP 消息
RSVP支持四种基本消息类型：资源预订请求消息、路径消息、错误与确认消息和断开消息。
2.4.9 RSVP 包格式
表3.11说明了RSVP包格式，如下内容列出格式的头和对象段。
表3.11 RSVP包格式 RSVP消息头段（长度单位：位） 4 4 8 16 16 8 8 32 15 1 16 版本 标志 类型 校验和 长度 预订 发送TTL 消息ID 预订 MF 偏移量 RSVP对象段（长度单位：位） 16 8 8 可变 长度 分类号 C类型 对象内容
RSVP 消息头段
RSVP 消息头段组成：
版本号---4位，表示协议版本号（当前版本为1）。
标志---4位 ，当前没有定义标志段。
类型---8位， 有几种可能值，如表3.12所示。
表3.12：RSVP消息类型段取值 值 消息类型 1 路径 2 资源预订请求 3 路径错误 4 资源预订请求错误 5 路径断开 6 资源预订断开 7 资源预订请求确认校验和---16位，表示基于RSVP消息的内容上标准TCP/UDP校验和。
长度---16-位，表示RSVP包的字节长度，包括公共头和随后的可变长度对象。如设置了MF标志，或片段偏移为非零值，这就是较大消息当前片段长度。
发送TTL---8位，表示消息发送的IP生存期。
消息ID---32位，提供下一RSVP跳/前一RSVP跳消息中所有片段共享标签。
更多片段 (MF) 标志---一个字节的最低位，其它7位预订，除消息的最后一个片段外，都将设置MF。
片段偏移---24位，表示消息中片段的字节偏移量。
RSVP 对象段
RSVP 对象段组成如下：
长度---16-位，包含总对象长度，以字节计（必须是4的倍数，至少是4）。
分类号---表示对象类型，每个对象类型都有一个名称。RSVP程序必须可识别分类，类型在表3.13列出。如没有识别出对象分类号，分类号高位决定结点采用什么行动。
C-类型---C类型，在分类号中唯一。最大内容长度是65528个字节。分类号和C-类型段(与标志位一起) 可用作定义每个对象唯一位的16位数。
对象内容---长度、类型号和C类型段指定对象内容的形式。
2.4.10 RSVP小结
RSVP运行在传输层，在IP上层。与ICMP和IGMP相比，它是一个控制协议。RSVP的组成元素有发送者、接收者和主机或路由器。发送者负责让接收者知道数据将要发送，以及需要什么样的QoS；接收者负责发送一个通知到主机或路由器，这样他们就可以准备接收即将到来的数据；主机或路由器负责留出所有合适的资源。
RSVP协议的两个重要概念是流与预定。流是从发送者到一个或多个接收者的连接特征，通过IP包中"流标记"来认证。发送一个流前，发送者传输一个路径信息到目的接收方，这个信息包括源IP地址、目的IP地址和一个流规格。这个流规格是由流的速率和延迟组成的，这是流的QoS需要的。接收者实现预定后，基于接收者的模式能够实现一种分布式解决方案。
RSVP领域的发展是非常迅速的，但目前并没有在任何一种网络上得到证实，它的应用只是局限在测试的小Intranet网络上。因为RSVP的预定必须建立在完全流方式的基础上，其可扩展性问题倍受关注。RSVP还存在诸如当一个服务请求被申请控制否决时网络应该怎样通知用户以及用户怎样应答这样的通知等问题。
三. SMIL语言
3．1.SMIL语言简介
3．1．1概述
自从SMIL被制定出来后，在业内一直获得一片赞扬声中。但是对于为支持Web多媒体技术而诞生的这项技术，在没有客户端浏览器支持后到底还有多少生命力，实在是个问号。
SMIL是W3C根据一系列草案来制订的.W3C也希望它制定的一系列规范能够被遵守. Microsoft和Netscape也每次都发誓说，他们会是好孩子并且会遵循W3C的各种规范。 他们发誓说会有一个采用通用标准的Web平台，并且浏览器都会遵守这些标准。
但是事实上，现在不但没有形成统一的标准，Web的构建还变得越来越复杂。新版本浏览器不断地引入一些专用技术，而这些技术似乎专门用于分裂市场。Web创建者现在得花大约25%的时间处理浏览器的兼容问题，并且随着5.0版浏览器的推出，这一百分比还会升高。
感到恐怖的是Web创建者们正在与Web Standards Project和其他倡导机构进行斗争，但胜利还很渺茫。Microsoft和Netscape都有充分的理由继续分化其浏览器，却很少有兴趣关心可怜的Web创建者们的呼声。
两个浏览器制造者曾经都不表示支持SMIL (Synchronized Multimedia Integration Language)。而Microsoft走得更远，提出HTML+TIME (Timed Interactive Multimedia Extensions for HTML)，并否认它将与和已被批准的SMIL进行竞争。意图是显而易见的.
SMIL的最强力支持来自RealNetworks公司。它认为，SMIL从根本上增强了Web的体系结构，是业界广泛支持和合作的产物，并且SMIL能与现有的技术(包括DHTML)一起使用。RealNetworks相信微软会最终采纳SMIL中的时间同步功能。
目前，RealNetworks占据了Web流式媒体网页约85%的市场份额，并有2400万注册用户。其于7月13日发布的G2系统beta版完全基于SMIL，是第一个支持SMIL的商业流式媒体播放器。
现在，有这样的想法充满你的头脑了吗?一种规范的工作草稿，所有的主流浏览器都不支持。是的,事实上就是这样.
是否最终规范会得到广泛使用，或者甚至是否能发展为可以发布的规范，都是一种猜测。和SMIL草稿直接竞争的技术，如Shockwave、RealFlash和Active Movie Control的市场可能都比SMIL媒体对象来的大。
网景和微软好象都对SMIL保持一种观望的态度，每一方在宣布某种支持之前都在等着对方的声明。但是有一点我们是可以希望的,W3C在互联网社会中得到广泛的尊敬，它支持的多媒体规范希望能使网景和微软做出一些装模做样的笨拙的和不和谐的尝试.
这段开场只是希望学习SMIL的朋友不要太紧张，因为SMIL真的并不象你所认为的那么重要。关于它的前途问题实在还是不明朗。
3．1．2 SMIL的历史
一直都希望在多媒体应用有所表现的WWW,在面对HTML只能处理静态内容,带宽限制及信息的同步问题上早就感到厌烦了.他们一直希望能制定一个WEB结构标准能够解决这些问题,为了结构清晰,按时间的先后次序,我列出了一个SMIL大事记.
1. 1998年万维网联盟(W3C)正式推荐了同步多媒体综合语言SMIL(Synchronized Multimedia Integration Language).
2. 1999年8月3日,在第一个草案的基础上,W3C推出了SMILBoston版本.SMILBoston有了许多重要的扩展,包括可重复使用的模块、通用的动画设计、改良的交互功能以及电视综合功能.
3. 2000于美国当地时间8月9日,以W3C建议（W3CRecommendation）的形式,工作小组“W3C Synchronized Multimedia(SYM)”，发表了基于XML的因特网多媒体演示用语言“SMIL（Synchronized Multimedia Integration Language）2.0”。SMIL是能够使音频、视频以及文本等多媒体信息内容要素获得同步的描述语言。也是现今为止最新的版本.
参加SYMM的成员包括，Glocomm公司、美国IBM公司、美国英特尔、美国Macromedia、美国微软、美国网景（Netscape）/美国在线、芬兰的诺基亚、Oratrix公司、松下电器产业、荷兰飞利普、美国的RealNetworks、WGBH公司等企业；还包括CWI（CentreforMathematicsandComputerScience／荷兰）、INRIA（InstitutNationalDeRecherceenInformatiqueetenAutomatique／法国）、NIST（NationalInstituteofStandardsandTechnology／美国）等研究以及政府机构。
3.2 详细内容
3．2．1多媒体标记
虽然在网上播放视频产品是可能的，但还不可行。未压缩的视频每秒需要播放几乎4兆的信息，这种传输速率在局域网上都很难达到，就更不用说大型网络了。人们正试图在将来的芯片中实现有效的视频压缩，但是当它实现时，视频也只是网上一种非常浪费的媒体。不管是运用快速蒙太奇还是别的方法，被传输的文件仍然相当大。
为了使视频在网上可行，我们需要实现聪明的内容。EDL（Edit Decision List）和SMPTE(Society of Motion Picture and Television Engineers)等视频编辑们认为是理所当然的时间编码标准很难转换到网上。SMPTE时间编码是视频时间片的标准，把视频信号分成小时、分、秒和祯（在视频中每秒30祯，在电影中每秒24祯）。
一旦SMPTE成为一种可采用的标准，就有可能描述基于时间片的一段视频。例如，第一个编辑发生在20秒和22祯处，持续2秒和4祯，然后切换到持续1秒和15祯，等等。很快，很多编辑台提供了可以记住某个给定片断的EDL，可以把EDL存储为只有几KB的计算机文件。这样，如果主卷丢失或被破坏，或者增加新的胶片，可以简单地用EDL来重建脚本。
这就是SMIL的基本原理。
直到现在，描述网上临时数据的明确定义的方式还没有真正出现。
公平地说，确实有一些面向网页的技术。其中的大多数，如Macromedia的Shockwave或RealNetwork的RealMedai，需要插件、ActiveX控件甚至单独的应用程序首先被下载下来，然后使用百分之百所有权的文件格式。而且，这些技术产生的文件对搜索引擎没有意义。
基于Web的多媒体缺乏标准部分是由于今天的混乱，但是同时也是可以原谅的。带宽依然是个问题，假设大多数人用28.8kbps的速率上网，1M的信息要花几分钟来下载，对音频和视频，1M的信息根本算不了什么。所以除非你知道你的大多数观众有一个快速连接，使用基于Web的多媒体是没有意义的。
好象我们可以在18个月内可以看到一些带宽的戏剧性的增长，或者象xDSL和电缆modem等技术的发展超过测试阶段。最重要的事实是通常很保守的W3C已经发布了一种试图处理多媒体的标记语言的工作草案：SMIL。
3.2.2 进入SMIL
SMIL，同步多媒体集成语言（Synchronized Multimedia Integration Language）的首字母缩写，把它的视线对准音频和视频世界。如果现在的工作草稿能够成为将来最终标准的指南，那么我们以后可能要做很多SMIL的工作了。
首先要知道的是SMIL是XML的子集。XML本质上是关于meta-data的，允许创建新的HTML方式的标记符来描述Web内容。
最明显（和最常见）的XML的例子是 或 标记符的创建。
很多网页有清楚的author和byline，但是现在它们通过没有差别的HTML来表达。处理这种类型的信息的明显的标记符对搜索引擎很有价值，这样可以马上分辨出文章的作者。XML使用文档类型定义（DTD）来描述XML的特定子集是如何组织的。在XML中，一般通过添加新的实体定义来扩展DTD（然而在SMIL中，不推荐这样做）。因为SMIL是基于XML的最早的工作草稿之一，所以最好等到XML成为现实那一天。
3.2.3 基础知识
SMIL的好处是它的结构很象HTML，所以不难掌握它的基础知识。实际上，最基本的SMIL文档看起来与基本的HTML文档基本相同：
用 标记符替换标记符，就得到一个SMIL文档。SMIL的另一个好处是它的核心功能基于这两个标记符: 和 。知道了这两个标记符，就可以写SMIL表达式了。当你知道 是"parallel"的缩写， 是"sequence"的缩写时，它们的功能就显而易见了。所以可以把 放在想要开始播放媒体的地方，把 放在播放某个序列条目的地方。这两个标记符可以嵌套，所以可以在子序列中开始几个平行的其它媒体对象，或者可以在一个序列中平行地播放几个对象。SMIL媒体类型的表示与HTML略有不同。图像的表示几乎相同，但是因为所有XML标记符不需要第二个结束标记符，所以需要一个反斜线放在结尾。因此：
变成
注意我们没有明确指明我们在调用一个GIF图像。SMIL独立地处理这种情况，从服务器、操作系统，或者SMIL中的"type"属性中提取信息。这不如开始时那么复杂：SMIL知道我们在标记符中处理图像，所以不需要直接指明是GIF图像。当然，既然它是一种多媒体标记语言，它就包含了不只图像一种媒体类型。有效的媒体类型包括音频、动画、a(anchor标记符)、ref(通用的媒体类型指示，用在不能确定媒体类型时)、img、文本、文本流、视频，当然还有par和seq标记符。
3.2.4 结构
你们中的很多人可能曾经咬牙切齿地盼望停止使用表格和控制间距的GIF的一天 - 用样式表控制页面上元素的布局和表现。
SMIL的好消息是允许马上精确控制元素。坏消息是它不只使事情容易和使用样式表作为它的缺省布局协议。它不采用封装 标记符的 和 标记符。然而，基本的SMIL布局元素与CSS很相似，而且CSS本身它也支持，所以确定"text/css"将允许用样式表对页面进行布局。这两种方式都可以有效地在页面上定位元素：
和
#smile {top:200; left:100;z-index:5; width:100; height:220 }
我不知道W3C为什么不直接选择CSS，但我肯定他们有自己的原因。
3.2.5不用脚本的条件化内容
过去，在HTML文件中建立条件化的内容一般要涉及到某种服务器端的方案，如XSSI或ASP，或者某些使用相当广泛的客户端脚本。SMIL使用
可以简单地把
作为一个例子，假设你建立了一个视频表现，而且你有对各种不同连接速度的不同的表现版本。使用
#smile {top:200; left:100; z-index:5;width:100; height:220 }
video_high" system-bitrate="33000" />
video_good" system-bitrate="22000" />
video_slow" system-bitrate="12000" />
video_crap" system-bitrate="8000" />
3.2.6 属性
现在，假设你已经具备了SMIL的基本知识，但是建立真正功能强大的SMIL文档需要了解所有可用的SMIL标记符。不幸的是，本文不能对此涉及太多。我前面说过，SMIL现在只是一份工作草稿，还不值得花费精力学习所有的SMIL属性。
那么就让我们看看一些最常用的SMIL属性：
abstract - 提供附加信息，或者内容的概述。
author - 内容的整理者。
begin - 决定媒体对象在它的父包容器中何时出现。
copyright - 版权信息。
dur - 媒体对象的持续时间。
end - 媒体对象的结束。
id - 对象的名称。
repeat - 媒体对象重复的次数。
system-bitrate - 连接速度。
system - captions - 是否使用音轨的基于文本的等价物。
system-language - 表现的语言。
system-overdub-or-caption - 使用子标题还是配音对话。
system-required - 扩展的名称。
system-screen-size - 特定的屏幕大小。
system-screen-depth - 表现的像素深度。
3．3 SMIL前景展望
现在，我把这样的想法充满你的头脑：一种规范的工作草稿，所有的主流浏览器都不支持。
SMIL是一种在网上实现多媒体内容的尝试，但是是否最终规范会得到广泛使用，或者甚至是否能发展为可以发布的规范，都是一种猜测。和SMIL草稿直接竞争的技术，如Shockwave、RealFlash和Active Movie Control的市场可能都比SMIL媒体对象类型的大。
实际上，对SMIL的真正威胁来自于动态HTML。浏览器厂商已经试图使动态HTML包容多媒体内容，他们可能把SMIL当作不必要和令人困惑的选择。另一方面，W3C在互联网社会中得到广泛的尊敬，她支持的多媒体规范应该能使网景和微软做出一些装模做样的笨拙的和不和谐的尝试 - 在为共同的目标而处理多媒体时。
网景和微软好象都对SMIL保持一种观望的态度，每一方在宣布某种支持之前都在等着对方的声明。可能至少要一年的时间，SMIL才能被考虑集成到浏览器中，这取决于W3C是否能给这份草稿正式的祝福（也取决于便宜的、高速的连接是否能成为现实）。总之，SMIL还是不错的。它还不够强大，但是孕育着希望。我宁愿CSS成为SMIL缺省的布局协议，除非它的草稿作者有使用基于SMIL的布局的更好的理由。我也期望看到不同的回放速度和在给定媒体对象内设置开始和结束点的能力。以我的理解，草稿还不支持这样的功能。因此，我们现在我们不得不等待，并期望这种目前不被支持的规范能实现我们喜欢的浏览器能支持的版本。
扫一扫
2507
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
