架设一个自己的网络电视台？（直播加点播）Part TWO

LIVE RTMP HLS Nginx Streaming Broadcast 直播点播

目录
一：资源准备
二：直播点播技术简介
三：简单直播架设
四：进阶直播
五：录像等其他问题

四：进阶直播

所谓进阶，就是在上文我们那个基本的直播服务上，增加一些实用的功能。可能有人已经注意到，推流地址是固定的，且没有安全验证（虽然我们用端口转发进行了一点隐藏工作，但只能防止端口扫描）。也就是说一旦泄露出去，任何人都可以强行推流进来。所以我们首先要做的就是对推流进行身份验证。

4.1 添加身份验证

要想让rtmp模块增加身份验证，可以通过修改源代码的方式实现。但那难度太高，不适合大家推广。我们还可以通过动作事件来进行身份验证。看下图红线部分，通过 on_publish 事件来指定一个验证页面。这个页面可以是本机上的一个php页面（现成的nginx和php环境对吧），也可以是互联网上其他位置的页面。笔者这里指定了一个自己写的验证服务，方便实现更复杂的验证工作（其实php水平太烂）。注意下图还有一句 notify_method get 不要丢了。

同理其实 on_play 事件也可以用来验证播放者身份。但是，我们这里用hls播放而非rtmp播放，所以这里没用了（要实现播放鉴权，可以参考后文多机直播部分的多地址分发服务）。
说回这个身份验证页面，如果你指定本机一个 mywebsite.com/yanzheng.php 页面。那么这个页面可以这么写：

请注意上图中验证的用户名和密码通过 $_GET[‘user’]和$_GET[‘pass’] 取出了 Url中的user和pass参数，这些参数其实是可以随便改的，完全可以用name和tok代替。验证方式可以是简单的密码比对，也可以是数据库查询。最终验证通过，只要页面正常返回即可，输出什么内容无所谓。验证不通过，就返回一个404错误码就行了。这样没有正确密码的推流端就会被断开。愿意的话，可以把每次验证的信息、IP、结果存在服务器日志或数据库中。

当服务器配置好推流验证信息后，推流主播的推流地址也要相应调整。原来主播推流地址是 rtmp://mywebsite.com:1905/live/my001 。此时我们要改写成
rtmp://mywebsite.com:1905/live/my001?user=zhuboming&pass=mima
的形式。有些软件会要求推流地址和节目名分开写，那么就是这样

到此，我们给主播推流加上了一个账号密码的验证。但是说实话，这样的用户名密码太不安全了。可否将用户名、密码、节目名、主播IP地址等等进行联合验证吗？当然可以，只要你自己写验证页面就行了。笔者把验证的请求抓包出来，给各位看看，验证页面到底可以得到多少东西用来做安全检验。

上图展示了rtmp向验证页面发送的数据中最重要的部分，来简单解释一下。 app=live 这个就是对应服务器上配置的 application live 接口，参数值就是接口名或者说我们规定的频道名。下面的url不用解释了。 addr=127.0.0.1 表示了rtmp服务接受到的主播连接的对端IP地址（我们通过端口映射，所以这里变成了127.0.0.1，要想得到真实主播地址，可以不用端口映射，直接修改rtmp的端口就行了）。 Call=publish 表示触发验证的动作原因是推流。 Type=live这里说的是直播动作类型，这个live跟之前的app参数不是一个意思。 Name=my001表示的是节目名。User和pass就是我们推流地址上写的用户名和密码。这些信息都是通过 Query_string参数穿进来的。有了这些信息，我们可以采用联合验证的方式进行身份验证，比如主播的IP地址可以通过白名单筛选；比如用户名密码的参数名可以更换其他的误导词汇；比如把主播用户名与节目名和频道名联合验证，限定某主播只能在特定频道下特定节目名直播等等。只要你能写代码，都可以实现。

4.2 多机直播

前边提到过，当观众比较多的时候，对网络带宽压力比较大。对于这个问题，当然可以通过多花钱，买大带宽来解决。不过那样花费会比较大，我们也可以通过主机数量解决。毕竟小鸡的价格比带宽便宜，来的更实惠一些。我们之前配置好的那台主机，就叫主播服务器Core吧。然后我们再增加两台从属主机，叫边缘服务器edgeA和边缘服务器edgeB。当直播开始后，主播通过推流软件把媒体流推给主播服务器，主播服务器把媒体流分发给两个边缘服务器。观众就可以通过者三台主机访问观看了。承载能力立马翻三倍（理论上）。媒体流从Core分发给edgeA和B的方式可以选择推或拉（push或pull指令）。经过测试两种方式效果相同。区别就是Core主动推给A和B还是A和B主动去Core上拉。这三台主机的推拉流还是需要rtmp协议，而不是通过HLS协议的。

当然，只要你愿意，可以设置多级服务器，也可以根据用户数量动态的加入新服务器，连推带拉，手忙脚乱，哈哈哈哈。

这是一个edgeA服务器的 nginx.conf 配置文件，可以对比前文的主服务器上配置文件看。重点是增加了一行 pull 指令。通过rtmp协议向主服务器啦一个媒体流回来。要注意的时候，拉流的时候就必须指定好频道和节目名，这里是mr1900 。所以多机直播必须事先约定好节目名。然后这里不能再配置 on_publish 的身份验证。由于我们主服务器上已经配置了录像record，所以这个边缘服务器上就不在重复录像了。如果你愿意，也可以在这里录像。其他信息与主服务器类似就不废话了。边缘服务器上也要同主服务器上配置一个网站，除了域名地址与主服务器不同外，其他配置与主服务器类似，都是在站点.conf文件里添加好相应的 location 节点。节点名可以与主服务器相同或不同。开始笔者猜测，如果采用主服务器向边缘服务器push的方式，相比pull方式会更及时一些。猜测边缘服务器的pull动作需要有观众触发才去拉流。但是经过测试是笔者多虑了。使用pull模式，也是三台服务器同时可以观看。

