第7讲 多媒体络.ppt

《第7讲 多媒体络.ppt》由会员分享，可在线阅读，更多相关《第7讲 多媒体络.ppt（54页珍藏版）》请在麦多课文档分享上搜索。

1、第7讲 多媒体网络,第7讲 多媒体网络,本讲目标: 了解多媒体网络的应用要求 延迟 带宽 数据丢失 学习如何将因特网所提供的尽力而为的服务用到极致 学习因特网将如何进化以便更好的支持多媒体应用,本讲概述: 多媒体的网络应用 存储式音频/视频流 RTSP 交互式的实时应用 IP电话举例 RTP H.323 and SIP 在尽力而为的基础上发展 调度和策略的实施 集成服务 区别服务,第7讲 多媒体网络,网络中的多媒体,基本特征: 一般对延迟敏感. 但可以容忍部分数据的丢失: 偶尔发生的数据丢失会产生轻微的干扰，可以忽略. 数据资料的传输(程序, 银行信息, etc.), 却正好相反，可以容忍延迟

2、，但不能容忍数据的丢失. 多媒体也称 “连续媒体（continuous media）/流媒体”,多媒体应用的分类: 存储式的 audio/video流媒体 直播式的audio/video流媒体 实时交互式的audio/video,第7讲 多媒体网络,网络中的多媒体 (2),存储式流媒体 客户端从服务器请求audio/video文件，以流水方式从网络上进行接收并显示 交互: 用户可进行操作 (如同操作录像机: 暂停, 恢复播放, 快进, 回退, etc.) 延迟: 从客户端发出请求到开始播出为110秒,实况转播（单向实时） : 如同 TV 和无线广播, 但是从因特网上传送 非交互, 只是收视/收

3、听 实时交互 : 电话或视频会议 由于实时特性，比流媒体点播和实况转播要求更为严格 Video: 150 ms尚可 Audio: 150 ms比较好, 400 ms可以接受,第7讲 多媒体网络,网络中的多媒体 (3): 挑战,TCP/UDP/IP 协议族提供的是尽力而为,无延迟或延迟变动承诺的服务. 流媒体的应用有 5-10的延迟今天看来十分普遍,但当链路(越洋线路)拥塞时，情况会急剧恶化 实时交互应用对分组延时和抖动（ jitter）具有严格的限制. 抖动（Jitter）是指在同一分组流传输过程中发生的分组延时变化.,如果在因特网中能分出服务级别，那么多媒体应用的设计将要容易的多. 但是在公

4、共因特网中,所有分组所受到的服务完全是相等的. 包含实时交互audio和video 数据分组在网络中所受到的待遇,和其他分组完全一样. 目前对在因特网中提供区别对待的服务的研究一直在进行之中.,第7讲 多媒体网络,网络中的多媒体 (4): 将尽力而为的服务用到极致,为减少“尽力而为”的因特网的服务原则的影响，我们可以: 使用UDP来避免TCP和它的慢启动过程 在客户端缓存部分内容和控制回放来弥补传输抖动造成的影响 我们可以给分组加上时间戳来提醒接收端及时回放该分组. 选择压缩等级来适配可用带宽,我们还可以发送冗余的分组来减少分组丢失所造成的影响。 我们将讨论这些 “雕虫小技”,第7讲 多媒体网

5、络,因特网应如何进化才能更好的支持多媒体?,集成服务（Intserv）的哲学: 改变因特网协议以便应用程序能够预定端对端的带宽 需要部署协议来预留带宽 必须修改路由器的调度策略来响应带宽预留 应用程序必须体为网络提供信息流量的描述,并进而遵循这样的描述. 在主机和路由器中开发新的更复杂的软件,区别服务（Diffserv）的哲学: 对因特网的基础结构进行改造,使其可以提供分级的服务. 分组要加标记 用户为高级别的服务付出更多的费用. ISP为骨干网络收发高级别的分组付出更多的费用.,第7讲 多媒体网络,因特网应如何进化才能更好的支持多媒体?(续),自由放任( Laissez-faire )哲学

