计算机topdownv3-7

《计算机topdownv3-7》由会员分享，可在线阅读，更多相关《计算机topdownv3-7（112页珍藏版）》请在金锄头文库上搜索。

1、第7章 多媒体联网 Multimedia Networking 计算机网络：自顶向下方法 (原书第三版) 陈鸣译，机械工业出版社，2005年Computer Networking: A Top Down Approach Featuring the Internet, 3rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004. 1多媒体联网多媒体, 服务质量: 概念多媒体应用: 网络音频和视 频(“连续媒体”)网络为应用提供运行应用 所需的性能水平QoS2多媒体联网第7章 目标原则r多媒体应用分类r确定应用程序所需的网络服务r尽

2、可能利用尽力而为服务r提供QoS的机制协议和体系结构r用于尽力而为的特定协议rQoS的体系结构3多媒体联网第7章 要点r7.1 多媒体联网应用程序r7.2 流式存储音频和视频r7.3实时多媒体: 因特网电 话研究r7.4 用于实时交互应用程序 的协议mRTP, RTCP, SIPr7.5 多媒体分发: 内容分发 网络r7.6 超越尽力而为r7.7 调度和监管机制r7.8 综合服务和区分服 务r7.9 RSVP4多媒体联网多媒体网络应用 基本特性:r典型的时延敏感m端到端时延m时延抖动 r但容忍丢包: 不经常的丢 包引起较小的干扰r与数据的特性相对，数据 不能丢失但容忍时延多媒体应用的分类: 1

3、) 流式存储 音频和视频 2) 流式实况音频和视频 3)实时交互音频和视频时延抖动是在相同分组流 中分组时延的变动5多媒体联网流式存储多媒体 流式: r媒体存储在源中r传输到客户机r流式：在所有数据到达前，客户 机播放开始6多媒体联网流式存储多媒体: 概念1.记录 的视频2. 发送的视频3. 收到视频，在客户机 播放累计数据流式: 在此时刻，客户机播放视频的 较早部分，而服务器还在发送视频 的后面部分网络时延时间7多媒体联网流式存储多媒体: 交互性rVCR类似的功能：客户机能够暂停、 倒带、快进、推动滑动条m10 sec初始时延OKm1-2 sec直到命令响应 OKmRTSP经常使用(详情见后

4、)r对仍在传输数据的定时约束：及时播放8多媒体联网流式实况多媒体例子:r因特网无线电谈话节目r实况体育事件 流式r重放缓存r重放能够滞后传输几十秒r仍有定时约束 交互性r不可能快进r倒带、暂停可能！9多媒体联网交互性,实时多媒体 r端到端时延要求:m音频: 64,000 bpsr接收方将它转换回模拟 信号:m某种质量降低 速率例子rCD: 1.411 MbpsrMP3: 96, 128, 160 kbpsr因特网电话: 5.3 - 13 kbps13多媒体联网视频压缩简介r视频是以恒速显示的图 片序列m如 24图片/secr数字图片是像素数组r每个像素由比特表示r冗余m空间的m时间的例子:rM

