引言：最近项目中，有需求做一个视频站点。记得大学那会儿有做过一个简单的视频播放，但比较简单，一种方式是运用了优酷视频播放，另外一种就是利用HTML5了（那时H5还没有正式规范呢），其实没有涉及流媒体方面的内容，此次负责的项目中，肯定需要使用流媒体，所以进行了深入的探索与寻觅，当然是经过阅读大量的资料来确认具体使用什么方案。本文就是记录相关流媒体协议及可进行进一步实施的方案探索，但不是对音视频底层的探索，所以主要面向做实施和开发研发人员。

 

刚开始接触“音视频”的时候，肯定都是云里雾里，一头雾水，只有当我们坚持了，就会有丰厚的果实等待着我们。这次也准备整理一个简单的系列，循序渐渐的理解流媒体，记录好实施过程，本篇是《音视频系列》的前篇，也算是知识的储备。本文一些概念一般都是引用的，主要将常用的协议以及方案进行罗列和比较。

 

 

常见的有：RTP、RTMP、RTSP、HLS、HTTP-FLV。其中RTP默认使用UDP传输协议，其他协议默认使用TCP传输协议，当然RTMP和RTSP也支持基于UDP协议实现。UDP协议，不创建立连接，会出现丢包会乱序现象，而TCP协议，需要建立连接，需要三次握手，可靠并且有序。从这两个协议的比较来看，基于UDP协议实现适合直播，基于TCP协议实现比较适合点播。

实时传输协议RTP（Real-time Transport Protocol）是一个网络传输协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统（配合RTSP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在用户数据报协议上的。RTP广泛应用于流媒体相关的通讯和娱乐，包括电话、视频会议、电视和基于网络的一键通业务（类似对讲机的通话）。

注：以上概念及简述引用自百度百科，具体详情自行搜索查看。

RTP广泛应用在视频监控、视频会议、IP电话等领域，因其内容实时性强。

RTMP即Real Time Messaging Protocol（实时消息传输协议），基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。

注：以上概念及简述引用自百度百科，具体详情自行搜索查看。

此协议在国内用的很多，因为它是开源软件，同时又有稳定的开源库，浏览器只要支持FlashPlayer就可以放RTMP的直播了，而且现在大多数的播放器都支持该协议的播放，如此选择就很多。

全称为Real Time Streaming Protocol，RFC2326，实时流传输协议，是TCP/IP协议体系中的一个应用层协议。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。

注：以上概念及简述引用自百度百科，具体详情自行搜索查看。

支持该协议的有DSS服务等。

HLS (HTTP Live Streaming)，Apple的动态码率自适应技术。主要用于PC和Apple终端的音视频服务。包括一个m3u(8)的索引文件，TS媒体分片文件和key加密串文件。

注：以上概念及简述引用自百度百科，具体详情自行搜索查看。

HTTP Live Streaming（缩写是 HLS）是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。是苹果公司QuickTime X和iPhone软件系统的一部分。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U (m3u8) playlist文件，用于寻找可用的媒体流。HLS只请求基本的HTTP报文，与实时传输协议（RTP)不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。

基于HTTP协议流式的传输媒体内容。相对于RTMP，HTTP更简单和广为人知，而且不担心被Adobe的专利绑架。内容延迟同样可以做到2~5秒，打开速度更快，因为HTTP本身没有复杂的状态交互。所以从延迟角度来看，HTTP-FLV要优于RTMP。

 

 

FMS是Adobe公司的产品，license非常昂贵。Flash  Media Server是一款高性能、多线程的流媒体服务器软件。专为多种终端设备提供音视频内容播放服务，支持iOS、windows、Android、BlackMerry等系统的终端设备，以HTTP、RTSP/ RTP、RTMP传输协议的流播放，还支持利用机顶盒进行播放的IPTV。

因其商业模式，基本支持大部分的流媒体协议，也可以实现移动端等。

DSS是Apple公司提供的开源实时流媒体播放服务器程序。整个程序使用C++编写，在设计上遵循高性能，简单，模块化等程序设计原则，务求做到程序高效，可扩充性好。

主要支持RTSP协议，实现过程中也需要其他的工具辅助，国内使用不常见。

Red5的主要功能和Macromedia公司的FMS类似，提供基于Flash的流媒体服务的一款基于Java的开源流媒体服务器。它由Java语言编写，使用RTMP作为流媒体传输协议，这与FMS完全兼容。它具有流化FLV、MP3文件，实时录制客户端流为FLV文件，共享对象，实时视频播放、Remoting等功能。用Red5替换FMS后，客户端不用更改可正常运行。

主要支持RTMP协议，若使用开源免费，其可代替FMS，是有名的基于Java实现的流媒体服务。

    4）SRS（simple-rtmp-server）流媒体，支持RTMP/HLS 直播服务器

 

其他还有很多开源的服务，大家自行探索吧！实施的方案能找到很多资料，但在实施的过程中，肯定是要因环境而异的，最终要的还是要把握思想，整理思路，所谓万变不离其宗即是如此。

 

 

以上基本都是概念，但在真正的项目中，我们应该如何确定自己的方案呢？

首先要明确视频站点是“点播”平台还是“直播”平台。

“点播”类型的平台，最好基于HTTP协议实现，因为HTTP协议是基于TCP协议，不会丢包，也就是视频不会花屏等。

“直播”类型的平台，自然一般都是基于RTMP之类的协议，因为实时传输协议是基于UDP协议，不管是否丢包，保证实时是最重要的。

此处的“语言”是指开发的语言，如Java，PHP等。比如您的项目是PHP实现的，那Java实现的服务可能就不能选择了。每种“语言”，最好首先选择本身性能最佳的服务方案。

“现状”在这里就是指落地的项目，经济情况，现有服务器配置，以及服务器环境等等因素，有些方案虽然很好，但不一定真的适合。最简单的，其实使用FMS基本能满足一般的需求，大公司可以投入成本来做，但小公司使用就不现实。再譬如，在Nginx的环境下，其实就有很多中实现方式，RTMP、HLS和HTTP FLV等实现方式，在现实的开发中，可能时间有限，可能服务器配置不高，可能客户端有限制等，在相关的情况下，选择最好的方案才是关键。

 

根据以上的步骤，其实多数会选择基于Nginx来实现流媒体。因其免费和性能，同时系统消耗低，安装部署简单。

 

 

<4> HTTP-FLV视频方案的实践.