流媒体技术简述

pwestly

1、              缩略词
3GPP            3rd Generation Partnership Project
CODEC              Coder and Decoder
DRM            Digital Right Management
DSS              Darwin Streaming Server
FW               Fire Wall
HTTP           Hyper Text Transport Protocol
MMS            Microsoft Media Server protocol
Mbone          Multicast Backbone
NAT             Network Address Translate
NPT              Normal Play Time
PKI                     Public Key Infrastructure
RTSP            Real Time Streaming Protocol
RTP              Real-time Transport Protocol
RTCP           Real-time Transport Control Protocol
SDP              Session Description Protocol
TCP              Transport Control Protocol
UDP             User Datagram Protocol

2、              参考文档
《End-to-end transparent streaming service: General description》 3GPP TS 26.233 version 7.0.0 Release 7
《Key Management Extensions for Session Description Protocol(SDP) and Real Time Streaming Protocol(RTSP)》 RFC4567
《QTSS/DSS Administrator’s Guide》
《Real Time Streaming Protocol(RTSP)》 RFC2326
《RTP: A Transport Protocol for Real-Time Applications》 RFC3550
《SDP: Session Description Protocol》 RFC4566
《Transparent end-to-end Packet-switched Streaming Service(PSS): Protocols and codecs》 3GPP TS 26.234 version 6.11.0 Release 6

4、              场景描述
4.1 流媒体定义
流媒体是从服务器到客户端通过网络实时传送并回放连续多媒体数据的一种方式。其中，传送是端到端的，发送方为服务器，接收并回放方为客户端。传送网络现基于IP网。连续多媒体数据是指接收端的数据跟发送端源数据具有相同的时序性，也就是说接收端需要根据时间属性重组接收到的多媒体数据。连续多媒体数据根据时序紧密性可分为实时互动和流式回放两种，前者对传输网络（包括带宽，可靠性等）的要求更高。

4.2 流媒体特性
从流媒体的定义可以看出，与HTTP下载多媒体文件到本地硬盘，然后回放的方式不同，用户无需等待整个流媒体文件下载到硬盘，客户端接收到数据就可以实时回放，就是所谓的“边下载边播放”。这样省却了等待时间，极大的改善了用户体验。但是这也带来了显著的缺点，就是网络情况比较差或者不稳定时，会影响多媒体文件回放的质量。

4.3 用例描述
一个简单的流媒体服务包括媒体流控制、媒体流传输、媒体流编解码和媒体流内容描述发布。
如上图所示，流媒体的内容（包括内容简介，RTSP URL等）通常是通过网页服务器发布，用户在浏览网页内容的时候就可以根据自己感兴趣的内容进行点击，客户端在通过HTTP获取到流媒体信息后，就可以通过发起RTSP跟流媒体服务器进行交互实现媒体流的发起和控制，同时RTSP附带SDP描述媒体流的编解码等信息。RTSP交互成功后，媒体流通过RTP进行传输，RTCP反馈传输的状态信息。

4.4 广播和点播
流媒体根据传输选项可以分为两类：广播和点播。
广播流：不同的客户端无论什么时候加入流，他们看到的都是同样的流内容，就如看电视节目或者收听广播电台。
点播流：每个客户端都会初始化并建立自己的流，不会像广播流那样因为加入流的时间晚而错失部分流的内容。

4.5 多播和单播
在多播中，一个媒体流是在多个客户端之间共享的，流媒体服务器不需要为每一个加入流的客户端单独建立一个媒体流，这可以很好的节约网络带宽。不过这需要网络本身支持多播的功能，如Mbone。
对于单播，每个客户端与流媒体服务器之间都会建立独立的媒体流，客户端越多，媒体流连接也越多，对流媒体服务器和网络带宽都会带来很重负担。不过这种方式对传输网络没有额外要求，所以在网络上应用可以很广泛。

4.6 应用场景
流媒体的特性决定了这项技术可以应用于对多媒体文件回放要求不高，实时性要求高的业务。下面简单介绍几个比较常见的应用场景，关于3G的应用放到后面移动流媒体再作介绍。

4.6.1 视频点播
（略）

4.6.2 视频直播
（略）

4.6.3 网络电台/电视台
（略）

5、              协议介绍
现在流行的流媒体协议有两种：RTSP和MMS。RTSP协议是IETF制定的流媒体控制协议公开标准。MMS是微软私有的协议，微软没有公开任何技术细节，所以网络上所能获取的相关资料都是爱好者通过抓包分析汇总的，并没有官方授权或保证。

