因特网上的音频视频服务课件.ppt

第8章因特网上的音频/视频服务 8.1 概述 计算机网络最初是为传送数据信息设计的。因特网 IP 层提供的“尽最大努力交付”服务，以及每一个分组独立交付的策略，对传送数据信息很合适。因特网使用的 TCP 协议可以很好地解决IP层不能提供可靠交付这一问题。 随着技术的进步，许多用户开始利用因特网传送音频/视频信息。这种音频/视频信息称为多媒体信息。（这种多媒体信息如电视会议原本在公用电话网上传送，技术已相当成熟，只是费用较高） 多媒体信息与不包括声音和图像的数据信息的区别： (1)多媒体信息的信息量往往很大。 (2)在传输多媒体数据时，对时延和时延抖动(即时延变化)均有较高的要求。 多媒体数据往往是实时数据(real time data)，它的含义是：在发送实时数据的同时，在接收端边接收边播放。 因特网是非等时的 模拟的多媒体信号经过采样和模数转换变为数字信号，再组装成分组。这些分组的发送速率是恒定的（等时的）。 传统的因特网本身是非等时的。因此经过因特网的分组变成了非恒定速率的分组。 为解决上述问题可在接收端设置适当大小的缓存 如下图所示，当缓存中的分组数达到一定的数量后再以恒定速率按顺序把分组读出进行还原播放。 缓存实际上就是一个先进先出的队列。图中标明的 T 叫做播放时延。 需要解决的问题 （1）在传送时延敏感(delay sensitive)的实时数据时（如视频会议），不仅传输时延T不能太大，而且时延抖动（即时延变化）也必须受到限制。 （2）对于传送实时数据，很少量分组的丢失对播放效果的影响并不大（因为这是由人来进行主观评价的），因而是可以容忍的。因此，实时数据的传输在运输层就应采用UDP而不是TCP。丢失容忍(loss tolerant)也是实时数据的另一个重要特点。 需要解决的问题（续） （3）由于分组到达可能不按序，但将分组还原和播放时又应当是按序的。因此在发送多媒体分组时还应当给每一个分组加上序号。这表明还应当有相应的协议支持才行。 （4）要使接收端能够将节目中本来就存在的正常的短时间停顿（如音乐中停顿几拍）和因某些分组的较大迟延造成的“停顿”区分开来。这就需要增加一个时间戳(timestamp)，以便告诉接收端应当在什么时间播放哪个分组。 要解决以上问题必须改造现有的因特网 有人认为：只要大量使用光缆和高速路由器，网络的时延和时延抖动就可以足够小，在因特网上传送实时数据就不会有问题。 也有人认为：必须把因特网改造为能够对端到端的带宽实现预留(reservation)，从而根本改变因特网的协议栈：把无连接的网络转变为面向连接的网络。 还有人认为：部分改动因特网的协议栈所付出的代价较小，而这也能够使多媒体信息在因特网上的传输质量得到改进。 尽管上述争论仍在继续，但因特网的一些新的协议也在不断出现： 目前因特网提供的音频/视频服务大体上可分为三种类型 1、流式存储音频/视频： 　　这种类型是先把已压缩的录制好的音频/视频文件存储在服务器上，用户通过因特网“边下载边播放”。这里的下载不是传统意义上的下载，文件并没有存储到硬盘上，播放完毕后，用户的硬盘上没有留下有关播放内容的任何痕迹，有利用保护版权。 2、流式实况音频/视频： 　这种类型和无线电台或电视台的实况广播相似，不同之处是音频/视频节目的广播是通过因特网来传送的。它的特点是，节目不是事先录制好和存储在服务器中，而是发送方边录制边发送（不是录制完毕再发送） 3、交互式音频/视频 　　这种类型是用户使用因特网和其他人进行实时交互式通信，现在的因特网电话或因特网电视会议就属于这种类型。 新名词：流媒体：即上面讲的流式音频/视频,其特点是“边下载边播放” 8.2 流式存储音频/视频 传统的下载文件方法: 传统下载最大的缺点是： 下载时间太长，必须全部下载完才能开始播放，为此，改进措施： 措施一：8.2.1 具有元文件的万维网服务器 　　　第一种改进措施就是在万维网服务器中增加一个元文件，该文件里面保存了有关这个音频/视频文件的信息，如该音频/视频的URL。 使用元文件下载音频/视频文件 ? 浏览器用户使用 HTTP 的 GET 报文接入到万维网服务器。这个超链指向一个元文件。这个元文件有实际的音频/视频文件的统一资源定位符 URL。 ? 万维网服务器把该元文件装入 HTTP 响应报文的主体，发回给浏览器。 ? 客户机浏览器调用相关的媒体播放器，把提取出的元文件传送给媒体播放器。 ? 媒体播放器使用元文件中的 URL ，向万维网服务器发送 HTTP 请求报文，要求下载音频/视频文件。 ? 万维网服务器发送 HTTP 响应报文，把该音频/视频文件发送给媒体播放器。媒体播放器边下载边解压缩边播放。 措施二：