第八章音频视频.pptVIP

第 8 章 因特网上的音频/视频服务 8.1 概述 8.2 流式存储音频/视频 8.3 交互式音频/视频 8.4 改进“尽最大努力交付”的服务 8.1 概述 网络层提供两种服务：面向连接的虚电路服务和面向无连接的数据报服务。 因特网 IP 层提供的“尽最大努力交付”服务，以及每一个分组独立交付的策略，对传送数据信息也是很合适的。 因特网使用的 TCP 协议可以很好地解决网络不能提供可靠交付这一问题。 多媒体信息的特点 多媒体信息（包括声音和图像信息）与不包括声音和图像的数据信息有很大的区别。 多媒体信息的信息量往往很大。(p306) 在传输多媒体数据时，对时延和时延抖动均有较高的要求。 多媒体数据往往是实时数据(real time data)，它的含义是：在发送实时数据的同时，在接收端边接收边播放。 因特网是非等时的 模拟的多媒体信号经过采样和模数转换变为数字信号，再组装成分组。这些分组的发送速率是恒定的（等时的）。 传统的因特网本身是非等时的。因此经过因特网的分组变成了非恒定速率的分组。 在接收端设置缓存 接收端需设置适当大小的缓存。当缓存中的分组数达到一定的数量后再以恒定速率按顺序把分组读出进行还原播放。 缓存实际上就是一个先进先出的队列。图中标明的 T 叫做播放时延。 缓存的影响 缓存使所有到达的分组都经受了迟延。 早到达的分组在缓存中停留的时间较长，而晚到达的分组在缓存中停留的时间则较短。 以非恒定速率到达的分组，经过缓存后再以恒定速率读出，就能够在一定程度上消除了时延的抖动。但我们付出的代价是增加了时延。 需要解决的问题 在传送时延敏感(delay sensitive)的实时数据时，不仅传输时延不能太大，而且时延抖动也必须受到限制。 对于传送实时数据，很少量分组的丢失对播放效果的影响并不大（因为这是由人来进行主观评价的），因而是可以容忍的。丢失容忍(loss tolerant)也是实时数据的另一个重要特点。 需要解决的问题（续） 由于分组的到达可能不按序，但将分组还原和播放时又应当是按序的。因此在发送多媒体分组时还应当给每一个分组加上序号。这表明还应当有相应的协议支持才行。 要使接收端能够将节目中本来就存在的正常的短时间停顿（如音乐中停顿几拍）和因某些分组的较大迟延造成的“停顿”区分开来。这就需要增加一个时间戳(timestamp)，以便告诉接收端应当在什么时间播放哪个分组。 必须改造现有的因特网 如果想在因特网上传送音频/视频数据就需要改造现有的因特网。 大量使用光缆和高速路由器，网络的时延和时延抖动就可以足够小，在因特网上传送实时数据就不会有问题。 把因特网改造为能够对端到端的带宽实现预留(reservation)，把使用无连接协议的因特网转变为面向连接的网络。 目前因特网提供的音频/视频服务大体上可分为三种类型 流式(streaming)存储音频/视频 ——边下载边播放。 流式实况音频/视频 ——边录制边发送 。 交互式音频/视频——实时交互式通信。 8.2 流式存储音频/视频 传统的下载文件方法 8.2.1 具有元文件的万维网服务器 元文件就是一种非常小的文件，它描述或指明其他文件的一些重要信息。 8.2.2 媒体服务器 媒体服务器也称为流式服务器(streaming server) ，它支持流式音频和视频的传送。 媒体播放器与媒体服务器的关系是客户与服务器的关系。 媒体播放器不是向万维网服务器而是向媒体服务器请求音频/视频文件。 媒体服务器和媒体播放器之间采用另外的协议进行交互。 使用媒体服务器 流媒体协议 实时传输协议（RTP） 多媒体数据流的一种传输协议。在一对一或 一对多的传输情况下，提供时间信息和实现流同 步，一般采用UDP传送数据。负责对流媒体数据 进行封包并实现媒体的实时传输。 局限性:不保证按序到达的可靠传输机制,不提供流量和拥塞控制. 实时流协议 RTSP RTSP 协议以客户服务器方式工作，它是一个应用层的多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：暂停/继续、后退、前进等。因此 RTSP 又称为“因特网录像机遥控协议”。 要实现 RTSP 的控制功能，我们不仅要有协议，而且要有专门的媒体播放器(media player)和媒体服务器(media server)。 苹果公司的QuickTime和Real Networks公司的RealPlayer. 流媒体协议 实时控制协议（RTCP） 提供流量控制和拥塞控制服务。RTCP包含有已发 送、丢失包的数量等统计资料。与RTP配合使用。 媒体描述协议（SDP） SDP文件是服务器端