第7章多媒体网络案例分析.ppt

第7章 多媒体网络;7.1 多媒体网络应用;7.1 多媒体网络应用;7.1 多媒体网络应用;视频：以恒速显示的图片序列。 性质 高比特率需求 视频压缩 空间冗余：给定图像的内部冗余。 时域冗余：反映一幅图像和后续图像的重复程度。 生成不同比特率的视频版本。;7.1 多媒体网络应用;7.1 多媒体网络应用;7.1 多媒体网络应用;7.1 多媒体网络应用;;流式存储音频和视频： 特色： 相互作用：客户机能够暂停、倒带、快进、推动滑动条。 连续播放：一旦开始播放，按照初始计量的时序进行。对仍在传输数据的定时约束，及时播放。 网络为流式应用提供的平均吞吐量至少等于视频的比特率。;7.1 多媒体网络应用;7.1 多媒体网络应用;7.2 流式存储视频;7.2 流式存储视频;客户端缓存, 播放;;播放缓存:平均填充速率 (x), 播放速率 (r): x r: 缓存最后会被排空 (导致视频冻结，直到缓冲区???满Q比特再次播放)。 x r: 缓存不会排空，提供的初始播放延迟是大到足以吸收变化x(t)。 初始播放时延后，用户将享受连续的播放直到视频结束。 ;UDP流：服务器通过UDP以一种稳定的速率记录下视频块，用以客户的视频消耗速率相匹配的速率传输视频。 通常发送速率= 编码速率 = 恒定速率 则供给速率 = 恒定速率 – 分组丢包 UDP视频流：应用层采用传输协议RTP封装运输分组。 UDP控制连接：客户发送有关会话状态变化的命令。;UDP流不足: 服务器和控制之间的可用带宽无法预测并且是变化的，恒定速率UDP流不能够提供连续播放。 要求RTSP服务器这样的媒体控制器，以对每个进行中的客户会话处理客户到服务器的交互请求和跟踪客户状态。 防火墙配置多为阻塞UDP流量，无法接收UDP视频。;HTTP流: 视频直接作为具有一个特定URL的普通文件存储在HTTP服务器上。 客户要看视频，步骤如下： TCP连接 发送一个对视频URL的HTTP GET请求 服务器通过HTTP响应报文发送视频文件。 问题：TCP的拥塞控制和流量控制等可靠性传输机制是否会妨碍视频的连续播放？ 客户缓存和预取技术;预取视频：客户能够尝试以高于视频消耗速率的速率下载视频，预取将来会被消耗的视频帧，存在在客户应用缓存中。 平均TCP吞吐量大于媒体比特率就可以实现连续播放。;客户应用缓存和TCP缓存 一个满的客户应用缓存间接对服务器到客户能够发生的视频速率施加限制。;视频的早期中止和重定位 利用HTTP GET 报文中的HTTP字节范围首部，只是指示客户当前希望获取到的字节范围。 产生网络带宽和服务器资源的浪费。;HTTP流的缺陷：所有客户接收到相同编码的视频。 DASH: 经HTTP的动态适应性流 视频编码为几个不同版本，具有不同的比特率。 客户动态请求来自不同版本的文件块。;服务器: 将视频文件划分为许多文件块。 每个文件块按照不同的比特率编码存储，构造不同版本的视频文件。 告示文件:为每个视频版本都有一个URL及其比特率 客户: 周期性测量客户-服务器间的可用带宽。 查询告示文件，每次请求一个文件块： 鉴于目前的带宽选择最大编码速率，实现可持续播放。 不同时间选择不同速率编码。;DASH的客户端是“智能” ， 可决定： 什么时候请求文件块。 请求什么编码的文件块。 向谁请求文件块。 ;挑战: 如何向位于全世界的所有用户流式传输所有流量同时提供连续播放和高交互性。 方法 1: 建立单一的大规模数据中心 单点故障。 单点网络拥塞。 客户与数据中心相关甚远，带来大的停滞时延。 视频可能经过相同的通信链路传输多次。 ;方法 2: 内容分发网CDN，在遍及因特网的数以百计的服务器上存储视频副本，将用户的请求定向到一个将提供最好的用户体验的CDN位置。 服务器安置原则： 深入: 在接入网部署CDN服务器集群 靠近端用户 Akamai首创,部署了 1700 位置部署集群 维护管理不方便 邀请做客: 靠近许多第一层ISP的Pop的位置（靠近接入网）部署少量大集群。 维护管理成本较低 端客户实验较高和吞吐量较低 ;;CDN集群选择策略 挑战: 如何动态地将客户定向到CDN中服务器集群或是数据中心的机制。 选择地理上最为邻近的集群 IP任播 主动选择:让用户根据给定的CDN集群列表选择。 ;案例学习: Netflix;;7.2 IP语音 VoIP;因特网电话：经因特网的实时会话式语音。 PC到PC电话：即时讯息服务提供该业务。 PC到phone： Dialpad Net2phone 有Web摄像的视频会议。;通过一个例子介绍因特网电话 讲话者的语音：交互的语涌, 静默期。 在语涌期间64 kbps 仅在语涌期产生分组 以8 Kbytes/s