流媒体服务器原理和架构解析

多媒体数据文件

一个完整的多媒体文件是由音频和视频两部分组成的，H264、Xvid等就是视频编码格式，MP3、AAC等就是音频编码格式，字幕文件只是附加文件。目前大部分的播放器产品对于H.264 + AAC的MP4编码格式支持最好，但是MP4也有很多的缺点，比如视频header很大，影响在线视频网站的初次加载时间。

为了降低头部体积，需要进行视频本身的物理分段等等。对MPEG2-TS格式视频文件进行物理切片，分成一小段，这种方式被Apple公司的HTTP Live Streaming (HLS)技术采用。另外一种是使用Fragmented MP4文件格式，这是一种文件内部的逻辑分割方式，而视频文件还是完整的，这种技术被 Microsoft Smooth Streaming和Adobe HTTP Dynamic Streaming采用。很多在线视频网站在带宽耗费的压力下，主要选择的是adobe公司提供的FLV或F4V，FLV是流媒体封装格式，可将其数据看为二进制字节流。总体上看，FLV包括文件头（File Header）和文件体（File Body）两部分，其中文件体由一系列的Tag及Tag Size对组成。

流媒体传输类型

流媒体在播放前不是完全下载整个文件，而是把开始部分内容存入内存，数据流是随时传送随时播放。

流媒体服务器提供的流式传输方式有两种：顺序流式传输和实时流式传输 两种方式。

顺序流式传输是顺序下载，在下载文件的同时用户可观看在线媒体。如果使用普通的HTTP服务器，将音视频数据以从头至尾方式发送，则为顺序流媒体传输。实时流式传输总是实时传送，特别适合现场事件。一般来说，如果视频为现场直播，或使用专用的流媒体服务器，或应用如RTSP等专用实时协议，即为实时流媒体传输。实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差。

在流式传输时，流媒体数据具有实时性，等时性等基本特点，流服务期和客户终端要保证各种媒体间的同步关系，因此，流媒体传输对“最大延时”，“延时抖动”等QoS参数都有严格要求。

实时流传输既可传输实况直播，也可传输完整的音视频文件（专用协议流式）。

     顺序流媒体不可用于实况直播，仅能传输完整的音视频文件（HTTP渐进式）。

 

区别	实时流	顺序流
音视频数据源	实时从录制设备上采集， 或（使用专用协议传输的）文件	可播放的音视频文件
服务器类型	专用流媒体服务器，如： QuickTime Streaming Server Real Server Windows Media Server Flash Media Server	普通的HTTP服务器， 或FTP服务器
传输协议	专用协议RTSP， HLS或RTMP等	一般的HTTP协议， 与传输网页的协议相同
跳播	可随机访问任意片段	在给定时刻，用户只能观看已下载的那部分，而不能跳到还未下载的部分

 

主流的流媒体协议

主流的流媒体协议主要有： RTMP， HLS， RTSP等。

 

区别	RTMP	HLS	RTSP
全称	Real Time Message Protocol	Http Live Stream	Real Time Streaming Protocol
上层协议	TCP或HTTP	HTTP	RTP，RTCP
软件模型	C\S	B\S	C\S
研发主要来自	Adobe	Apple	Microsoft
针对客户端	支持Flash类产品 的浏览器 支持HTML5的浏览器	苹果的Safari浏览器 支持HTML5的浏览器	播放器
视频格式要求	FLV， F4V	MP4	无
服务器要求	专用Flash服务器 Flash Media Server Red5	普通HTTP服务器	专用RTSP流媒体服务器
实况直播要求	专用编码器上传 Flash Media Encoder	专用编码器上传 Apple开发工具	与服务器相关， 自定义上传
文件播放要求	FLV ，F4V文件即可， 服务器会自动分解为 F4f 数据文件 f4x索引文件	TS数据文件， M3u8索引文件	与服务器相关， 与播放器相关

 

流媒体协议原理

(一)  HTTP渐进式下载原理（仅支持文件播放）

HTTP边下载边播放，严格意义上讲，不是直播协议。他的原理是先下载文件的基本信息，音频视频的时间戳，再下载音视频数据，以播放mp4为例，先下载文件头，根据文件头指引下载文件尾，然后再下载文件的音视频数据。

播放方式：浏览器调用系统播放器播放；

           使HTML5的Video标签，浏览器支持直接播放。

 

