第7讲多媒体网络.ppt

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

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

2、continuous media）/流媒体”,多媒体应用的分类:存储式的 audio/video流媒体直播式的audio/video流媒体实时交互式的audio/video,第7讲 多媒体网络,网络中的多媒体(2),存储式流媒体客户端从服务器请求audio/video文件，以流水方式从网络上进行接收并显示交互:用户可进行操作(如同操作录像机:暂停,恢复播放,快进,回退,etc.)延迟:从客户端发出请求到开始播出为110秒,实况转播（单向实时）:如同 TV 和无线广播,但是从因特网上传送非交互,只是收视/收听实时交互:电话或视频会议由于实时特性，比流媒体点播和实况转播要求更为严格Video:15

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

4、组完全一样.目前对在因特网中提供区别对待的服务的研究一直在进行之中.,第7讲 多媒体网络,网络中的多媒体(4):将尽力而为的服务用到极致,为减少“尽力而为”的因特网的服务原则的影响，我们可以:使用UDP来避免TCP和它的慢启动过程在客户端缓存部分内容和控制回放来弥补传输抖动造成的影响我们可以给分组加上时间戳来提醒接收端及时回放该分组.选择压缩等级来适配可用带宽,我们还可以发送冗余的分组来减少分组丢失所造成的影响。我们将讨论这些“雕虫小技”,第7讲 多媒体网络,因特网应如何进化才能更好的支持多媒体?,集成服务（Intserv）的哲学:改变因特网协议以便应用程序能够预定端对端的带宽需要部署协议来预

5、留带宽必须修改路由器的调度策略来响应带宽预留应用程序必须体为网络提供信息流量的描述,并进而遵循这样的描述.在主机和路由器中开发新的更复杂的软件,区别服务（Diffserv）的哲学:对因特网的基础结构进行改造,使其可以提供分级的服务.分组要加标记用户为高级别的服务付出更多的费用.ISP为骨干网络收发高级别的分组付出更多的费用.,第7讲 多媒体网络,因特网应如何进化才能更好的支持多媒体?(续),自由放任(Laissez-faire)哲学 没有带宽预定,不搞分组标记只要需求增加,供应更多的带宽将存储内容置于网络的边缘:ISP和主干上增加缓存内容提供商将内容置于 CDN 结点P2P:选择临近的存储有内