假设我们三台服务器都配置好了。主播推流没有任何变化，还采用之前的配置。观众就有了三个可观看地址：
主服务器 https://mywebsite.com/live/my001/index.m3u8
边缘服务器A https://a.mywebsite.com/live/my001/index.m3u8
边缘服务器B http://b.newweb.com/live/my001/index.m3u8
假设三台服务器配置相同，原一台服务器可以承载15个观众，现在三台可以承载45人以上了。而这三个地址如何分配给相应的观众，就不是本文的核心问题了。所以笔者本着比较负责的态度来简单说说算了。首先我们可以通过DNS的智能线路分配，让来自不同网络位置的观众得到不同IP地址解析。这里隐含的要求就是服务器要考虑这种工作模式，多台主机上要配置相同的主机名，相同的访问路径。还有就是可以通过CDN服务进行内容转发来实现不同客户访问不同服务器。但是这样一般需要收费服务才能实现智能分配，同时还不能让CDN服务缓存m3u8和ts文件，必须是实时转发。最后当然有个免费方案，就是如果你有一定的编程能力，就可以自己写一个简单的分发服务。比如写一个页面 http://ccccc.com/cdn.aspx?chan=live&pg=my001 这个页面取参数chan和pg 。在配置表里取出真实播放地址加工一下输出301跳转到 https://mywebsite.com/live/my001/index.m3u8 即可。再比如我们的直播观看页面上嵌入了一个媒体播放器，播放器里就可以将媒体URL写成 http://ccccc.com/cdn.aspx?chan=live&pg=my001 。那么至于 cdn.aspx页面里是按照什么规则分发真实地址就看你的喜好了。可以使用计数器，让多个地址均衡的承载观众数量；也可以根据权重和客户位置实时计算，得出最优的播放地址；甚至可以什么都不考虑，直接随机分配。

五：录像等其他问题

5.1录像问题

我们在之前的服务器配置上开启了录像功能。录像不是必须的，但是经常用到。录像功能可以设置为直接开启、关闭、只录图像、只录音频、只录关键帧、主播推流端控制等等。在record命令上的详细参数可以百度。录像文件的体积是由推流的码率决定的。一般720p画面，每秒25帧，2000Kbps码率的音视频录像一小时在1.5GB上下。仔细看服务器配置的朋友已经知道，录像文件也是切片存储的。每个切片的大小可以通过多个条件限定，包括最大时长，文件体积，帧数等等。一般用文件体积做限定条件最多。建议录像切片文件体积不要限定的太小，会增加文件系统开销，也不要太大，会对内存和磁盘造成压力，一般2~8MB最好。切片文件还有其他参数可设，用于设定关键帧，时间戳，文件名等等。可以参考文末的参考资料。

5.2 录像的导出和整理

前文说了，录像都是以切片文件存放的。更准确的说是以flv文件格式存储的。（展开一点，这个flv文件用一般播放器都可以直接播放，查看内部包含的是adv视频编码，aac音频编码。似乎跟MP4
的adv+aac一个意思。但是文件真的不一样，很多视频编辑软件比如vegas里，这个flv文件是无法使用的。转码MP4后才可以用。）一个小时的录像可能有100~300个文件之多（看分片文件大小）。这些文件要下载回来留档是很不方便的。要留档还是要合并成一个文件比较好。这个问题看似是小问题，也不算直播主旨的核心问题。但确实是搞直播玩的朋友都会遇到的一个比较头疼的问题。很多合并和转码工具，合并出来的文件都会有缝隙。就是一段一段的切片合并后，每隔一定时间间隔画面或声音会停顿一下，或者跳几帧。有的很明显，有的不太明显而已。笔者对文件合并和转码进行过很多试验，总结出了一套较效果理想，速度又快的方案。暂时不想说。等笔者爽够了再更新到这里吧。哈哈哈哈

5.3 美颜、特效、导播问题

这几个问题也不算是直播的核心问题。这里简单说说给新手指个路。美颜和特效都属于前期处理，就是在推流之前的事。一般直播服务器不会进行此类处理。（但是不排除可以在直播服务器上增加处理特效的模块。）一般来说美颜和特效都是在视频采集阶段进行处理的。比如通过手机上带美艳功能的录像软件拍摄，比如在OBS软件上直接加载特效滤镜进行编码。要想美颜效果好，特效玩的好，这些东西都有专业设备。在这些前期设备处理好图像以后，再给直播服务推流。
如果再想玩的复杂点，就需要导播的介入了。导播并不是指一个专业的人，可以是OBS这种轻量级的软件，也可以是一个专业的团队。拿简单的游戏主播来说吧，至少是涉及两套视频画面，一个是主播本人的画面，一套是游戏画面，再加上一些美颜、炫彩特效，还可能有背景音乐和主播变声。这种多路资源的合成与调度就是导播干的工作。类似于OBS这种软件可以实现一些简单的资源合并，图像合成。要实现复杂的多路合并于切换，音频的调整与合成。你需要一个专业导播台。简单的导播台可能是这样：