6、没有带宽预定,不搞分组标记 只要需求增加,供应更多的带宽 将存储内容置于网络的边缘: ISP和主干上增加缓存 内容提供商将内容置于 CDN 结点 P2P: 选择临近的存储有内容的对等结点,虚拟专网 (VPN) 为企业保留永久性的带宽域( blocks of bandwidth）. 路由器可以根据IP 地址来识别VPN的信息流 路由器使用特殊的调度策略来提供预留的带宽.,第7讲 多媒体网络,存储式Audio & Video流,存储式流媒体: Audio/video 文件存储在服务器上 用户根据需求调用audio/video 文件. Audio/video 在请求的10秒以内提供. 提供交互性 (

7、暂停, 重新定位等, etc.).,媒体播放器（Media player）: 消除抖动 解压缩 错误校正 提供图形交互界面进行控制 可以使用插件（Plug-in）将媒体播放器植入浏览器窗口.,第7讲 多媒体网络,从Web服务器调用流媒体 (1),Audio和 video文件存储在 Web服务器上 最原始的方法 浏览器使用HTTP请求报文从Web服务器访问流媒体文件 Web服务器用HTTP响应报文发送文件 content-type 首部行描述了 audio/video的编码 浏览器启动媒体播放器,并将文件传递给它 媒体播放器解读该文件,主要缺点: 媒体播放器通过浏览器作为中介 与Web 服务器交

8、互,第7讲 多媒体网络,从Web服务器调用流媒体(2),改进: 在服务器和播放器之间建立连接 浏览器请求和接收元文件（ meta file ）(用来描述对象的文件）而不是接收文件本身) ; Content-type首部说明是特定的audio/video应用 浏览器启动媒体播放器并将元文件传递给它 播放器与服务器建立TCP 连接并发送 HTTP请求.,问题讨论: 媒体播放器使用HTTP通信, 没有 pause, ff, rwnd 功能 可以考虑使用 UDP通信,第7讲 多媒体网络,从流媒体服务器调用流媒体,该结构可以使用非HTTP协议进行通信在服务器和流媒体播放器之间进行通信 可以使用UDP来替

9、代 TCP.,第7讲 多媒体网络,实时流媒体协议（Real Time Streaming Protocol）: RTSP,HTTPHTTP所服务的媒体已经定型: HTML, images, applets, etc. HTTP 的设计没有考虑流媒体 (i.e., audio, video, etc.) RTSP: RFC 2326 客户端-服务器应用层协议. 可为用户提供播出控制: rewind, fast forward, pause, resume, repositioning, etc,它所不能做到的: 没有流媒体传递过程中的audio/video数据的封装 不限制流媒体的传递方式; 既

10、可以用 UDP也可以用TCP 没有定义流媒体播放器如何对 audio/video数据进行缓存 RealNetworks 服务器和播放器使用RTSP 互相向对方发送控制信息,第7讲 多媒体网络,RTSP: 带外控制-out of band control,FTP 使用了 “带外”的控制通道: 文件传输通过一个通道 控制信息 (cd, rm, mv, etc.) 则通过分离的TCP连接发送 .“带外”和 “带内” 通道使用不同的端口号.,RTSP 报文也使用带外通道传送: RTSP控制报文使用的端口号与媒体流使用的不同，所以是带外传递. 流媒体的分组结构不是由RTPS定义的，因此被认为是在“带内”

11、传输的. 如果RTSP报文使用与流媒体相同的端口号，RTSP将与流媒体一起“间隔”传送.,第7讲 多媒体网络,RTSP 启动和控制传递,首先客户端获取多媒体的表示方式描述, 这可以由若干媒体流组成. 浏览器个根据表示方式所描述的内容类型调用媒体播放器 (辅助的应用程序-helper application). 表示描述中使用URL方法 rtsp:/ 将媒体流包含在内 播放器发送 RTSP SETUP请求; 服务器发送 RTSP SETUP响应. 播放器发送 RTSP PLAY 请求;服务器发送 RTSP PLAY 响应. 媒体服务器“泵出”流媒体. 播放器发送 RTSP PAUSE请求;服务器

12、发送 RTSP PAUSE响应. 播放器发送 RTSP TEARDOWN请求;服务器发送 RTSP TEARDOWN响应.,第7讲 多媒体网络,元文件举例,Twister ,第7讲 多媒体网络,RTSP会话,每次RTSP 都会有由服务器选择的会话定义符. 当客户端用SETUP请求启动会话，服务器就会使用定义符来进行响应. 在随后的过程中，客户端反复在每个请求中都使用该定义符,直到客户端使用 TEARDOWN请求来结束会话.,RTSP 端口号为 554. RTSP 报文可以通过 UDP或TCP发送. 每个 RTSP 报文可以通过一个分离的TCP 连接进行.,第7讲 多媒体网络,RTSP: 交换实

13、例,C: SETUP rtsp:/ RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp:/ RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp:/ RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp:/ RTSP/1.0 Session: 4231 S: 200 3 OK,第7讲 多媒体网络,RTSP: 流媒体的缓存,对RT

14、SP响应报文的缓存没有太大的意义. 但希望将媒体流缓存在客户端的邻近处. 大部分 HTTP/1.1的缓存控制机制也被RTSP采用. 缓存的控制首部可以用于RTSP SETUP 请求和相应: If-modified-since: , Expires: , Via: , Cache-Control:,对给定的流媒体来说代理缓存只能按数据段的形式保持. 代理缓存可以从本地缓存 中取出部分数据进行服务,而然后必须同原始服务器连接来填充部分丢失的资料, 但愿不要在客户端造成传输中断 . 从原始服务器传回的流媒体将通过代理传到客户端, 代理可以使用TCP来获取流媒体; 但代理服务器还是把RTSP控制报文发

15、给了原始服务器.,第7讲 多媒体网络,实时交互式应用,PC-2-PC phone PC-2-phone Dialpad Net2phone 视频会议 Webcams,现在来研究PC-2-PC IP 电话的案例,第7讲 多媒体网络,使用“尽力而为服务”的IP电话 (1),Best effort model packet delay, loss and jitter IP 电话举例 现在对分组延迟、丢失、和抖动对电话内容所造成的影响进行分析. IP 电话应用程序在对话期间产生分组 谈话期间的数据产生的速率为64 kb/s,在交谈期间, 每 20 ms应用程序将产生160字节 ( 8 kB/s *

16、20 ms )的数据块 数据块加上首部; 然后封装入UDP分组并发送 某些分组的丢失和延迟会给传输造成“起伏 (fluctuate)”. 受话方必须确定何时将数据块进行播放，如何处理缺失的数据块,第7讲 多媒体网络,IP 电话 (2),分组丢失 UDP 段封装在 IP 分组中 分组在路由器队列中可能溢出 TCP 虽然可以消除数据丢失, 但是 重发会增加延迟 TCP 的拥塞控制会降低速率 增加冗余分组会有帮助 端对端的延迟 为发送、传播、排队延迟的总和,端对端的延迟一旦超过400 ms将严重影响交互性; 这种延迟越小越好 延迟抖动(delay jitter) 考虑交谈期间两个连续的语音分组 在发

17、送端初始间隔为20 ms, 但到达受话方时，间隔可能发生变化(20ms;20ms) 消除抖动(removing jitter) 编顺序号码 时间戳(timestamps) 延迟播出(delaying playout),第7讲 多媒体网络,IP电话 (3): 固定的播放延迟,受话方试图在数据块产生的q ms后播出. 如果数据块有时间戳 t, 受话方将在t+q以后将数据播出 如果数据块在t+q以后到达, 受话方将予以丢弃. 顺序编号没有必要. 对丢失的分组需要采取策略.,Q的取值问题: large q: 分组丢失较少 small q: 较好的交互性能,第7讲 多媒体网络,IP 电话 (4):固定的

18、播放延迟,发送方在交谈期间每隔20 ms产生分组.首个分组在时间r到达第一种播放策略: 在p点开始第二种播放策略：在 p 点开始,第7讲 多媒体网络,从数据丢失中恢复 (1),数据丢失: 分组没有到达或比其计划中播出时间迟到 前向纠错( forward error correction ，FEC): 简单机制 以n个数据块为一组，为每一组创建一个冗余块，该块的形成是通过对这n个原始块的异或（xor）而得 发送这 n+1 个块（chunks）,增加了1/n的带宽. 如果从该n+1块里丢失的块最多只有一个的话，该块可以重新构建,播出延迟必须限定在这对n+1 分组的接收时间里 折衷: 加大 n, 带

19、宽浪费较小些 加大 n, 较长的播出延迟 加大 n, 出现2个或2个以上分组丢失的概率增加,第7讲 多媒体网络,从数据丢失中恢复(2),第二种 FEC 机制“捎带低品质流媒体” 发送低分辨率的媒体流 作为冗余信息例如, 一般流媒体的音 频的 PCM 为64 kb/s而冗 余的GSM为 13 kb/s.发送端从正常流媒体的 第n个数据块与（n-1）数 据块中创建冗余流媒体附 加上一起发送.,只要数据丢失不是连续的，受话端可以对数据丢失 进行补偿. 在开始播放前只要收到两个分组即可开始 为应付连续的数据丢失，也可以附加 (n-1)和 (n-2) 的冗余数据块,第7讲 多媒体网络,从数据丢失中恢复(

20、3),交错（ interleave ） 数据块被分割成较小的单元 例如, 45 ms一个数据块 将数据块如图交错传送 分组将携带来自不同数据块的较小的数据单元,在受话方重新装配数据块 如果分组丢失, 但大部分数据块仍然存在,第7讲 多媒体网络,从数据丢失中恢复(4),在受话方对受损的音频流进行修复 产生一个类似原始替代数据来替代丢失的分组 重复：对于较小的分组(4-40 ms)和低丢失率可表现出良好的性能,第7讲 多媒体网络,实时协议( Real-Time Protocol,RTP),RTP定义了携带 audio / video数据的分组结构 : RFC 1889. RTP 分组提供 负荷类型

21、定义 分组顺序编号 时间戳,RTP 在端系统中运行 . RTP 分组被封装在UDP数据段中 互操作性（Interoperability）: 如果 两个IP 电话应用程序都运行RTP, 那么它们就有 可能一起工作,第7讲 多媒体网络,RTP 运行在 UDP之上,RTP 库提供了传输层接口来扩展 UDP: 端口号, IP地址 跨段的错误校验 负荷类型标记 分组顺序编号 时间戳,第7讲 多媒体网络,RTP 举例,回顾发送 64 kb/s PCM-编码的语音通过RTP. 应用程序采集已经编码的数据块, e.g., 每20 ms = 160 字节的数据块. 音频 数据块和 RTP首部形成 RTP 分组,

22、 被封装入 UDP数据段.,RTP首部说明每个分组的音频类型; 发送端可以在会议期间改变编码. RTP首部同样包含了顺序号和时间戳.,第7讲 多媒体网络,RTP 和 QoS,RTP 不承诺提供任何实时传递和 服务质量 保证. RTP 封装仅仅可以在端系统 进行 与中间的路由器没有关系. 路由器的作用还是完成传统的尽力而为的服务，而对 RTP分组的传递没有任何实时性促进的作用.,要为应用程序提供 QoS, 因特网必须要提供其他 的机制, 例如 RSVP,为 应用程序预留网络资源.,第7讲 多媒体网络,RTP 媒体流,RTP 允许每个信源 (例如,一台摄像机或一个麦克风)赋以 各自的独立的 RTP

23、分组流. 例如,对有两个参与者的得视讯会议, 要打开4个RTP流: 两个用于传输音频 (一个方向一个) 和两个视频流 (同样, 一个方向一个).,但是, 一些常用的编码技术 包括 MPEG1和 MPEG2 在编码过程中将音频和视频合成一个流媒体. 这种情况下，在每个方向上只需一个 RTP流. 对于一场 many-to-many的组播会话来说, 所有的发送方和信源一般将RTP流依据同样的组播地址送入同一组播树,第7讲 多媒体网络,RTP 首部,Payload Type (7 bits): 说明传输分组的编码类型. 如果在会议过程中发送端改变编码类型，则通过payload type字段通知接受端.

24、 Payload type 0: PCM mu-law, 64 Kbps Payload type 3, GSM, 13 Kbps Payload type 7, LPC, 2.4 Kbps Payload type 26, Motion JPEG Payload type 31. H.261 Payload type 33, MPEG2 videoSequence Number (16 bits): 该序号按所发送的RTP分组递增 ，可用于 测试数据丢失和恢复失序的分组 .,第7讲 多媒体网络,RTP 首部 (2),Timestamp field (32 bytes long). 表示RTP

25、数据分组中首个字节的采样瞬间. 在 接受端 可使用该字段消除抖动和提供同步播出. 该时间戳是由发送端的采样时钟提供的. 例如, 音频的时间戳每个采样周期递增一次 (for example, each 125 usecs for a 8 KHz sampling clock); 如果音频应用程序产生的数据块包括了160 个 已编码采样，在信源激活期间，每个RTP分组的时间戳的增量为160. 只要信源处于激活状态，时间戳时钟就以恒定的速率递增. SSRC field (32 bits long). 定义信源的 RTP流. 在一个RTP会话中，每个流都必须有一个独特的 SSRC.,第7讲 多媒体网络

26、,实时控制协议(Real-Time Control Protocol ,RTCP),与RTP协同工作. 每个在某个RTP会话中的参与者都要周期性的传输RTCP控制分组给所有其它所有的参与者. 每个RTCP分组都包含了发送端和/或接收端的统计报告，对应用层有用 统计数据包括分组发送数量、分组丢失数量、分组到达的间歇抖动等.,这种反馈信息可用于控制应用程序的性能和进行诊断. 发送方可根据反馈信息修改传输参数（The sender may modify its transmissions based on the feedback）.,第7讲 多媒体网络,RTCP (续),- 一般典型的RTP会话都

27、有一个组播(multicast)地址; 所有的RTP 和 RTCP 分组只要同属该会话，就是使用该组播地址. - RTP 和RTCP分组可使用不同的端口号来相互区别. - 为限制数据流量, 当参与者增加时，每各与会者都会减少 RTCP数据的发送.,第7讲 多媒体网络,RTCP 分组,接收端报告分组: 丢包比率, 最后收到的分组,平均间隔的抖动. 发送端报告分组: RTP流中的 SSRC, 当前时间, 已经发送的分组数量, 和发送的字节数量.,信源描述分组: 发送端的e-mail地址,发送端的名称, 相关RTP流的 SSRC . 分组提供了SSRC和用户/主机间的 映射.,第7讲 多媒体网络,流

28、媒体的同步问题,RTCP可以协调同一会话中的不同流的同步. 考虑一下视讯会议，应用程序对视频流和音频流分别产生一个 RTP数据流. 在两个媒体流中都携有时间戳是来自采样时钟，而不是来自墙上的挂钟 (i.e., to real time).,每个RTCP发送端报告分组包括, 在相关RTP流中最近产生的分组中, RTP分组的时间戳和分组创建的真实时间. 这样 RTCP发送端报告分组将采样时钟和真实时间联系在一起. 接收端可以依据这种联系来同步音频和视频播出.,第7讲 多媒体网络,RTCP带宽分配(Bandwidth Scaling),RTCP试图将其占用的带宽 限制在 5%的会话带宽以下. 例如,

29、 假设一个发送端以2 Mb/s速率发送视频数据. 那么RTCP的信息流量限制在 100 Kb/s. 协议规定把其中 75%（ 75 kb/s）的速率留给接收端, 其余的 25% 或 25 kb/s, 给发送端.,分配给接收端的75 kb/s在接收端之间进行平均分配，假设有R 个接收端，每个接收端分得 75/R kb/s而发送端则以25kb/s 发送 RTCP信息 . 一个会话参与者 (一个接收端或一个发送端) 在动态计算平均RTCP分组大小(across the entire session)的基础上确定RTCP分组的传输周期.,第7讲 多媒体网络,H.323,概述 H.323 终端 H. 3

30、23 编码 网守(Gatekeeper) 网关(Gateway) Audio 编码机制 Video 编码机制,第7讲 多媒体网络,概述 (1),在IP网络上进行音频和视频会议的基础 . 定位于实时通信(而不是存储式流媒体) 兼顾 ITU的通信标准. 覆盖的范围: 独立设备 (如：Web 电话，Web 电视) PC应用程序 点对点和多点视讯会议,H.323 定义包括: 终端如何启动/接受呼叫 终端间如何使用通用 audio/video编码 . Audio和video数据如何进行封装和发送. Audio和video如何同步 (lip-sync). 终端如何同各自的网守程序（gatekeeper）通

31、信IP电话如何与 PSTN /ISDN 电话通信.,第7讲 多媒体网络,概述 (2),Telephone calls Video calls Conferences Whiteboards,所有支持 H.323的终端,第7讲 多媒体网络,概述 (3),H.323,SS7, Inband,第7讲 多媒体网络,H.323端接点必须支持:,G.711 - ITU 语音压缩标准 RTP 将媒体数据块封装成分组的协议 H.245 - “带外” 控制协议用于控制H.323终端间的流媒体传输 .,Q.931 用于建立/结束连接的信令协议 RAS (Registration/ Admission/Status

32、) 信道协议 与网守程序进行通信的协议 (如果存在网守-gatekeeper),第7讲 多媒体网络,H.323 终端,第7讲 多媒体网络,H.323 编码,Audio: H.323终端必须支持 G.711 标准进行语音压缩. G.711 以 5664 kb/s的速率传输语音. H.323 正在考虑使用 G.723 = G.723.1, 该标准以 5.36.3 kb/s的速率操作（来支持低速链路）. Optional: G.722, G.728, G.729,Video 对 H.323终端来说，视频能力为可选项. 任何可视化的 H.323终端必须支持 QCIF H.261 (176x144 pi

33、xels). 也可以选择其他的H.261机制: CIF, 4CIF and 16CIF. H.261所使用的信道带宽必须是64 kb/s的整倍数.,第7讲 多媒体网络,产生H.323中的音频数据流,Audio Source,Encoding: e.g., G.711 or G.723.1,RTP packet encapsulation,UDP socket,Internet or Gatekeeper,第7讲 多媒体网络,H.245控制通道,H.323 媒体流可以包含若干信道来传输不同类型的媒体数据 每个H.323会话有一个 H.245 控制信道 H.245 控制信道是 一个可靠的 (TCP

34、) 信道,主要任务: 开闭媒体信道 能力信息交换:在发送流媒体之前,通信终端对它们之间的编码/算法协商一致,第7讲 多媒体网络,信息流,第7讲 多媒体网络,网守(Gatekeeper) 1/2,网守是任选的H.323模块/设备, 可以给端点提供:负责”别名”与IP地址的转换带宽管理: 可以限制实时会议所消耗的带宽作为可选功能, H.323呼叫可以被引导通过网守, 对计费有用.RAS协议 (over TCP)负责端点-网守间的通信,第7讲 多媒体网络,网守(Gatekeeper) 2/2,H.323终端必须在网守的辖区内注册. 当 H.323 应用程序在终端上调用时,该终端使用 RAS 给网守发

35、送其 IP地址和(用户提供的)别名. 如果区内有网守存在, 每个区内的终端必须与网守联系并获取呼叫许可.,一旦获得许可, 终端将给网守发送电子邮件地址、别名字符串或电话分机.网守将别名翻译成 IP 地址 如有必要,网守将轮询其他辖区中的网守以解决IP地址的解析问题.处理过程如同DNS,但具体做法因厂商而异,第7讲 多媒体网络,H.323 网关(Gateway),H.323 terminals,Gatekeeper,Router,Internet,LAN = “H.323 Zone”,RAS,Gateway,PSTN,是IP区和PSTN (or ISDN) 网络之间的桥梁. 终端使用 H.245和 Q.931与网关进行通信,第7讲 多媒体网络,Audio编码机制,MOS (Mean Opinion Score),第7讲 多媒体网络,Video编码机制,H.261 (p x 64 kb/s) ISDN上的视频流 分辨率 : QCIF, CIF H.263 ( 64 kbit/s) 低传输速率通信 分辨率: SQCIF, QCIF, CIF,4CIF, 16CIF,