6、容的对等结点,虚拟专网(VPN)为企业保留永久性的带宽域(blocks of bandwidth）.路由器可以根据IP 地址来识别VPN的信息流路由器使用特殊的调度策略来提供预留的带宽.,第7讲 多媒体网络,存储式Audio&Video流,存储式流媒体:Audio/video 文件存储在服务器上用户根据需求调用audio/video 文件.Audio/video 在请求的10秒以内提供.提供交互性(暂停,重新定位等,etc.).,媒体播放器（Media player）:消除抖动解压缩错误校正提供图形交互界面进行控制 可以使用插件（Plug-in）将媒体播放器植入浏览器窗口.,第7讲 多媒体网络

7、,从Web服务器调用流媒体(1),Audio和 video文件存储在 Web服务器上最原始的方法浏览器使用HTTP请求报文从Web服务器访问流媒体文件Web服务器用HTTP响应报文发送文件content-type 首部行描述了 audio/video的编码浏览器启动媒体播放器,并将文件传递给它媒体播放器解读该文件,主要缺点:媒体播放器通过浏览器作为中介与Web 服务器交互,第7讲 多媒体网络,从Web服务器调用流媒体(2),改进:在服务器和播放器之间建立连接浏览器请求和接收元文件（meta file）(用来描述对象的文件）而不是接收文件本身);Content-type首部说明是特定的audio

8、/video应用浏览器启动媒体播放器并将元文件传递给它 播放器与服务器建立TCP 连接并发送 HTTP请求.,问题讨论:媒体播放器使用HTTP通信,没有 pause,ff,rwnd 功能可以考虑使用 UDP通信,第7讲 多媒体网络,从流媒体服务器调用流媒体,该结构可以使用非HTTP协议进行通信在服务器和流媒体播放器之间进行通信 可以使用UDP来替代 TCP.,第7讲 多媒体网络,实时流媒体协议（Real Time Streaming Protocol）:RTSP,HTTP HTTP所服务的媒体已经定型:HTML,images,applets,etc.HTTP 的设计没有考虑流媒体(i.e.,a

9、udio,video,etc.)RTSP:RFC 2326客户端-服务器应用层协议.可为用户提供播出控制:rewind,fast forward,pause,resume,repositioning,etc,它所不能做到的:没有流媒体传递过程中的audio/video数据的封装不限制流媒体的传递方式;既可以用 UDP也可以用TCP没有定义流媒体播放器如何对 audio/video数据进行缓存RealNetworks服务器和播放器使用RTSP 互相向对方发送控制信息,第7讲 多媒体网络,RTSP:带外控制-out of band control,FTP 使用了“带外”的控制通道:文件传输通过一个

10、通道控制信息(cd,rm,mv,etc.)则通过分离的TCP连接发送.“带外”和“带内”通道使用不同的端口号.,RTSP 报文也使用带外通道传送:RTSP控制报文使用的端口号与媒体流使用的不同，所以是带外传递.流媒体的分组结构不是由RTPS定义的，因此被认为是在“带内”传输的.如果RTSP报文使用与流媒体相同的端口号，RTSP将与流媒体一起“间隔”传送.,第7讲 多媒体网络,RTSP 启动和控制传递,首先客户端获取多媒体的表示方式描述,这可以由若干媒体流组成.浏览器个根据表示方式所描述的内容类型调用媒体播放器(辅助的应用程序-helper application).表示描述中使用URL方法 r

11、tsp:/将媒体流包含在内播放器发送 RTSP SETUP请求;服务器发送 RTSP SETUP响应.播放器发送 RTSP PLAY 请求;服务器发送 RTSP PLAY 响应.媒体服务器“泵出”流媒体.播放器发送 RTSP PAUSE请求;服务器发送 RTSP PAUSE响应.播放器发送 RTSP TEARDOWN请求;服务器发送 RTSP TEARDOWN响应.,第7讲 多媒体网络,元文件举例,Twister,第7讲 多媒体网络,RTSP会话,每次RTSP 都会有由服务器选择的会话定义符.当客户端用SETUP请求启动会话，服务器就会使用定义符来进行响应.在随后的过程中，客户端反复在每个请求

12、中都使用该定义符,直到客户端使用 TEARDOWN请求来结束会话.,RTSP 端口号为 554.RTSP 报文可以通过 UDP或TCP发送.每个 RTSP 报文可以通过一个分离的TCP 连接进行.,第7讲 多媒体网络,RTSP:交换实例,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 Sessi

13、on:4231 Range:npt=37 C:TEARDOWN rtsp:/RTSP/1.0 Session:4231 S:200 3 OK,第7讲 多媒体网络,RTSP:流媒体的缓存,对RTSP响应报文的缓存没有太大的意义.但希望将媒体流缓存在客户端的邻近处.大部分 HTTP/1.1的缓存控制机制也被RTSP采用.缓存的控制首部可以用于RTSP SETUP 请求和相应:If-modified-since:,Expires:,Via:,Cache-Control:,对给定的流媒体来说代理缓存只能按数据段的形式保持.代理缓存可以从本地缓存 中取出部分数据进行服务,而然后必须同原始服务器连接来填充

14、部分丢失的资料,但愿不要在客户端造成传输中断.从原始服务器传回的流媒体将通过代理传到客户端,代理可以使用TCP来获取流媒体;但代理服务器还是把RTSP控制报文发给了原始服务器.,第7讲 多媒体网络,实时交互式应用,PC-2-PC phonePC-2-phoneDialpadNet2phone视频会议Webcams,现在来研究PC-2-PC IP 电话的案例,第7讲 多媒体网络,使用“尽力而为服务”的IP电话(1),Best effort modelpacket delay,loss and jitterIP 电话举例现在对分组延迟、丢失、和抖动对电话内容所造成的影响进行分析.IP 电话应用程序

15、在对话期间产生分组谈话期间的数据产生的速率为64 kb/s,在交谈期间,每 20 ms应用程序将产生160字节(8 kB/s*20 ms)的数据块数据块加上首部;然后封装入UDP分组并发送某些分组的丢失和延迟会给传输造成“起伏(fluctuate)”.受话方必须确定何时将数据块进行播放，如何处理缺失的数据块,第7讲 多媒体网络,IP 电话(2),分组丢失UDP 段封装在 IP 分组中分组在路由器队列中可能溢出TCP 虽然可以消除数据丢失,但是重发会增加延迟TCP 的拥塞控制会降低速率增加冗余分组会有帮助端对端的延迟为发送、传播、排队延迟的总和,端对端的延迟一旦超过400 ms将严重影响交互性;

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

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

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

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

20、端系统中运行.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 分组,被封装入 UDP数据段.,RTP首部说明每个分组的音频类型;发送端可以

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

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

23、psPayload type 7,LPC,2.4 KbpsPayload type 26,Motion JPEGPayload type 31.H.261Payload type 33,MPEG2 videoSequence Number(16 bits):该序号按所发送的RTP分组递增，可用于测试数据丢失和恢复失序的分组.,第7讲 多媒体网络,RTP 首部(2),Timestamp field(32 bytes long).表示RTP数据分组中首个字节的采样瞬间.在 接受端 可使用该字段消除抖动和提供同步播出.该时间戳是由发送端的采样时钟提供的.例如,音频的时间戳每个采样周期递增一次(for

24、 example,each 125 usecs for a 8 KHz sampling clock);如果音频应用程序产生的数据块包括了160 个 已编码采样，在信源激活期间，每个RTP分组的时间戳的增量为160.只要信源处于激活状态，时间戳时钟就以恒定的速率递增.SSRC field(32 bits long).定义信源的 RTP流.在一个RTP会话中，每个流都必须有一个独特的 SSRC.,第7讲 多媒体网络,实时控制协议(Real-Time Control Protocol,RTCP),与RTP协同工作.每个在某个RTP会话中的参与者都要周期性的传输RTCP控制分组给所有其它所有的参与者

25、.每个RTCP分组都包含了发送端和/或接收端的统计报告，对应用层有用 统计数据包括分组发送数量、分组丢失数量、分组到达的间歇抖动等.,这种反馈信息可用于控制应用程序的性能和进行诊断.发送方可根据反馈信息修改传输参数（The sender may modify its transmissions based on the feedback）.,第7讲 多媒体网络,RTCP(续),-一般典型的RTP会话都有一个组播(multicast)地址;所有的RTP 和 RTCP 分组只要同属该会话，就是使用该组播地址.-RTP 和RTCP分组可使用不同的端口号来相互区别.-为限制数据流量,当参与者增加时，每

26、各与会者都会减少 RTCP数据的发送.,第7讲 多媒体网络,RTCP 分组,接收端报告分组:丢包比率,最后收到的分组,平均间隔的抖动.发送端报告分组:RTP流中的 SSRC,当前时间,已经发送的分组数量,和发送的字节数量.,信源描述分组:发送端的e-mail地址,发送端的名称,相关RTP流的 SSRC.分组提供了SSRC和用户/主机间的 映射.,第7讲 多媒体网络,流媒体的同步问题,RTCP可以协调同一会话中的不同流的同步.考虑一下视讯会议，应用程序对视频流和音频流分别产生一个 RTP数据流.在两个媒体流中都携有时间戳是来自采样时钟，而不是来自墙上的挂钟(i.e.,to real time).

27、,每个RTCP发送端报告分组包括,在相关RTP流中最近产生的分组中,RTP分组的时间戳和分组创建的真实时间.这样 RTCP发送端报告分组将采样时钟和真实时间联系在一起.接收端可以依据这种联系来同步音频和视频播出.,第7讲 多媒体网络,RTCP带宽分配(Bandwidth Scaling),RTCP试图将其占用的带宽 限制在 5%的会话带宽以下.例如,假设一个发送端以2 Mb/s速率发送视频数据.那么RTCP的信息流量限制在 100 Kb/s.协议规定把其中 75%（75 kb/s）的速率留给接收端,其余的 25%或 25 kb/s,给发送端.,分配给接收端的75 kb/s在接收端之间进行平均分

28、配，假设有R 个接收端，每个接收端分得 75/R kb/s而发送端则以25kb/s 发送 RTCP信息.一个会话参与者(一个接收端或一个发送端)在动态计算平均RTCP分组大小(across the entire session)的基础上确定RTCP分组的传输周期.,第7讲 多媒体网络,H.323,概述H.323 终端H.323 编码网守(Gatekeeper)网关(Gateway)Audio 编码机制Video 编码机制,第7讲 多媒体网络,概述(1),在IP网络上进行音频和视频会议的基础.定位于实时通信(而不是存储式流媒体)兼顾 ITU的通信标准.覆盖的范围:独立设备(如：Web 电话，We

29、b 电视)PC应用程序点对点和多点视讯会议,H.323 定义包括:终端如何启动/接受呼叫终端间如何使用通用 audio/video编码.Audio和video数据如何进行封装和发送.Audio和video如何同步(lip-sync).终端如何同各自的网守程序（gatekeeper）通信 IP电话如何与 PSTN/ISDN 电话通信.,第7讲 多媒体网络,概述(2),Telephone callsVideo callsConferencesWhiteboards,所有支持 H.323的终端,第7讲 多媒体网络,概述(3),H.323,SS7,Inband,第7讲 多媒体网络,H.323端接点必须

30、支持:,G.711-ITU 语音压缩标准RTP 将媒体数据块封装成分组的协议H.245-“带外”控制协议用于控制H.323终端间的流媒体传输.,Q.931 用于建立/结束连接的信令协议RAS(Registration/Admission/Status)信道协议 与网守程序进行通信的协议(如果存在网守-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

31、/s的速率操作（来支持低速链路）.Optional:G.722,G.728,G.729,Video对 H.323终端来说，视频能力为可选项.任何可视化的 H.323终端必须支持 QCIF H.261(176x144 pixels).也可以选择其他的H.261机制:CIF,4CIF and 16CIF.H.261所使用的信道带宽必须是64 kb/s的整倍数.,第7讲 多媒体网络,产生H.323中的音频数据流,AudioSource,Encoding:e.g.,G.711 or G.723.1,RTP packetencapsulation,UDP socket,Internet orGateke

32、eper,第7讲 多媒体网络,H.245控制通道,H.323 媒体流可以包含若干信道来传输不同类型的媒体数据每个H.323会话有一个 H.245 控制信道H.245 控制信道是 一个可靠的(TCP)信道,主要任务:开闭媒体信道能力信息交换:在发送流媒体之前,通信终端对它们之间的编码/算法协商一致,第7讲 多媒体网络,信息流,第7讲 多媒体网络,网守(Gatekeeper)1/2,网守是任选的H.323模块/设备,可以给端点提供:负责”别名”与IP地址的转换 带宽管理:可以限制实时会议所消耗的带宽 作为可选功能,H.323呼叫可以被引导通过网守,对计费有用.RAS协议(over TCP)负责端点

33、-网守间的通信,第7讲 多媒体网络,网守(Gatekeeper)2/2,H.323终端必须在网守的辖区内注册.当 H.323 应用程序在终端上调用时,该终端使用 RAS 给网守发送其 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,CIFH.263(64 kbit/s)低传输速率通信分辨率:SQCIF,QCIF,CIF,4CIF,16CIF,