OBS+RED5+FFPLAY构建流媒体点直播平台 —— 实现自己的游戏直播不再是梦想

一. 前言

记得本科时，学生宿舍并不限制必须接入校园网，也能选择接入运营商网络，于是网络中心的一帮人为了营造校园网资源多且免费的形象，费心思搞了个教育网视音频点播平台以及资源分享FTP，虽然打着学习资源分享的名义，不过最终人心所向都变成了娱乐资源，游戏，音乐，影视剧构成了内网资源三剑客，那种买台笔记本连入校园网直接就能从FTP down游戏联机战局的感觉极大的提高了我校在我们莘莘学子口耳相传中的口碑，于是联网必连校园网成为了时尚，这直接导致后来网络中心所能分配教育网公网IP耗尽，只能整改为私网组网。我是09年读的大一，10年出头的时候还没有提速降费的口号，那个时候网络下行达到1~2Mbps就算是光速了，宿舍人多网速虽说不慢但是不稳，看个优酷土豆还是能把人卡哭的，经常性的弹出上报网络卡顿的提示栏，也因此网络中心的那个点播平台上线后感动哭了一大批看剧狂魔，因为在内网所以没有带宽问题故而播放流畅，资源真的好多而且还自带更新，简直堪比小土豆，欧美日韩应有尽有，我就是当时看的《灭世》（Revolution）第一季，小剧种好多人没听说过，也没看完，印象较深是因为看过几集后‘bitch就是矫情；bitch就是死不了’的感触记忆犹新。现在想想这个点播平台肯定是网络中心外包给别人做的并且附带后续维护和资源更新服务，先不怀疑他们是否有闲工夫搭平台（而且那个平台很商业化另外专业的不像是学生做出来的）单是持续更新某些恋爱养成游戏视频就不是那些老学究们的风格，因为当时我制霸了我班跑车界号称电信09级某班车神（后来在一同学多事的撺掇下，与石家庄某高校某宿舍团体竞技中被碾压到哭，不得己含恨隐退从此再无车神，后来听说石家庄他们宿舍四个经常闭门不出，没日没夜的在宿舍磨炼跑车技艺，并且我那多事同学事前添油加醋的渲染我们气焰多么的嚣张，从那以后每次见到那个同学我都忍不住想揍他），总之在被碾压之前我是靠辆板车就能撞歪众人拿第一神一样的存在，自信心爆棚的我自然想将我神乎其技的游戏视频放到我的网页上，从这点讲幸好后来没搞成功，现在回首才不得不感慨中国互联网最近几年发生了多么大的变化，如今云无处不在，当年只能去找godaddy，学生没单位办不了信用卡刷美刀，还要淘宝上代购，万网还没有被阿里收购，买域名复杂的跟期末考试似得，如今阿里云免费注册非com域名，godaddy直接简体中文上线，所以说人这辈子无论碰上多大的事最重要的就是好好活着，活着就有希望，总之就是我当年财力范围之内能使用的服务器性能和带宽都不行，加载个flash都能页面崩溃，所以这种内网里的流媒体点播技术让我很是着迷，尝试研究后发现完全搞不懂其技术原理，确实其使用的技术门槛是当时的我完全跨越不了的，该平台web后台使用asp.net，配合独立开发的streaming server，微软的粉估计是VC++写的，以及对应的浏览器播放插件，没有使用现成的流媒体点播方案，加上当时的我并非计算机专业科班出身且入门级水平没法举一反三，图书馆查阅资料无果最后只能放弃，现在想想当年那些科班的同学也挺弱的，当然毕竟也刚上专业课，软开专业JAVA方向的只知道JSP前后台技术都分不清的人至今都在抱怨是我当年误导了他导致研究了半个月才发现这玩意的实现跟JAVA后台一点关系都没有，flash方向的同学专业是艺设，简笔画画的不错提到编程就傻了，直到后来大家见多识广了才明白这种技术架构也就这样简单。其实从我们常见的视频网站采用的技术来看，特别是flash技术鼎盛的时期（现在在H5的强势推进下，flash略有式微）往往使用的还是HTTP缓冲式加载而非真正意义上的RTSP流式加载，究其原因应该还是实时流媒体对服务器资源的消耗较HTTP多，公网视频流式点播用户量过大容易引起服务器性能瓶颈，因此RTSP更多应用在网络视频会议上，而在直播行业兴起之后关于RTSP的讨论才又多了起来。

二. 流媒体技术

流媒体（streaming media）是个泛称，重点在于streaming（流式），这个概念经常被解释为流式传输，这种解释本质上没有错误只是容易引起误解，因为网络里所有数据的传输方式均可称为流式传输，因此明晰此概念的关键在于认识此概念强调的是媒体数据应用加载方式而非传输方式，或者称之为流式加载而非流式传输。

我们知道计算机网络传输的基础在于TCP/IP协议栈，完整的数据内容分装到一定数量的package从source端发送到destination端组装后在传递给应用（显示或保存到文件系统），组装的过程需要在内存中缓冲或者缓存已收到数据，这种缓冲全部数据后在传递应用的方式是传统计算机网络的方法论，这种方法论在传输文本数据时是毋庸置疑的方案，但当传输多媒体数据的时候情况就发生了变化，因为我们对多媒体数据没有传统意义上完整性的需求而更着重于数据实时性的呈现，因此对多媒体数据的处理方式需要从传统完全缓冲后加载转变为对缓冲数据的及时加载，也就是只要数据缓冲到一定的量级，应用就开始加载呈现数据，这种方法论即为streaming。