5.1 流媒体控制协议RTSP
5.1.1 简述
RTSP是一个应用层协议，用来控制实时传输的多媒体数据。RTSP一般来说本身并不用来传输媒体流，但是在交织模式下，媒体流和控制流是混合在一起的。
RTSP独立于传输层协议，可以使用TCP，也可以使用UDP。
RTSP是从HTTP发展而来的，语法结构、操作和很多概念都是沿自HTTP/1.1。但是跟HTTP是无状态协议不同，RTSP需要维护协议状态。
RTSP消息包是基于文本格式的。

5.1.2 状态机
一般情况下，RTSP媒体流控制与媒体流传输是相互独立的，那么在媒体流传输开始后，即使流媒体服务器没收到RTSP信令，媒体流的传输仍然会继续。所以会存在这样一种情况，在整个媒体流过程中，RTSP媒体流控制信令会分别通过多个顺序的TCP连接来传输。因此，流媒体服务器需要保持会话状态来把RTSP信令关联到相应的媒体流控制上。

客户端的状态机：
Init：已经发送SETUP信令，等待服务器回复；
Ready：收到SETUP信令的回复或者在Playing状态收到PAUSE信令；
Playing：收到PLAY信令的回复；
Recording：收到RECORD信令的回复；

服务器的状态机：
Init：初始化状态，没收到任何SETUP信令；
Ready：收到SETUP信令，并回复或者在Playing状态收到PAUSE信令并回复；
Playing：收到PLAY信令，并回复，媒体流数据已经发送；
Recording：在保存媒体流数据；

客户端在接收到请求成功的回复时改变状态，而服务器在收到请求并成功处理的时候改变状态。

5.1.2 参数
5.1.2.1 会话索引
会话索引是每个媒体流控制的全局标志，服务器收到SETUP信令并成功处理就会生成一个会话索引并通过回复发送到客户端。后续对该媒体流的控制请求都需要带上会话索引。

5.1.2.2 NPT
NPT显示媒体流以播放时间为度量基准相对开始的播放位置。NPT通常用于指示播放、暂停或者录播的开始/结束时间。

5.1.3 回复
RTSP回复状态码和原因说明如下：
       1xx：通知回复—表示请求已经收到，而且正在处理中；
       2xx：成功—表示请求已经正常处理；
       3xx：重定向—表示请求需要发送到另外的服务器进行处理；
       4xx：客户端错误—表示请求因为格式不对而处理出错；
       5xx：服务器错误—表示请求因为服务器问题而处理出错；

5.1.4 方法定义
5.1.4.1 DESCRIBE
DESCRIBE用来获取服务器上媒体文件的描述（如音/视频编解码格式，媒体流格式等）。

5.1.4.2 SETUP
SETUP指定媒体流的传送方式。对于正在传输的媒体流，SETUP可以改变传输参数。

5.1.4.3 PLAY
PLAY请求服务器开始传输由SETUP指定传送方式的媒体流。PLAY可以指定需要传输的流文件的时间段，如指定开始时间和结束时间。如果客户端已经处于PLAYING状态，发送PLAY不会引起状态变化，所以也可以用来作为客户端对服务器的心跳检测。

5.1.4.4 PAUSE
PAUSE暂停媒体流传输。PAUSE可以指定时间点，当媒体流传输到该时间点的时候，就会实现暂停。如果该时间点在流传输时间前面，那么会返回“457 Invalid Range”错误。如果没有指定时间点，正在传输的媒体流会立刻停止。

5.1.4.5 TEARDOWN
TEARDOWN停止相应的媒体流传输，释放相关的会话资源。

5.1.4.6 GET_PARAMETER
GET_PARAMETER是用获取相关流的参数。回复里面的内容可以自定义。GET_PARAMETER请求里面如果没有消息体，通常是用来做客户端和服务器之间的连接心跳检测的。

5.1.4.7 RECORD
RECORD是用来录像的，需要指定开始时间和结束时间，如果没有就从会话开始时间开始录像。需要注意的是，如果要对某个会议进行录像，在调用RTSP的RECORD功能前，必须已经加入这个会议，RTSP协议并不能实现加入会议的功能，需要用其它（如H.323）协议完成。

5.1.4.8 Embedded (Interleaved) Binary Data
由于RTSP和媒体流传输是分离的，在碰到服务器和客户端之间存在NAT/FW的情况下，媒体流的传输就会被NAT/FW挡住而导致出现收不到媒体流数据的问题。为了解决这个问题，RTSP提供了媒体流控制和媒体流数据交织的方式。这种方式只能应用于TCP连接。
当媒体流数据使用RTP传输时，RTCP信令也需要交织在RTSP数据包里面。

5.1.5 包头定义
（略）

