本文首发于作者自己的网站。本文允许转载，注明原作者和原出处。

标签： 直播点播云主机

参见上一节

目录

一：资源规划

二：直播点播技术介绍

三：简单的直播设置

四：高级直播

五：视频等问题

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

四：高级直播

所谓高级，就是在我们基础的直播服务上面减少一些实用功能。可能有人已经注意到，推流地址是固定的，没有进行安全验证（虽然我们在端口转发方面做了一点隐藏工作，但只能避免端口扫描）。也就是说，一旦泄露出去，任何人都可以强行进来。所以我们首先要做的就是对推送流进行鉴权。

4.1添加认证

要让rtmp模块低认证，可以通过修改源码来实现。但这对你来说太难推广了。我们还可以通过行动风暴进行身份验证。看右边红线，指定一个穿越风暴的验证页面。这个页面可以是本机的php页面（现成的nginx和php环境，对吧），也可以是网上其他位置的页面。作者这里指定了一个自己写的验证服务，方便实现比较复杂的验证工作（虽然PHP级别太软了）。注意右图中还有一句话，不要弄丢了。

风暴指定验证页面

同样，虽然风暴也可以用来验证玩家的身份。而且我们这里使用的是hls播放，而不是rtmp播放，所以这里没用（实现播放信令，可以参考下面多机直播部分的多地址分发服务）。

回到这个身份验证页面，如果你指定一个本地 /.php 页面。所以这个页面可以这样写：

.php页面文件

请注意，上图中验证的用户名和密码已经通过$_GET['user']和$_GET['pass']取出用户并在Url中传递参数。这些参数可以随意更改，完全可以用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 这是对应服务器上配置的live ，参数值为我们指定的名称或者通道名称。下面的网址无需解释。 addr=127.0.0.1表示rtmp服务接收到的主机连接的对端IP地址（我们使用端口映射，所以这里是127. 0.0.1，如果要获取真实的主机地址，可以直接更改rtmp的端口，无需端口映射）。 call= 表示触发验证的动作原因是推流。 type=live 这里指的是live 的类型。这次直播和之前的app参数不一样。 Name=my001 表示程序名称。用户和通行证是写在我们的流媒体地址上的用户名和密码。此信息通过参数传入。有了这些信息，我们就可以使用联合认证的方法进行身份验证。例如，可以通过白名单过滤主机的IP地址；例如，用户名和密码的参数名称可以用其他欺骗性的词代替；联合验证频道名，限制某主播在特定频道下直播特定节目名等。只要会写代码就可以。

4.2场直播

后面会提到，当听众越多，对网络带宽的压力就越大。对于这个问题，其实可以通过多花钱买大带宽来解决。不过成本会比较大，我们也可以通过主机数量来解决。虽然小鸡的价格比带宽更实惠，但来的更便宜。我们之前配置的主机叫做锚点服务器Core。之后，我们降低两个从主机，称为边缘服务器 edgeA 和边缘服务器 edgeB。直播开始时，主机通过流媒体软件将媒体流推送到主机服务器，主机服务器将媒体流分发到两个边缘服务器。听众可以通过三台主机访问和观看。承载能力立即增加三倍（理论上）。从Core到edgeA和B的媒体流分发方式可以选择push或者pull（push or pull指令）。两种形式都被测试为同样有效。不同的是，Core 主动向 A 和 B 推送，或者 A 和 B 主动向 Core 上拉。这三个主机的推拉流仍然需要rtmp合约而不是HLS合约。

多机直播视频

其实只要你喜欢，你可以设置多级服务器，也可以根据用户数量动态添加新服务器，甚至推拉，急急忙忙的，哈哈哈。

边缘服务器的 nginx.conf 文件

