第7章多媒体网络.

整理文档很辛苦,赏杯茶钱您下走!

免费阅读已结束,点击下载阅读编辑剩下 ...

阅读已结束,您可以下载文档离线阅读编辑

资源描述

第7章多媒体网络17.1多媒体网络的应用7.2流式存储视频7.3IP语音7.4实时会话式应用的协议7.5支持多媒体的网络7.1多媒体网络应用多媒体网络:支持传输多媒体数据的通信网络。多媒体网络应用:任何应用音频或视频的网络应用。7.1多媒体网络应用假设三个不同用户使用不同因特网应用,假设会话时间为4000s:用户1在Facebook页面上下载或是上传照片,每10s操作一次,照片大小平均为200KB。用户2通过手机从因特网上听音乐,音乐128kbps编码。用户3正在观看2Mbps编码的视频。7.1多媒体网络应用比特率67分钟传输的字节Frank脸谱160kbps80MBMartha音乐128kbps64MBVictior视频2Mbps1GB三种因特网应用的比特率需求的比较视频:以恒速显示的图片序列。性质高比特率需求视频压缩空间冗余:给定图像的内部冗余。时域冗余:反映一幅图像和后续图像的重复程度。生成不同比特率的视频版本。……………………...…空间冗余压缩编码:……………………...…帧i帧i+1时域冗余压缩编码:7.1多媒体网络应用音频:音频采样-量化编码-解码以恒定速率对模拟信号取样。电话:8,000样本/secCD音乐:44,100样本/sec量化每个样本,即四舍五入。如28=256可能的量化值每个量化值用比特来表示。8比特表示256个值例子:8,000样本/sec,256个量化值--64,000bps接收方将它转换回模拟信号:某种质量降低7.1多媒体网络应用音频的性质:低比特率。例如:CD:1.411MbpsMP3:96,128,160kbps因特网电话:5.3-13kbps不同的编码PCM,MP3(压缩编码),AAC(高级音频编码)用户体验对音频的小失误比视频的小失误更敏感。7.1多媒体网络应用多媒体网络应用的类型流式存储音频和视频会话式IP语音/视频流式实况音频/视频7.1多媒体网络应用多媒体网络应用的类型流式存储音频和视频:预先录制的视频或是音频放置在服务器上,用户向这些服务器发送请求按需观看这些视频。1.视频录制(假设30帧/秒)2.视频传输流:当客户正在从视频的一个位置开始播放时,与此同时从服务器接收该视频的后续部分。网络时延(假设是固定的)时间3.收到视频,客户端播放(30帧/秒)特色:视频开始播放,不需要整个视频下载完整。7.1多媒体网络应用流式存储音频和视频:特色:相互作用:客户机能够暂停、倒带、快进、推动滑动条。连续播放:一旦开始播放,按照初始计量的时序进行。对仍在传输数据的定时约束,及时播放。网络为流式应用提供的平均吞吐量至少等于视频的比特率。7.1多媒体网络应用7.1多媒体网络应用多媒体网络应用的类型会话式IP语音(因特电话)和视频,特性:高度时延敏感:150ms良好,400msOK容忍偶尔丢包7.1多媒体网络应用多媒体网络应用的类型流式实况音频和视频因特网无线电谈话节目实况体育事件特色:有一定的时延容忍,也有定时约束。交换性差。7.2流式存储视频流式视频系统类型:UDP流HTTP流适应性HTTP流(DASH)共同特点:使用客户端应用缓存,缓解变化的端到端的时延和变化的服务器和客户端之间可用带宽的影响。7.2流式存储视频固定比特率传输视频time可变的网络时延客户收到视频客户以固定比特率播放视频客户播放时延视频缓存d客户机侧缓存,播放时延补偿网络增加的时延,时延抖动客户端缓存,播放填充速率x(t)客户端应用缓存,sizeB播放视频速率CBRr缓存填充限制,Q视频服务器客户端流式视频分析填充速率x(t)客户应用缓存,大小=B视频播放速率CBRr_x0013_缓存填充限制,Q视频服务器客户1.开始填充客户应用缓存,直到tp开始播放2.t=tp=Q/x(t)开始播放,3.缓存填充变化速率与填充速率x(t)和播放速率r变化而变化。流式视频分析播放缓存:平均填充速率(x),播放速率(r):xr:缓存最后会被排空(导致视频冻结,直到缓冲区填满Q比特再次播放)。xr:缓存不会排空,提供的初始播放延迟是大到足以吸收变化x(t)。初始播放时延后,用户将享受连续的播放直到视频结束。视频服务器填充速率x(t)视频播放速率CBRr客户应用缓存,大小=B缓存填充限制,QUDP流:服务器通过UDP以一种稳定的速率记录下视频块,用以客户的视频消耗速率相匹配的速率传输视频。通常发送速率=编码速率=恒定速率则供给速率=恒定速率–分组丢包UDP视频流:应用层采用传输协议RTP封装运输分组。UDP控制连接:客户发送有关会话状态变化的命令。7.2.1UDP流UDP流不足:服务器和控制之间的可用带宽无法预测并且是变化的,恒定速率UDP流不能够提供连续播放。要求RTSP服务器这样的媒体控制器,以对每个进行中的客户会话处理客户到服务器的交互请求和跟踪客户状态。防火墙配置多为阻塞UDP流量,无法接收UDP视频。7.2.1UDP流HTTP流:视频直接作为具有一个特定URL的普通文件存储在HTTP服务器上。客户要看视频,步骤如下:TCP连接发送一个对视频URL的HTTPGET请求服务器通过HTTP响应报文发送视频文件。问题:TCP的拥塞控制和流量控制等可靠性传输机制是否会妨碍视频的连续播放?客户缓存和预取技术7.2.2HTTP流预取视频:客户能够尝试以高于视频消耗速率的速率下载视频,预取将来会被消耗的视频帧,存在在客户应用缓存中。平均TCP吞吐量大于媒体比特率就可以实现连续播放。7.2.2HTTP流客户应用缓存和TCP缓存一个满的客户应用缓存间接对服务器到客户能够发生的视频速率施加限制。_x0013__x0013_变化填充速率,x(t)_x0013_TCP发送缓存视频文件TCP接收缓存应用播放缓存服务器客户假设用户暂停播放视频,会出现什么情况?7.2.2HTTP流视频的早期中止和重定位利用HTTPGET报文中的HTTP字节范围首部,只是指示客户当前希望获取到的字节范围。产生网络带宽和服务器资源的浪费。7.2.2HTTP流HTTP流的缺陷:所有客户接收到相同编码的视频。DASH:经HTTP的动态适应性流视频编码为几个不同版本,具有不同的比特率。客户动态请求来自不同版本的文件块。7.2.3适应性流和DASH服务器:将视频文件划分为许多文件块。每个文件块按照不同的比特率编码存储,构造不同版本的视频文件。告示文件:为每个视频版本都有一个URL及其比特率客户:周期性测量客户-服务器间的可用带宽。查询告示文件,每次请求一个文件块:鉴于目前的带宽选择最大编码速率,实现可持续播放。不同时间选择不同速率编码。7.2.3适应性流和DASHDASH的客户端是“智能”,可决定:什么时候请求文件块。请求什么编码的文件块。向谁请求文件块。7.2.3适应性流和DASH挑战:如何向位于全世界的所有用户流式传输所有流量同时提供连续播放和高交互性。方法1:建立单一的大规模数据中心单点故障。单点网络拥塞。客户与数据中心相关甚远,带来大的停滞时延。视频可能经过相同的通信链路传输多次。7.2.4内容分发网方法2:内容分发网CDN,在遍及因特网的数以百计的服务器上存储视频副本,将用户的请求定向到一个将提供最好的用户体验的CDN位置。服务器安置原则:深入:在接入网部署CDN服务器集群靠近端用户Akamai首创,部署了1700位置部署集群维护管理不方便邀请做客:靠近许多第一层ISP的Pop的位置(靠近接入网)部署少量大集群。维护管理成本较低端客户实验较高和吞吐量较低假设Bob(client)请求播放视频视频存储的CDN:://netcinema.com/6Y7B23Vfromnetcinema.comwebpage22.resolve’slocalDNSnetcinema’s权威DNS33.netcinema’sDNSreturnsURL://KingCDN.com/NetC6y&B23viaKingCDN’sauthoritativeDNS,whichreturnsIPaddressofKIingCDNserverwithvideo56.requestvideofromKINGCDNserver,streamedviaHTTPKingCDNauthoritativeDNSCDN集群选择策略挑战:如何动态地将客户定向到CDN中服务器集群或是数据中心的机制。选择地理上最为邻近的集群IP任播主动选择:让用户根据给定的CDN集群列表选择。案例学习:NetflixNet'flix本身拥有非常少的基础设施,利用第三方提供服务。拥有注册和支付服务。亚马逊云服务:Netflix将视频的母版上载到亚马逊的云主机。创建不同版本的视频向CDNs上载视频版本负责在线主页管理Netflix同时使用3个第三方CDN公司:Akamai,Limelight,Level-311.Bob管理Netflix账号Netflix注册和支付服务器Amazon云AkamaiCDNLimelightCDNLevel-3CDN22.Bob浏览Netflix视频网站33.返回告示文件4.DASH视频块向CDNs上载不同的视频版本案例学习:Netflix7.2IP语音VoIP因特网CDIP电话网关IP电话网关公用电话网BA电路交换电路交换分组交换因特网电话:经因特网的实时会话式语音。PC到PC电话:即时讯息服务提供该业务。PC到phone:DialpadNet2phone有Web摄像的视频会议。通过一个例子介绍因特网电话讲话者的语音:交互的语涌,静默期。在语涌期间64kbps仅在语涌期产生分组以8Kbytes/sec速率的20msec块:160字节数据在每块上加上应用层首部:块+首部封装在UDP段中在语涌期应用程序每20msec向套接字发送UDP段。网络丢包:由于网络拥塞的IP数据报丢失(路由器缓存溢出)时延丢包:在接收方,IP数据报到达太迟而无法播放时延:网络中的处理、排队;端系统(发送方,拒)时延典型的最大可容忍时延:400ms丢包容忍:取决于语音编码,差错隐藏丢失,丢包率在1%和10%之间可以容忍分组时延抖动:从源中产生的分组到它在接收方收到的这段时间,对于不同的分组可能有波动。时延抖动考虑两个连续分组的端到端时延:差异能大于或小于20msec恒定比特率视频传输时间可变的网络时延时延抖动客户机接收视频客户机以恒定比特率播放客户机播放时延缓存的视频通过以下机制结合实现时延抖动的消除时间戳播放时延固定播放时延适应性播放时延7.3.2在接收方消除音频的时延抖动固定播放时延接收方试图在块生成后的qmsec来播放每个块块具有时戳t:在t+q播放块在t+q后块到达:数据到达太迟而不能播放,数据“丢失”Q的折衷:大q:分组丢失少小q:更好的交互体验41固定播放时延假设发送方在语涌期每20msec产生分组第一个分组在时间r收到,第一个播放进度:在p开始;第二个播放进度:在p’开始packets时间分组产生分组收到丢包rpp'播放进度p'-r播放进度p-r自适应播放时延络时延的估计接收到分组收到分组i第分组分组i的网络间接收方播放分组收方播间接收方接收分组收方接第i个分组i个分iiiiiidtrprt在接收方平均时延的动

1 / 49
下载文档,编辑使用

©2015-2020 m.777doc.com 三七文档.

备案号:鲁ICP备2024069028号-1 客服联系 QQ:2149211541

×
保存成功