5.1.6 缓存
与HTTP不同，RTSP的信令几乎不需要缓存（除了DESCRIBE或者ANNOUNCE的回复），因为一般来说媒体流的传输与RTSP是分离的。但是对于媒体流，缓存是有必要的。
出于对流媒体服务器负荷分担和网络带宽的分流，在客户端和服务器之间通常会存在代理，如下图所示。当代理收到来自客户端的SETUP或者PLAY请求时，它会通过向服务器发送SETUP或者DESCRIBE请求，根据比较服务器回复中的Last-Modified包头与缓存的流媒体文件确定缓存文件是否是最新。如果缓存文件不是最新的，代理会修改SETUP的传输参数然后传给服务器。对后续的RTSP控制信令如PLAY或者PAUSE，代理就不会做修改。当媒体流经过代理传输到客户端时，代理会缓存一份流媒体文件替换掉原来的文件。
与HTTP的代理不同，RTSP代理的缓存并不需要把服务器上的所有资源备份下来，只是把经过代理传输到客户端的媒体流缓存一份，所以这个缓存机制不会带来额外的开销。
代理在RTSP里是个B2BUA，对于客户端来说，代理就像服务器，对于服务器来说，代理就像客户端。

5.1.7 例子流程描述
5.1.7.1 媒体点播
在这个例子中，流媒体文件的音频和视频流分别存储在流媒体服务器A和流媒体服务器V上，而服务描述文件则发布在页面服务器上。客户端在进行点播时，需要先通过HTTP协议从页面服务器获取到流媒体的信息，然后分别发起RTSP会话到流媒体服务器A和V，以建立音频和视频媒体流。在结束点播业务时，也需要分别结束相应音/视频流。示意时序图如下：
5.1.7.2 给一个存在的会话播放媒体
在这个例子中，客户端正在参与一个会议，他想通过流媒体服务器向其他与会者播放一段演示录像，那么需要在SETUP请求里面附带Transport和Conference包头描述相关参数。媒体流加入会议的过程不属于本文档的描述范畴，下面只给出RTSP的示意时序图：

5.1.7.3 录像
这个例子中，客户端参与一个会议，他想要流媒体服务器对会议进行录像，那么需要使用ANNOUNCE请求告诉流媒体服务器需要录像会话的详细信息。简单时序图如下：

5.2 与RTP的互动
在点播的业务中，客户可以对播放文件进行快进、快退等操作，这样就会出现RTSP的NPT跳跃的情况。但是RTP包的序号和时间戳不能受NPT跳跃的影响，仍然应该是连续的。
例如，媒体流的时钟频率是8000Hz，RTP的打包时间间隔为100毫秒，初始序号和时间戳为0。第一段播放NPT 10到15，第二段播放NPT 18到20。那么第一段RTP包的序号从0到49，时间戳从0到39200。第二段RTP包的序号接着从50到69，时间戳从40000到55200。
这样的机制可以防止出现以下这种错误情形：在客户端，RTSP处理与RTP处理是相互独立的两个进程，它们之间不能进行通信。那么如果RTP的时间戳与NPT一样的跳跃，RTP处理会认为媒体流出现暂停。如果NPT跳跃的时间足够大，使得时间戳的值回滚了，RTP处理会认为后续收到的包是以前重复的包。

5.3 使用SDP描述RTSP会话
RTSP会话使用SDP来描述媒体流。SDP是IETF组织制定的公开标准，关于各个参数的详细定义可以参考RFC2327。
值得注意的是，RTSP里面有一个集中控制和非集中控制的概念。所谓集中控制，就是说在客户端触发一个多媒体业务的时候，构成这个多媒体呈现的多个媒体流来自同一个流媒体服务器，而这些媒体流可以使用一个RTSP会话来进行控制。相反的，构成多媒体呈现的多个媒体流来自一个或者多个流媒体服务器，而这些媒体流无法用一个RTSP会话进行控制，就称为非集中控制。通常情况下，非集中控制的SDP是通过HTTP或者非RTSP协议获得的，而集中控制的SDP是在DESCRIBE的回复里附带的。

5.4 安全考虑
由于RTSP是明文传送的，而且媒体流传输一般使用RTP，所以对于有安全需要的应用必须考虑提供更有保障的安全机制。
l      用户认证机制：流媒体服务器可以校验请求用户是否合法。与HTTP类似，该机制主要有Basic和Digest两种方式。
l      RTP媒体流加密及密钥管理机制：因为RTP是公开标准，而且IP网络本身具有的开放性，所以很容易被窃取数据内容，所以对信息内容进行加密，是安全通讯的需要。由于RTP只是传输协议，所以密钥的传输管理就需要媒体流控制协议来完成。但是RTSP并不是基于OFFER/ANSWER模型的，所以RTSP以及附带的SDP都需要增加额外的包头来传递所需参数，详细信息清参考《Key Management Extensions for Session Description Protocol(SDP) and Real Time Streaming Protocol(RTSP)》文档。



本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/1251/showart_406332.html