这是edgeA服务器的nginx.conf配置文件，可以和上面主服务器上的配置文件对比。关键是减少一行拉指令。媒体流通过 rtmp 合约发送回主服务器。需要注意的时候，拉流的时候一定要指定频道和节目名，这里就是。因此，多机直播必须事先约定好节目名称。之后无法再在此处配置身份验证。因为我们已经在主服务器上配置了录像，所以在这台边缘服务器上不再重复录像。如果你愿意，也可以在这里记录。其他信息与主服务器类似，不是废话。还应在具有主服务器的边缘服务器上配置网站。不仅域名地址与主服务器不同，其他配置与主服务器类似。在 site.conf 文件中添加了相应的节点。节点名称可以与主服务器相同或不同。一开始，笔者推测如果采用主服务器到边缘服务器的push方式，会比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文件，必须实时转发。最后，其实还有一个免费的方案，就是如果你有一定的编程能力，可以自己写一个简单的分发服务。比如写一个页面 /cdn.aspx?chan=live&pg=my001 这个页面带参数chan和pg。取出配置表中真正的播放地址进行处理，输出301，跳转到/live/my001/index.m3u8。再比如，我们的直播页面中嵌入了一个媒体播放器，媒体URL在播放器中可以写为/cdn.aspx?chan=live&pg=my001。因此，在 cdn.aspx 页面中使用哪些规则来分发真实地址取决于您的偏好。计数器可以用来让多个地址平均携带监听器的数量；还可以根据重量和客户位置实时估计，得到最优播放地址；它甚至可以在不考虑任何一个的情况下随机分配。

.net输出301或302跳转五：视频等问题

5.1 个视频问题

我们在之前的服务器配置上启用了视频录制。视频录制不是必需的，并且经常使用。录像功能可以设置直接打开、关闭、只录图片、只录音频、只录关键帧、控制主播的流媒体等。该命令的详细参数可以百度。视频文件的大小由推流的分辨率决定。通常是720p屏幕，每秒25帧，音视频录制分辨率约为1.5GB一小时。仔细看服务器配置的同事早就知道，视频文件也是分片存储的。每个切片的大小可以受多种条件限制，包括最长持续时间、文件大小、帧速率等。通常以文件大小作为最大的限制条件。建议视频切片文件的体积不要限制得太小，会降低文件系统的成本，也不要太大，会对显存和C盘造成压力，一般为2 ~8MB 是最好的。切块文件还有其他参数可以设置，用于设置关键帧、时间戳、文件名等。可以参考文末的参考资料。

5.2 导入和组织视频

如上所述，视频都存储在切片文件中。更准确地说，它是以 flv 文件格式存储的。 （稍微展开一下，这个flv文件可以直接用普通播放器播放，查看里面是否包含adv视频编码，aac音频编码。虽然和MP4一样

adv+aac 有一个含义。而且文件真的不一样。在 vegas 等许多视频编辑软件中，这个 flv 文件很难使用。只有转码为 MP4 后才能使用。 ) 一个小时的视频可能有多达 100 到 300 个文件（取决于片段的文件大小）。下载这些文件并将它们存档是非常不方便的。最好保留文件或将它们合并为一个文件。这个问题看似小问题，并不是直播主题的核心问题。但确实是搞直播的同学会遇到的头疼问题。使用许多合并和转码工具，合并后的文件会出现空白。也就是在对段的段进行切片和合并后，画面或声音会在一定的时间间隔内暂停一段时间，或者跳过几帧。有些是显而易见的，有些则不是。笔者在文件合并和转码方面做了很多实验，总结出一套疗效理想、速度快的解决方案。我暂时不想说。当我足够酷时，我会在这里更新。哈哈哈（虽然作者还需要时间去验证文件内部转码和播放器的细微差别）

5.3皮肤美容、特效、导演问题

这些问题都不是直播的核心问题。这里是一个关于为新秀指路的简短谈话。美肤和特效都是预处理，也就是流媒体之前。通常实时服务器不做这种处理。 （并且不排除会降低直播服务器处理效果的模块。）一般来说，美肤和特效都是在视频采集阶段进行处理的。比如通过手机上带有性感功能的视频软件进行拍摄，比如直接在OBS软件上加载特效滤镜进行编码。想要美肤效果好，特效好，这种东西有专业的设备。在这些前置设备处理完图像后，它们会被流式传输到实时服务。

如果你想玩得更复杂，你需要导演的干预。导演不是指专业人士，可以是OBS等轻量级软件，也可以是专业团队。以一个简单的游戏主播为例，它至少涉及到两组视频图像，一组是主播自己的图像，另一组是游戏图像，加上一些皮肤美化、多彩的特效，可能还有背景音乐和主播的声音变化这些多路资源的合成和调度是导演的工作。类似于OBS，这些软件可以实现一些简单的资源合并和图像合成。实现复杂的复用、切换、音频调整和合成。你需要一个专业的播音员。一个简单的指挥站可能如下所示：

有点中间是这样的：

参考资料：

lnmp一键安装包

lnmp安装nginx配置站点启动

让我们HTTPS证书

lnmp组件及安装位置

rtmp模块参数解读

供 HLS 按需使用的 TS 切片文件