5、PEG 1 (CD-ROM) 1.5 MbpsrMPEG2 (DVD) 3-6 MbpsrMPEG4 (常用于因特网, Twister 27多媒体联网RTSP操作28多媒体联网RTSP交换例子C: SETUP rtsp:/audio. RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp:/audio. RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp:/audio. RT

6、SP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp:/audio. RTSP/1.0 Session: 4231 S: 200 3 OK29多媒体联网第7章 要点r7.1 多媒体联网应用程序r7.2 流式存储音频和视频rr7.37.3实时多媒体实时多媒体: : 因特网电因特网电 话研究话研究r7.4 用于实时交互应用程序 的协议mRTP, RTCP, SIPr7.5 多媒体分发: 内容分发 网络r7.6 超越尽力而为r7.7 调度和监管机制r7.8 综合服务和区分服 务r7.9 RSVP30多媒体联网实时交互应用程序rPC到PC电话m即时讯

7、息服务提供该业 务rPC到phonemDialpadmNet2phoner既有Web摄像的视频会 议现在就去研究PC到 PC 的因特网电话的 详细例子31多媒体联网InternetCDIP 电话网关IP 电话网关公用电话网BA电路交换电路交换电路交换分组交换分组交换32多媒体联网IPIP 电话的原理电话的原理话音编码话音编码装成分组装成分组分组缓存分组缓存话音解码话音解码InternetInternet33多媒体联网交互多媒体: 因特网电话通过一个例子介绍因特网电话r讲话者的语音：交互的语涌, 静默期.m在语涌期间64 kbpsr仅在语涌期产生分组m以8 Kbytes/sec速率的20 mse

8、c 块 : 160 字节数据r在每块上加上应用层首部r块+首部封装在UDP段中r在语涌期应用程序每20msec向套接字发送UDP段34多媒体联网因特网电话: 分组丢失和时延r网络丢包: 由于网络拥塞的IP数据报丢失 (路 由器缓存溢出)r时延丢包: 在接收方，IP数据报到达太迟而无 法播放m时延: 网络中的处理、排队; 端系统(发送方，拒) 时延m典型的最大可容忍时延: 400 msr丢包容忍: 取决于语音编码，差错隐藏丢失， 丢包率在1% 和10%之间可以容忍35多媒体联网时延抖动r考虑两个连续分组的端到端时延：差异能大于或小于 20 msec恒定比特率 视频传输累积数据时间可变的 网络时延

9、 时延抖动客户机 接收视频客户机以恒定比特率播放客户机播放时 延缓存的视频36多媒体联网因特网电话: 固定播放时延r接收方试图在块生成后的q msec来播放每个块m块具有时戳t: 在t+q播放块m在t+q后块到达: 数据到达太迟而不能播放 ，数据“丢失”rQ的折衷:m大q: 分组丢失少m小q: 更好的交互体验37多媒体联网固定播放时延 发送方在语涌期每20 msec产生分组 第一个分组在时间r收到 第一个播放进度：在p开始 第二个播放进度：在p开始packets时间分组产生分组收到丢包rpp播放进度 p - r播放进度 p - r38多媒体联网自适应播放时延, I在接收方平均时延的动态估计其中

10、u是一个固定常数 (如 u = 0.01).r目的：最小化播放时延，使后面的丢包率低r方法：播放时延适应性调整:m在每个语涌的开始时，估计网络时延，调整播放时延m静默期压缩和伸长m语涌期每20 msec仍播放39多媒体联网自适应播放时延II估计时延的平均偏差vi也是有用的:每收到分组计算di 和vi 的估计值，尽管它们仅用于一个语涌的 开始。对语涌中的第一个分组，播放时间是 :其中K是一个正常数 在语涌中的剩余分组定时地播放40多媒体联网自适应播放时延, III问题: 接收方怎样决定分组是否是一个语涌中的 第一个？r如果无丢包，接收方看到连续的时戳m连续时戳的差异 20 msec 语涌开始.r

11、由于可能丢包，接收方必须看时戳和序号m联系时戳的差异 20 msec 和 没有间隙的序号 语 涌 开始.41多媒体联网丢包恢复(1)前向纠错(FEC): 简单的方案r对每组n个块生成一个冗余 块，通过异或这n个初始块r发送n+1块, 增加了1/n 的 带宽r如果对这n+1块至多丢失 一个块，能够重构初始n块r播放时延需要固定为接 收所有n+1分组的时间r折衷：m增加n，浪费较少的 带宽m增加n，较长的播放 时延m增加n，2个或更多块 丢失的概率增加42多媒体联网丢包恢复(2)2nd FEC方案 “载答较低质量流” 发送较低分辨率的音频 流作为冗余信息 例子： 64 kbps PCM 额定流和1

12、3 kbps GSM 冗余流 无论何时有非连续丢包，接收方能够隐藏该丢包 也能够附加第 (n-1) 和 (n-2)低比特率块43多媒体联网丢包恢复(3)交叉r块分成较小的单元r例子：每块4 5 msec 单元r分组包括来自不同块的小单元r如果分组丢失，仍有每个块 的大部分r没有冗余开销r但增加了播放时延44多媒体联网小结: 因特网多媒体: 技巧r对时间敏感的流量使用UDP 以避免TCP拥塞控制r客户机侧自适应播放时延：补偿时延r服务器侧为可用的客户机到服务器路径带宽匹配流带 宽m在每个编码流速率中选择m动态的服务器编码速率r差错恢复 (在UDP之上)mFEC, 交叉m重传，时间允许m隐藏差错：

13、重复临近数据45多媒体联网第7章 要点r7.1 多媒体联网应用程序r7.2 流式存储音频和视频r7.3实时多媒体: 因特网电 话研究rr7.4 7.4 用于实时交互应用程序用于实时交互应用程序 的协议的协议mmRTP, RTCP, SIPRTP, RTCP, SIPr7.5 多媒体分发: 内容分发 网络r7.6 超越尽力而为r7.7 调度和监管机制r7.8 综合服务和区分服 务r7.9 RSVP46多媒体联网实时协议(RTP)rRTP定义了承载音频和 视频数据的分组结构rRFC 1889.rRTP分组提供了m载荷类型标识m分组序号m时戳rRTP运行在端系统上rRTP分组封装在UDP段 中r交互

14、能力: 如果两个因特 网电话应用程序运行 RTP, 则它们能够在一起 工作47多媒体联网RTP运行在UDP之上RTP库提供了扩展UDP的运输层接口 : 端口号 IP地址 载荷类型标识 分组序号 时戳 UDPRTP48多媒体联网RTP例子r考虑经RTP发送64 kbps PCM编码语音r应用程序在块中收集编 码数据 ，如每20 msec = 一个块中的160 字节 r该音频块连同RTP首部 形成了RTP分组，它被 封装在UDP段中rRTP首部指示了在每个 分组中的音频编码类型m 发送方能够在一个会议 中改变编码rRTP首部也包含序号和 时戳49多媒体联网RTP和QoSrRTP不 提供确保数据定时

15、交付的任何机制或 提供服务质量保证 rRTP封装仅在端系统可见：而不被中间路由器 所见m提供尽力而为服务的路由器并不做任何特殊努力 ，以确保RTP分组以定时的方式到达目的地50多媒体联网RTP首部载荷类型(7 bits): 指出当前正被使用的编码类型。如果发送方在会议 中间改变编码，发送方通过该负载类型字段通知接收方载荷类型0: PCM mu-law, 64 kbps 载荷类型3, GSM, 13 kbps 载荷类型7, LPC, 2.4 kbps 载荷类型26, Motion JPEG 载荷类型31. H.261 载荷类型33, MPEG2 video序号 (16 bits): 对每个发送的

16、RTP分组增加, 能够用于检测丢包和恢复 分组顺序51多媒体联网RTP Header (2)r时戳字段 (32 比特长). 反映在RTP数据分组中的第一个字节的取 样时刻. m对音频，对每个取样周期，时戳时钟通常增加 (例如，对8 KHz取样时钟，每125 s为一种取样时钟) m如果应用程序生成160个 编码样本的块，当源是活跃的时， 对每个RTP时戳增加160。当源非活动时，时戳时钟继续以 恒定速率增加。rSSRC字段 (32 比特长). 标识RTP流的源。在RTP会话中的每个 流应当具有一个独特的SSRC. 52多媒体联网RTSP/RTP 编程作业r构建一个服务器，已将存储视频封装在RTP分组中m获取视频帧，加上RTP首部，生成UD