上述可知streaming即实现缓冲数据的及时加载，体现在streaming client的功能上，而从对缓冲数据的请求响应方式上可细分为real-time streaming 和 progressive streaming，前者实现媒体数据时间轴上的实时请求响应，通常使用RTSP等协议实现，而后者只能实现媒体数据整体的单次请求响应，通常使用HTTP协议实现。

					     Application Layer
---> Transport Layer -----> RTSP/HTTP -- [cache/streaming] -----> App
	     		     [request-response-type] [data-load-type]

不同于progressive streaming往往只需要台HTTP/FTP服务器加上支持streaming的播放器（可以认为几乎所有的播放器技术均支持）即可实现，real-time streaming需要专用的streaming server（严谨的讲应该是RT Streaming Server）, RTSP以及播放器或者播放器插件，实现直播的话还要推送端软件。

HTTP/FTP Server <-- HTTP/FTP --> Streaming Player Client

RT Streaming Server <-- RTSP --> RT Streaming Player Client (on demand)

RT Streaming Broadcaster <-- RTSP --> RT Streaming Server <-- RTSP --> RT Streaming Player Client (live)

实时流媒体服务主要方案有：
a. 微软系：WMS(Windows Media Service)+ MMS + WMP(Windows Media Player) （近淘汰）
b. RealNetworks系： Helix Server + RTSP + RealPlayer （近淘汰）
c. Adobe系： FMS(Flash Media Server)/Red5 + RTMP + Flash Player （popular）
d. Apple系：DSS(Darwin Streaming Server) + RTSP + QuickTime (优雅的小众派)

三. 流媒体方案

Adobe公司的flash可以算是流媒体技术的代名词，虽然FMS价格不菲，但是所幸还有开源软件Red5的存在用以实现FMS的功能，flash player需要用到actionscript编写脚本，不利于演示，因此使用开源的FFmpeg套件中ffplay工具实现流播放器功能，自此点播平台方案已经构建完毕，如要实现直播还需要流推送客户端，这里选用开源的OBS作为broadcaster。

OBS: https://obsproject.com/
Red5: http://red5.org/
FFmpeg: http://ffmpeg.org/

四. 构建说明

安装Red5服务器：

1.因为Red5基于JAVA开发，因此首先确保JRE/JDK安装到服务器，注意：新版Red5适用于JRE8但不兼容JRE7，并且要在安装完JRE后添加JAVA_HOME环境变量，Red5的启动脚本需要引用该变量。

2.下载Red5软件包，解压后目录结构如下所示：

因为无需自定义Red5的功能以及更改配置，唯一要关注的点就是webapps文件夹，该文件夹是Red5 web服务的根目录；并且其下的子文件夹为流媒体索引路径，流媒体文件默认到streams子文件夹下检索；其下WEB-INF子文件夹内定义了三个配置文件如下所示：

├── webapps
    ├── self
        ├── index.html
        ├── streams
        │   ├── BladeRunner2049.flv
        │   └── guardians2.mp4
        └── WEB-INF
            ├── red5-web.properties
            ├── red5-web.xml
            └── web.xml

3.执行shell脚本启动Red5服务，然后在浏览器中敲入localhost:5080能访问web界面即为启动成功。上述的index.html文件web访问路径为:5080/self/index.html，Streaming直播推送URL为rtmp:///self/，Streaming直播URL为rtmp:///self/，Streaming点播URL为rtmp:///self/BladeRunner2049.flv。

安装OBS

1.下载OBS安装包双击安装后打开Setting-Steam设置Stream URL以及Stream Key，注意Stream Key在player播放直播时起类似于点播时媒体标识的作用。

2.点击Start Streaming开始向Red5发送流数据，可从Red5 log看到回显信息：

使用FFmpeg

1.下载FFmpeg软件包，命令行模式下进入bin目录。

2.由上述可知流媒体直播URL为rtmp://192.168.1.116/self/test，点播URL为rtmp://192.168.1.116/self/BladeRunner2049.flv， 因此在命令行分别敲入以下命令：

ffplay rtmp://192.168.1.116/self/BladeRunner2049.flv
ffplay -i "rtmp://192.168.1.116/self/test live=1"

四. http/https与rtmp

rtmp是Adobe公司开发的实时流协议，因为应用广泛可以作为RTSP的代表，实时流协议的实时性体现在服务端与客户端的信道中既有控制消息也有数据消息，而作为互联网基础的HTTP从开发伊始就是文件传输性质的协议，从理解的角度可以简单的认为只有数据消息，因此从实时点播的角度来讲rtmp要优于http，但是协议消息的复杂化也会带来系统架构以及带宽控制的成本增加，因此大部分的媒体平台依旧选择http作为流媒体协议，常见的HTTP请求场景都是以文件为单位，但HTTP请求中也可以使用range参数指定请求文件中固定范围的比特数据即分块传输功能（2000年的时候断点续传功能让我觉得很神奇），基于该功能可以将控制功能下沉到客户端，依据进度条的位置计算HTTP请求的比特范围发送请求，这种折中方案应用极为广泛，毕竟CDN等分发网络对HTTP的支持比对复杂的rtmp等协议要友好的多。