(二)  苹果支持的HLS原理（实况直播、文件点播）

 

服务器端有三个组件：

其一：编码器（media encoder）, 用于将设备输出的格式转为H264和AAC，并封装为MPEG-2传输流；

其二：流分段器（stream segmenter）, 用于实况直播，将MPEG-2流分割为多个小片段后输出；

其三：文件分段器（file segmenter）, 用于文件点播，将文件分隔为多个小片段后输出；

分发原理

数据经以上三部分处理后为.ts文件（媒体数据）及.m3u8文件（媒体数据索引）存在于服务器之上。 客户端访问.m3u8后按索引下载.ts文件进行播放。

 

下面为某m3u8文件内容：

#EXTM3U

#EXT-X-TARGETDURATION:30

#EXTINF:30,

http://192.169.1.176/sample_100k-1.ts

#EXTINF:30,

http://192.169.1.176/sample_100k-2.ts

#EXTINF:30,

http://192.169.1.176/sample_100k-3.ts

#EXT-X-ENDLIST

 

根据这个文件，播放器会依次下载sample_100k-1.ts，sample_100k-2.ts，sample_100k-3.ts

 

     HLS的文件点播

1. 使用苹果开发工具“文件分段器”将基于H264和AAC或MP3的MPEG4分段，

生成.ts和.m3u8文件，存储于普通服务器上。

2. 苹果应用程序或苹果浏览器可以通过访问.m3u8文件获取到索引，并下载所需要的数据片段来播放。

     HLS的实况直播

1.  使用苹果开发工具“流分段器”将基于H264、AAC、MP3的MPEG2传输流分段，

可使用其它工具将MPEG4音视频文件加载到MPEG2传输流当中。

生成.ts和.m3u8文件，存储于普通服务器上。

2.  苹果应用程序或苹果浏览器可以通过访问.m3u8文件获取到索引，并下载所需要的数据片段来播放。

 

(三) Adobe Flash 支持的RTMP协议（支持文件播放 和 实况直播）

RTMP(Real Time Messaging Protocol) 

是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输 开发的开放协议。

它有四种变种：

1)   工作在TCP之上的明文协议，使用端口1935；

2)   RTMPS通过TLS/SSL连接；

3)   RTMPT封装在HTTP请求之中，可穿越防火墙；

4)   RTMPS类似RTMPT，但使用的是HTTPS连接；

RTMP协议(Real Time Messaging Protocol)是被Flash用于对象,视频,音频的传输。这个协议建立在TCP协议或者轮询HTTP协议之上。RTMP协议就像一个用来装数据包的容器,这些数据既可以是AMF格式的数据,也可以是FLV中的视/音频数据。一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的。

必须采用Flash服务器FMS(Flash Media Server) 或 RED5.

FMS的文件点播

1.   服务器将F4v 或 Flv文件转化为RTMP流或HTTP流

2.   客户端获取RTMP流，提取相应的Flv 或 F4v文件片段进行播放。

FMS的实况直播

1.   设备端将数据转化为F4v片段，通过RTMP流上传到服务器

2.   服务器转发RTMP流到客户端

3.   客户端获取RTMP流，提取数据片段播放。

 

 

(四) RTSP协议

该协议用于C/S模型，是一个基于文本的协议，用于在客户端和服务器端建立和协商实时流会话。

实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。

实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。

协议支持的操作如下：

