《第12讲-多媒体传输协议》由会员分享，可在线阅读，更多相关《第12讲-多媒体传输协议（95页珍藏版）》请在金锄头文库上搜索。
1、1,第12讲 多媒体传输协议,要求 1. 理解网络多媒体传输的基本问题和基本解决方法 2. 理解流式音频视频的基本原理 3. 理解交互式音频视频的基本原理 4. 了解多媒体传输协议RTSP、RTP和RTCP,2,12.1 概述,计算机网络最初是为传送数据信息设计的 因特网IP层提供的“尽最大努力交付”服务，以及每一个分组独立交付的策略，对传送数据信息也是很合适的 因特网使用的TCP协议可以很好地解决网络不能提供可靠交付这一问题,3,多媒体信息的特点,多媒体信息（包括声音和图像信息）与不包括声音和图像的数据信息有很大的区别 多媒体信息的信息量往往很大 在传输多媒体数据时，对时延和时延抖动均有较高
2、的要求 多媒体数据往往是实时数据(real time data)，它的含义是：在发送实时数据的同时，在接收端边接收边播放,4,因特网是非等时的,模拟的多媒体信号经过采样和模数转换变为数字信号，再组装成分组 这些分组的发送速率是恒定的（等时的） 传统的因特网本身是非等时的 因此经过因特网的分组变成了非恒定速率的分组,5,接收端需设置适当大小的缓存 当缓存中的分组数达到一定的数量后再以恒定速率按顺序把分组读出进行还原播放 缓存实际上就是一个先进先出的队列。图中标明的T 叫做播放时延,在接收端设置缓存,6,缓存使所有到达的分组都经受了迟延 早到达的分组在缓存中停留的时间较长，而晚到达的分组在缓存中停
3、留的时间则较短 以非恒定速率到达的分组，经过缓存后再以恒定速率读出，就能够在一定程度上消除了时延的抖动 但，付出的代价是：增加了时延,缓存的影响,7,8,需要解决的问题,在传送时延敏感(delay sensitive)的实时数据时，不仅传输时延不能太大，而且时延抖动也必须受到限制 对于传送实时数据，很少量分组的丢失对播放效果的影响并不大（因为这是由人来进行主观评价的），因而是可以容忍的。丢失容忍(loss tolerant)也是实时数据的另一个重要特点,9,需要解决的问题,由于分组的到达可能不按序，但将分组还原和播放时又应当是按序的 因此在发送多媒体分组时还应当给每一个分组加上序号。这表明还应
4、当有相应的协议支持才行 要使接收端能够将节目中本来就存在的正常的短时间停顿（如音乐中停顿几拍）和因某些分组的较大迟延造成的“停顿”区分开来 这就需要增加一个时间戳(timestamp)，以便告诉接收端应当在什么时间播放哪个分组,10,是否改造现有的因特网？,1、大量使用光缆和高速路由器，网络的时延和时延抖动就可以足够小，在因特网上传送实时数据就不会有问题 2、把因特网改造为能够对端到端的带宽实现预留(reservation)，把使用无连接协议的因特网转变为面向连接的网络 3、部分改动因特网的协议栈所付出的代价较小，而这也能够使多媒体信息在因特网上的传输质量得到改进,11,目前因特网提供的音频/
5、视频服务大体上可分为三种类型,流式(streaming)存储音频/视频 边下载边播放 流式实况音频/视频 边录制边发送 交互式音频/视频实时交互式通信,12,目前因特网提供的音频/视频服务大体上可分为三种类型,流式(streaming)存储音频/视频 边下载边播放 在这类应用中，客户机根据需求请求存储在服务器上的被压缩的音频或视频文件 目前数以千计的场点提供流式存数音频和视频，包括CNN和Youtube等 流式实况音频/视频 边录制边发送 交互式音频/视频实时交互式通信,13,目前因特网提供的音频/视频服务大体上可分为三种类型,流式(streaming)存储音频/视频 边下载边播放 流式实况音
6、频/视频 边录制边发送 这类应用类似于传统的电台广播和电视，只是它通过因特网来传输而已 这些应用允许用户接收从世界任何角落发出的实况无线电广播和电视传输 交互式音频/视频实时交互式通信,14,目前因特网提供的音频/视频服务大体上可分为三种类型,流式(streaming)存储音频/视频 边下载边播放 流式实况音频/视频 边录制边发送 交互式音频/视频实时交互式通信 这类应用允许人们使用音频/视频互相实时通信 因特网上的实时交互音频通常称为因特网电话(Internet telephony)，因为从用户角度来看，它类似于传统的电路交换电话服务,15,“边下载边播放”中的“下载”,“边下载边播放”结束
7、后，在用户的硬盘上没有留下有关播放内容的任何痕迹 流媒体(streaming media)，即流式音频/视频 流媒体特点就是“边下载边播放” (streaming and playing),16,12.2 流式存储音频/视频,传统的下载文件方法,万维网 服务器,客户机,服务器,媒体 播放器,浏览器,17,传统的浏览器从服务器下载音频/视频文件, 用户从客户机(client)的浏览器上用HTTP协议向服务器请求下载某个音频/视频文件 服务器如有此文件就发送给浏览器。在响应报文中就装有用户所要的音频/视频文件。整个下载过程可能会花费很长的时间 当浏览器完全收下这个文件后，就可以传送给自己机器上的媒
8、体播放器进行解压缩，然后播放,18,12.2.1 具有元文件的万维网服务器,元文件就是一种非常小的文件，它描述或指明其他文件的一些重要信息,万维网 服务器,客户机,服务器,媒体 播放器,浏览器,19,使用元文件下载音频/视频文件, 浏览器用户使用HTTP的GET报文接入到万维网服务器，这个超链接指向一个元文件，这个元文件有实际的音频/视频文件的统一资源定位符URL 万维网服务器把该元文件装入HTTP响应报文的主体，发回给浏览器 客户机浏览器调用相关的媒体播放器，把提取出的元文件传送给媒体播放器 媒体播放器使用元文件中的URL，向万维网服务器发送HTTP请求报文，要求下载音频/视频文件 万维网服
9、务器发送HTTP响应报文，把该音频/视频文件发送给媒体播放器。媒体播放器边下载边解压缩边播放,20,12.2.2 媒体服务器,媒体服务器也称为流式服务器(streaming server) ，它支持流式音频和视频的传送 媒体播放器与媒体服务器的关系是客户与服务器的关系 媒体播放器不是向万维网服务器而是向媒体服务器请求音频/视频文件 媒体服务器和媒体播放器之间采用另外的协议进行交互,21,使用媒体服务器,万维网 服务器,媒体 播放器,浏览器,媒体 服务器,客户机,服务器,22,采用媒体服务器下载音频/视频文件的步骤, 前三个步骤仍然和上一节的一样，区别就是后面两个步骤 媒体播放器使用元文件中的U
10、RL接入到媒体服务器，请求下载浏览器所请求的音频/视频文件。下载可以借助于使用UDP的任何协议，例如使用实时传输协议RTP 媒体服务器给出响应，把该音频/视频文件发送给媒体播放器。媒体播放器在迟延了若干秒后，以流的形式边下载边解压缩边播放,23,12.2.3 实时流式协议RTSP(Real-Time Streaming Protocol),RTSP协议以客户/服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：暂停/继续、后退、前进等 因此RTSP又称为“因特网录像机遥控协议” 要实现RTSP的控制功能，不仅要有协议，而且要有专门的媒体播放器(
11、media player)和媒体服务器(media server),24,RTSP简介,RTSP协议是由RealNetworks(音频/视频流领域的业界领袖之一)和Netcape共同提出的 RTSP协议是一个流媒体协议，用于视频点播、视频会议、视频监控等领域 知名端口：554 RTSP语法是基于文本的，类似HTTP协议 RTSP中的所有操作都是通过服务器和客户端的消息应答来完成的，其消息包括请求(Request)和响应(Response)两种,25,RTSP不能做什么,RTSP没有定义用于音频和视频的压缩方案 RTSP没有定义音频和视频在网络传输中是怎样封装在分组中的 流式媒体的封装可以通过R
12、TP或专用协议来提供 RTSP不限制流式媒体如何传输，它可以在UDP或TCP上传输 RTSP不限制媒体播放器如何缓冲音频/视频 音频/视频可能在它一到达客户机就开始播放，也可能在延迟几秒后播放，或者完全下载下来再播放,26,RTSP特点,RTSP允许媒体播放器控制媒体流传输 暂停/继续、播放重定位、快进和快退等 RTSP信道在很多方面和FTP的控制信道类似 RTSP本身并不传送数据，而仅仅是使媒体播放器能够控制多媒体流的传送 RTSP是一个带外协议(out-of-band protocol) RTSP报文在带外发送，而媒体流的分组结构没有被RTSP定义，它被认为是“带内”的 RTSP报文和媒体
13、流使用不同的端口号,27,RTSP消息格式,RTSP的消息有两大类： 请求消息 回应消息 请求消息： 方法 URI RTSP版本 CR LF 消息头 CR LF CR LF 消息体 CR LF,28,RTSP消息格式,说明 方法即可用的命令，如： OPTIONS：客户端用于得到服务器提供的可用方法 DESCRIBE：客户端用于得到会话描述信息(SDP) SETUP：客户端提醒服务器建立会话，并确定传输模式 PLAY：客户端发送播放请求 TEARDOWN：客户端发起关闭请求 URI是接受方的地址，如：rtsp:/192.168.20.136 RTSP版本一般都是 RTSP/1.0 每行后面的CR
14、 LF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CR LF,29,RTSP消息格式,回应消息： RTSP版本 状态码 解释 CR LF 消息头 CR LF CR LF 消息体 CR LF 说明 RTSP版本一般都是RTSP/1.0 状态码是一个数值 200表示成功 解释是与状态码对应的文本解释,万维网 服务器,客户机,服务器,媒体 播放器,浏览器,媒体 服务器,音频/视频流,30,31,使用RTSP的媒体服务器的工作过程, 浏览器向万维网服务器请求音频/视频文件 万维网服务器从浏览器发送携带有元文件的响应 浏览器把收到的元文件传送给媒体播放器 RTSP客户与媒体服务器的RT
15、SP服务器建立连接 RTSP服务器发送响应RESPONSE报文 RTSP客户发送PLAY报文，开始下载音频/视频文件 RTSP服务器发送响应RESPONSE报文 RTSP客户发送TEARDOWN报文断开连接 RTSP服务器发送响应RESPONSE报文,32,RTSP交互示例,C S SETUP rtsp:/115.182.51.79/zuoyou001.mp4/trackID=65537 RTSP/1.0 CSeq: 5 User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25) Transport: RTP/AVP/TCP;
16、unicast;interleaved=2-3 Session: 1837199341906602386,33,RTSP交互示例,S C RTSP/1.0 200 OK Server: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; ) Cseq: 5 Session: 1837199341906602386 Last-Modified: Thu, 17 Jan 2002 11:20:30 GMT Cache-Control: must-revalidate Date: Wed, 04 Jan 2012 06:14:53 GMT Expires: Wed, 04 Jan 2012 06:14:53 GMT Transport: RTP/AVP/TCP;unicast;interleaved=2-3;ssrc=5B56A405,34,RTSP交互示例,C S PLAY rtsp:/115.182.51.79/zuoyou001.
