架设一个自己的网络电视台?(直播加点播)Part TWO

架设一个自己的网络电视台?(直播加点播)Part TWO

2019年8月21日 1 By fengyeblade

前文请见 -= Part ONE =-

LIVE RTMP HLS Nginx Streaming Broadcast 直播 点播

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

四:进阶直播

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

4.1 添加身份验证

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

on_publish 事件 指定一个验证页面

同理其实 on_play 事件也可以用来验证播放者身份。但是,我们这里用hls播放而非rtmp播放,所以这里没用了(要实现播放鉴权,可以参考后文多机直播部分的多地址分发服务)。
说回这个身份验证页面,如果你指定本机一个 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这种软件可以实现一些简单的资源合并,图像合成。要实现复杂的多路合并于切换,音频的调整与合成。你需要一个专业导播台。简单的导播台可能是这样:

更高级一点的是这样:

参考资料:

Lnmp 一键安装包

Lnmp 安装 nginx配置 站点开设

Let’s Encryption HTTPS证书

Lnmp 组件以及安装位置

rtmp模块参数详解

准备HLS点播使用的TS切片文件