(1）从媒体服务器上检索媒体：用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。

(2）媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。

(3）将媒体加到现成讲座中：如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。

下面区分几种操作模式。

(1）单播：用户选择的端口号将媒体发送到RTSP请求源。

(2）服务器选择地址多播：媒体服务器选择多播地址和端口，这是现场直播或准点播常用的方式。

(3）用户选择地址多播：如服务器加入正在进行的多播会议，多播地址、端口和密钥由会议描述给出。

 

RTSP控制通过单独协议发送的数据流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的连接状态。RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：

(1) SETUP：让服务器给流分配资源，启动RTSP连接。

(2) PLAY与RECORD：启动SETUP分配流的数据传输。

(3) PAUSE：临时停止流，而不释放服务器资源。

(4) TEARDOWN：释放流的资源，RTSP连接停止。

标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连接产生连接标识。

RTSP为纯粹的传输控制协议。

RTSP协议本身不与它负载的媒体数据相关。

RTSP协议需要自定义客户端向服务器发送RTSP命令。

 

流媒体服务器的协议栈

在TCP／IP参考模型中，传输层通信协议TCP和UDP都不能满足流媒体传输的QoS要求。由于TCP协议采用滑动窗口控制机制，数据传送随着流控窗口动态的启动和关闭，难以满足流媒体实时和等时的传送要求。UDP协议的无连接特点能够提高传输速率，虽然可以在某种程度上满足流媒体的实时性要求，但是由于其本身的不可靠性，也无法满足流媒体传输的需要。

针对传输层协议的矛盾，为了实现流媒体在IP上的实时传送播放，设计流媒体服务器时需要在传输层协议（TCP／UDP）和应用层之间增加一个通信控制层。在增加的通信控制层，采用相应的实时传输协议，主要有：数据流部分的实时传输协议RTP（Real－time Transport Protocol），用于控制部分的实时传输控制协议RTCP（Real－time Control Protocol）和实时流化协议RTSP（Real－time Streaming Protocol）。

 流媒体服务器的协议栈，如图1所示。

RTP协议主要是用来传送实时的流媒体信息，数据报主要包括多媒体数据，以及所携带负载的时间戳，顺序号等。

RTCP协议的数据报主要包括了接收者收到某个多媒体流的服务质量信息Qos，用于对服务器端的反馈。

RTSP是一种控制协议，包括通信连接前的设定，从服务器送出的多媒体资料的控制。用于控制具有实时性的数据传输。它提供对流媒体的类似VCR（Video Cassette Recorder）的控制功能，如播放、暂停、快进、录制等，也就是RTSP对多媒体服务器实施网络远程控制。

 

流媒体服务器的功能框图，如图2所示。

当服务器收到RTSP请求，它首先产生RTSP请求对象。服务器通过RTSP协议的应答信息将请求的内容以流会话（streaming session）的形式描述，内容包括数据流包含多少个流、媒体类型、和编解码格式。一个流会话由一个或多个数据流组成，如视频流和音频流等。实际的数据流通过RTP协议传递到客户端。RTP在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP本身并不能为顺序传送数据包提供可靠的传送机制，它依靠RTCP一起提供流量控制和拥塞控制服务。在RTP会话期间，各连接者监视下层网络的性能，并将相关信息放入RTCP包，周期性地传送RTCP包来通知发送方。发送方也可以用RTCP包提供每次的会话信息，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，因有效的反馈和最小的开销使传输效率最佳化。

　　通过流媒体服务器的协议栈的设计，可以明确流媒体服务器是在传输层协议（TCP，UDP）上解释RTP，RTCP，RTSP协议的，所有的客户连接请求都是以TCP的端口获得的，流媒体数据也都是打成RTP包，通过UDP端口发出去的，因此，对于TCP，UDP端口事件的调度以及如何把大量的流媒体数据从磁盘空间传递到网络上成为制约流媒体服务器性能的主要因素。

 传统流媒体服务器的处理流程，如图3所示。

　　 流媒体服务器面对一个单一的客户，完成的过程如下：

　　 1）在客户端发出RTSP连接请求后，服务器通过对TCP端口的监听，读入请求。

　　 2）解析请求内容，调入相应的流媒体文件。

　　 3）形成RTP包，分发数据流包，获得RTCP包。

4）数据包发送完毕，关闭连接。

  

上图是RTSP直播服务器的系统框图。

从摄像头采集实时图像，送到编码器进行实时编码，一般是生成TS格式的数据流，然后数据流输出到视频直播服务器。客户端先发送请求到web服务器，然后再重定向到RTSP视频服务器，从视频服务器读取数据，同时实现播放，暂停等功能。

流媒体的传输技术

一、单播：

主机之间“一对一”的通讯模式，网络中的交换机和路由器对数据只进行转发不进行复制。如果10个客户机需要相同的数据，则服务器需要逐一传送，重复10次相同的工作。但由于其能够针对每个客户的及时响应，所以现在的网页浏览全部都是采用IP单播协议。网络中的路由器和交换机根据其目标地址选择传输路径，将IP单播数据传送到其指定的目的地。

单播的优点：

1. 服务器及时响应客户机的请求

2. 服务器针对每个客户不通的请求发送不通的数据，容易实现个性化服务。

单播的缺点：

1. 服务器针对每个客户机发送数据流，服务器流量＝客户机数量×客户机流量；在客户数量大、每个客户机流量大的流媒体应用中服务器不堪重负。

 

二、 广播：

主机之间“一对所有”的通讯模式，网络对其中每一台主机发出的信号都进行无条件复制并转发，所有主机都可以接收到所有信息（不管你是否需要），由于其不用路径选择，所以其网络成本可以很低廉。在数据网络中也允许广播的存在，但其被限制在二层交换机的局域网范围内，禁止广播数据穿过路由器，防止广播数据影响大面积的主机。

广播的优点：

1. 网络设备简单，维护简单，布网成本低廉

2. 由于服务器不用向每个客户机单独发送数据，所以服务器流量负载极低。

广播的缺点：

1.无法针对每个客户的要求和时间及时提供个性化服务。

2. 网络允许服务器提供数据的带宽有限，客户端的最大带宽＝服务总带宽。

3. 广播禁止在Internet宽带网上传输。

 

三、组播：

主机之间“一对一组”的通讯模式，也就是加入了同一个组的主机可以接受到此组内的所有数据，网络中的交换机和路由器只向有需求者复制并转发其所需数据。主机可以向路由器请求加入或退出某个组，网络中的路由器和交换机有选择的复制并传输数据，即只将组内数据传输给那些加入组的主机。这样既能一次将数据传输给多个有需要（加入组）的主机，又能保证不影响其他不需要（未加入组）的主机的其他通讯。

组播的优点：

1. 需要相同数据流的客户端加入相同的组共享一条数据流，节省了服务器的负载。具备广播所具备的优点。

2. 由于组播协议是根据接受者的需要对数据流进行复制转发，所以服务端的服务总带宽不受客户接入端带宽的限制。

3. 此协议和单播协议一样允许在Internet宽带网上传输。

组播的缺点：

1．与单播协议相比没有纠错机制，发生丢包错包后难以弥补，但可以通过一定的容错机制和QOS加以弥补。

2．现行网络虽然都支持组播的传输，但在客户认证、QOS等方面还需要完善，这些缺点在理论上都有成熟的解决方案，只是需要逐步推广应用到现存网络当中。

 

自适性串流技术

自适性串流（ABS - adaptive bitrate streaming），是一种在电脑网络使用的一种串流技术。过去的流媒体技术多使用 RTP/RTSP，但现在的技术则大多基于 HTTP，并为更高效在大型分布式HTTP网络（例如互联网）分发而设计。

此技术根据实时检测的用户的带宽和CPU使用率，调整视频流的质量。这需要使用一种可以将单一视频源输出为多码率的编码器。播放器客户端依赖可用资源在不同码率的流之间切换。"结果就是：更少缓存、更快的开始播放、为低端和高端链接都提供良好的体验。

根据当前广泛使用的实现，更具体来说，自适应串流（ABS）：

使用 HTTP 传送视频流；

使用多码率编码源内容；

每个单码率的流被切成小的，几秒钟的小切片；

流媒体客户端首先获取所有码率的切片索引信息。一开始，客户端先请求最低码率的串流。如果客户端判断下载速度比当前码率的切片串流快，它就去请求下一个更高码率的串流。随着播放的进行，如果客户端发现下载速度比当前码率的切片串流慢，转而请求下一个较低码率的串流。

切片大小和具体实现密切相关，不过一般都在2～10秒之间。每个切片由一个完整的GOP序列组成，一个GOP序列里面有1个或者多个I帧，GOP序列的第一个帧必须是I帧，并且每个切片都能单独的解码播放显示。

与传统的流媒体技术比较，缺点：需要额外的存储，更多的编码代价，复杂的只适应码率逻辑。

 

Adaptive streaming overview

 

Adaptive streaming in action

 

MPEG-DASH (Dynamic Adaptive Streaming over HTTP)

MPEG-DASH 是基于HTTP的自适应串流方案中的唯一国际标准。MPEG-DASH 技术由 MPEG 主导开发：

2010年开始DASH相关工作，2011年1月成为国际标准草案，2011年11月成为国际标准[3]，2012年4月，MPEG-DASH 以ISO/IEC 23009-1:2012 发表。

MPEG-DASH 基于3GPP第9版的 Adptive HTTP streaming（AHS）和 Open IPTV Forum第2版的 HTTP Adaptive Streaming (HAS)。作为与MPEG合作的一部分，3GPP第10版采用了DASH（采用特别的编码和操作模式），用于无线网络。

可用的 MPEG-DASH 实现有：

bitmovin GmbH 的开源 DASH 客户端库 libdash 和 DASHEncoder

 

Adobe HDS (HTTP Dynamic Streaming)

Flash Player 和 Flash Media Server 的最新版支持传统的 RTMP 协议和 HTTP协议。后者和Apple和微软基于HTTP的方案类似。

基于HTTP的流的优势是：

不需要防火墙开普通web浏览器所需端口以外的任何端口

允许视频切片在浏览器、网关和CDN的缓存，从而显著降低源服务器的负载。

HDS 的文件格式为 FLV/F4V/MP4，索引文件为 f4m，同时支持直播和时移。

 

Apple HLS (HTTP Live Streaming)

是一种基于HTTP的媒体流通信协议，在 iPhone 3.0 及更新版中成为标准功能。

2010年10月，所有自适应串流方案都作为产权提供时，Apple 将HLS提交到 IETF，成为正式的 RFC.

HLS 串流使用扩展名为 .m3u8 的文件作为索引，文件切片格式为TS，支持直播和时移。支持的客户端包括 iPad, iPhone, STB，VLC和其他支持的设备。

 

Microsoft MSS (Microsoft Smooth Streaming)

Smooth Streaming 是IIS的媒体服务扩展，用于支持基于HTTP的自适应串流。

在2010年11月发布的 IIS Media Services 4.0 中，微软引入了一项使 Live Smooth Streaming H.264/AAC 视频动态封装成 Apple HLS 格式的功能，直接提供给 iOS 设备，而不需要再次编码。同时支持直播和点播把1080P全高清视频发送到Silverlight客户端。

MSS 的文件切片格式为 mp4（fragmented-mp4），索引文件为ism/ismc，同时支持直播和时移。

 

流行视频网站的流媒体服务器架构

为了能够提供各类设备的在线视频播放需求，对于在线视频流媒体服务，提出了很多需求，对于早期建立的视频网站（土豆，优酷，ku6等）都只提供一种视频流媒体格式（FLV）的支持，我们称之为单一的流媒体服务架构，如图：

 图1 ：单一流媒体服务的架构图

但是，在实际业务运营中遇到了很多问题：

1） 视频存储的压力很大

同一种视频码流（h.264）,因为针对不同平台应用设备（如表2）的播放需求，需要不同的封装格式，需要将产生大量重复视频流存储的压力，视频网站的视频量巨大，多支持一种格式将产生几百TB级的存储压力，从机房到机柜，视频流同步等环节负载和压力都是巨大的。

2） 封装后的视频格式是否真的被播放

视频流封装完成后，同步到各地的中心节点后，是否真的有视频流请求产生，还是仅仅处于视频准备状态，是否会影响中心节点的磁盘占用，缓存节点的命中率不高。

3） 封装格式的功能性升级，导致老视频再次封装

封装格式的不断发展，TS流，HTTP live Stream的不断优化，将导致现有的视频流不断需要翻新或重复封装。 为了解决上述各类问题，视频网站流媒体服务的研发工程师进行了多格式的流媒体服务架构探索，提供了各类视频封装格式的流媒体封装反向代理接口，该接口能够通过URL的请求，完成对特定视频编码格式（h.264）的封装。

 图2：多格式的流媒体服务架构：

如图所示，“流媒体容器封装服务“成为多格式视频流服务的核心，对于这个流媒体的封装服务，通过对h.264的视频编码流进行不同格式的封装，提供了多种视频流的推送。对于这个服务，我们希望能够尽快为视频的cache服务推送视频流，所以，在硬盘方面，选择了每分钟15000转的SAS硬盘，降低同一视频流的不同封装请求的IO延迟等待。

作为最简单和原始的流媒体解决方案，单一流媒体服务架构唯一显著的优点在于它仅需要维护一个标准的视频流文件，而这样的服务器基础设施在互联网中已经普遍存在，其安装和维护的工作量和复杂性比起多格式流媒体服务架构来说要简单和容易的多。然而其缺点和不足却也很多，首先是维护的工作量较大，多份相同视频文件由于封装格式不相同，需要同时维护多个实体的码流文件，大量的占用磁盘的空间，再次，转码集群需要针对多种不同的封装格式，进行多次的视频转码，抢占很多资源，缺乏灵活的控制功能和扩展机制。