指定的网络文件夹目前是以其他用户名和密码进行映射的_玩个网络电视台？ ---自建直播（点播）服务下...-CSDN博客

本文首先发表在作者自己的小站，本文允许标明原作者和原始出处的情况下转载。

Tags：VPS LIVE RTMP HLS Nginx Streaming Broadcast 直播点播云主机

上一部分请参阅

大枫：玩个网络电视台？ ---自建直播（点播）服务上zhuanlan.zhihu.com

一：资源准备

二：直播点播技术简介

三：简单直播架设

四：进阶直播

五：录像等其他问题

========================

四：进阶直播

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

4.1 添加身份验证

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

on_publish 事件指定一个验证页面

同理其实 on_play 事件也可以用来验证播放者身份。但是，我们这里用hls播放而非rtmp播放，所以这里没用了（要实现播放鉴权，可以参考后文多机直播部分的多地址分发服务）。

说回这个身份验证页面，如果你指定本机一个 http://mywebsite.com/yanzheng.php 页面。那么这个页面可以这么写：

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

的形式。有些软件会要求推流地址和节目名分开写，那么就是这样

OBS 里将推流地址与串流码分开写的形式

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

rtmp 服务器使用get 方法调用验证页面时传递的参数

上图展示了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协议的。

多机直播图

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

边缘服务器的 nginx.conf 文件

这是一个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页面里是按照什么规则分发真实地址就看你的喜好了。可以使用计数器，让多个地址均衡的承载观众数量；也可以根据权重和客户位置实时计算，得出最优的播放地址；甚至可以什么都不考虑，直接随机分配。

.net 输出 301 或 302 跳转

五：录像等其他问题

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这种软件可以实现一些简单的资源合并，图像合成。要实现复杂的多路合并于切换，音频的调整与合成。你需要一个专业导播台。简单的导播台可能是这样：