3. 其它

这是我的 Windows Fluent 风格的 Video-js UI，不过记得修改它，里面引用了 Segoe Fluent 图标字体。

4. 特殊情况

Q：卡爆了！
A：如果是网络撑不住，那么你只能降低视频分辨率和质量；如果 CPU 爆满，提前转换格式；如果是硬盘占用率告急，除了降低视频分辨率和质量、转换格式以外，你还可以尝试把视频分片放到内存盘里面（如果你正在用 Windows），大小大约为视频碎片最大大小×(文件夹内视频碎片最大文件数量+1)+额外的20MB（如果将 Nginx 也放到内存盘里面的话）。
Q：假如有人 DoS 我怎么办？
A：如果路由器有防护功能，二话不说赶紧打开；然后考虑要不要额外开防打服务；如果这样都扛不住了，那没办法了，等着电脑崩溃然后收巨额账单吧，那么我们还有最后的招数！
1.拔。
2.

3.

（Windows 安全中心\防火墙和网络保护\某个网络）

さらば限界少女 是的，这是必须的。
不过这个也不难，之后我会讲讲方法。
今天我已经测试过了，观看人数少的话是完全扛得住的。（我用的甚至是一台笔记本，所以完全不用担心性能问题，除非奔腾啥的）

さらば限界少女 存储前端网页的服务器

这个？或许 GH Pages 吧（
当然我是直接把网页和直播文件放一个服务器里面了……

前面我们已经基本提到了完成一个直播的思路，但光是这些东西很可能还是要花一些功夫到网上去查别的资料，所以补充一些细节吧。

5. 服务器

Nginx 可以帮助我们完成一个简单的服务器。
首先，下载一个 Nginx，然后启动，你就获得了一个服务器。浏览器打开 127.0.0.1（localhost）你就可以看到 Nginx 的欢迎页面。不过如果你直接把这个粗糙的东西拿去作直播服务器，那是绝对不行的。必须修改其配置文件以便提升性能。

Worker_processes & Worker_connections

我参考的原文章找不到了，这篇或许也可以参考下：https://www.jianshu.com/p/c1045f374442

add_header Cache-Control no-cache;

按照我的理解，没有缓存的直播开始时到直播结束后刷新网页都可以立即获得更改(?)

如果要加入 IPv6 的支持……

Before：
    server {
        listen       80;
        server_name  localhost;

After：
    server {
        listen       80;
        listen       [::]:80;
        server_name  localhost;

在浏览器中键入[::1]即可看到效果。

现在，即使在内网打开您的电脑的 IP（v4），应该也能看到效果。
要让外网也能看到这个服务器需要进一步的操作，可能是内网穿透，也可能是其它方法，这些就看您的喜好了。

在外网使用 IPv6？

如果没有公网 IPv4，也不想搞内网穿透等等方式开 IPv4 服务器，那么纯 IPv6 服务器是一个替代方案。
（IPv4+v6 双栈也一样）
优点：
IPv6 解决了 IPv4 短缺的问题，因此 IPv6 是直接公网的，只要运营商支持，你可以在全球任何地方访问你的 IPv6，也就不需要内网穿透了，直接买一个域名绑上你的 IP 即可。
缺点：
仍然有人无法访问 IPv6，所以出于保证可访问性，现在还是以 IPv4 为主（最多搞双栈）。
当为你的路由器打开 IPv6 支持后，为你的电脑配置好一切，然后用你的手机的流量（手机流量通常默认支持 IPv6）访问你的电脑的 IPv6，一旦成功，就无需其它配置了。
关于如何配置你的服务器与路由器以支持 IPv6 的详细信息，请自行查询。

其它的就是自定义了，可以加一些 Referrer 限制之类的。

6. 前端网页与 Video-js

FFmpeg 一旦生成 m3u8，你就可以开始直播了。把 m3u8 的路径放在前端网页里面，然后把一切都交给服务器和 FFmpeg 就行了。
但等一下，你以为写一个<video>标签然后src="<m3u8 文件>"就万事大吉了吗？

等等，别走啊？

HLS can be used with a JavaScript library in browsers that doesn't support it natively as long as they support Media Source Extensions.

实际上用一个插件就可以了

Video-js

官方和网上都有不少信息，我就不提了，有兴趣的可以详细的自定义一番~
这里我只提一点
video-js 的播放框是很难调整大小的，一般用 iframe 把它包起来以便调整大小。
Microsoft Event 用了这种播放器，可以去那里借鉴一些哦
秀一个我的效果：

7. rtsp、rtmp & HLS

如果你在互联网上查找了相关信息，你应该会发现大多数文章都提到了 rtsp 或 rtmp——这是什么呢？
实际上，它们与 HLS 都是流媒体格式。

RTSP （Real-Time Stream Protocol）由Real Networks 和 Netscape共同提出的，基于文本的多媒体播放控制协议。RTSP定义流格式，流数据经由RTP传输；RTSP实时效果非常好，适合视频聊天，视频监控等方向。

RTMP（Real Time Message Protocol） 由 Adobe 公司提出，用来解决多媒体数据传输流的多路复用（Multiplexing）和分包（packetizing）的问题，优势在于低延迟，稳定性高，支持所有摄像头格式，浏览器加载 flash插件就可以直接播放。

—— https://www.cnblogs.com/biao-wu/articles/13064243.html

正因为 Rtmp 通过 Adobe Flash Player 进行播放，因此早些年它十分主流。但现在 Flash 死了，所以……我现在也不太知道 Rtmp 应该怎么在浏览器播放（

HLS 则是我们前面一直在讲的，由 Apple 开发的流媒体技术。因为浏览器支持性较好，所以大多数主流网站使用此技术。

网上一般提供的方法（基本思路）

视频源（或 Rtsp 流）FFmpeg（或其它直播软件）Rtmp 流带 Rtmp 支持的服务器接收流并转流客户端（前端）

被选用的原因：

• 直播程序（非 FFmpeg）不支持向本地存放视频流。
• 存放并推送视频流的服务端与直播源设备不是同一个。
• 需要进行 Rtsp 到 Rtmp 转流（通常是摄像头等设备）。
• 人云亦云（希望不会是这样）。

通常而言，直播程序更倾向于往另一台服务器推流而不是存放到本地；存放并推送视频流的服务端与直播源设备不是同一个时，先保存到本地再推向另一个服务器影响速度；Rtsp 的兼容性很差，通过转流为 Rtmp，可以提高兼容性（这个跟 HLS 可以二选一）。这时，使用这个方案是好的方法。
但为什么会有其它方案呢？
来看看另一个方案的流程（HLS）：

视频源（或 Rtsp 流）FFmpeg储存到本地服务器（同一台设备）客户端（前端）

这之间区别在何处？
方案一：视频被转换成 Rtmp 流，又被服务器转储为文件然后发送给前端；
方案二：视频直接保存到本地，发送给前端；
看到了吗？步骤减少了！

另：实际上我并不了解多余的转换过程期间发生了多少效率损失，但无论多还是少，我们还是要尽量节省的。方案一有它存在的意义，本人并没有反对这种方式。

详细一点说，通过配置服务器让它包括视频流碎片存放文件夹，那么服务器就可以一边存放网页，一边让前端读取同一个服务器内的视频流，而无需服务器自行转储视频流。就是这样。
即使是进行 Rtsp 到 Rtmp 转流，也不一定需要转成 Rtmp，直接转储到本地是同样可以的。

总结：
如果由于条件限制，无法直接存为本地视频流，Rtmp 方式更好；反之则 HLS 本地直播流为首选。

接下来就不是直播技术本身的内容了，可选择性阅读。

8.端口

如果你真的直接把你的 IP 暴露出去了，那可能是危险的。有些运营商会潜伏在你的网络的常用端口上监视网络活动，一旦他们监视到异常情况，就可能会封锁端口。也有些运营商会直接使用防火墙拦截常用端口。虽然有可能可以拆掉这个防火墙，但难度很高甚至不可行。这时可以更改成一个不常用的端口，以便绕过这种封锁。

端口范围

端口范围是 1~65535，还是很大的。要更改端口，在 Nginx 上可以这么做：

    server {
        listen       80;
        listen       [::]:80;
        server_name  localhost;

（将上面所有的“80”改为你想要的端口号）

端口限制

不过，这不意味着你可以随便设置。在 Edge 和 Chrome 浏览器上，会拒绝访问“不安全的”端口。
它们是：

  1,    // tcpmux
  7,    // echo
  9,    // discard
  11,   // systat
  13,   // daytime
  15,   // netstat
  17,   // qotd
  19,   // chargen
  20,   // ftp data
  21,   // ftp access
  22,   // ssh
  23,   // telnet
  25,   // smtp
  37,   // time
  42,   // name
  43,   // nicname
  53,   // domain
  77,   // priv-rjs
  79,   // finger
  87,   // ttylink
  95,   // supdup
  101,  // hostriame
  102,  // iso-tsap
  103,  // gppitnp
  104,  // acr-nema
  109,  // pop2
  110,  // pop3
  111,  // sunrpc
  113,  // auth
  115,  // sftp
  117,  // uucp-path
  119,  // nntp
  123,  // NTP
  135,  // loc-srv /epmap
  139,  // netbios
  143,  // imap2
  179,  // BGP
  389,  // ldap
  465,  // smtp+ssl
  512,  // print / exec
  513,  // login
  514,  // shell
  515,  // printer
  526,  // tempo
  530,  // courier
  531,  // chat
  532,  // netnews
  540,  // uucp
  556,  // remotefs
  563,  // nntp+ssl
  587,  // stmp?
  601,  // ??
  636,  // ldap+ssl
  993,  // ldap+ssl
  995,  // pop3+ssl
  2049, // nfs
  3659, // apple-sasl / PasswordServer
  4045, // lockd
  6000, // X11
  6665, // Alternate IRC [Apple addition]
  6666, // Alternate IRC [Apple addition]
  6667, // Standard IRC [Apple addition]
  6668, // Alternate IRC [Apple addition]
  6669, // Alternate IRC [Apple addition]

（所以6666没得玩了）
至于 Firefox，则将80以外的端口全部当做“不安全的”端口。
尽管可以更改浏览器设置来覆盖这种行为，但这无疑是复杂且不安全的。
因此，为了用户体验，对端口的设置需要谨慎考虑。

9.对直播的个人见解

不建议在直播刚好开始的时候开始直播，因为在直播刚好开始的时候进入直播是不可能的，这就意味着用户可能会错过一些内容。推荐的做法是在直播时间开始前就开始直播，以一些“即将开始”的内容填充。这样，用户可以提前打开直播并等待，减少了错过内容的可能性。
同样的原因，也建议提前开放直播页面，甚至是直播开始前（在上面标注直播开始的时间）。

做一个什么样的“即将开始”的内容比较好？

个人比较喜欢微软的倒计时+音乐，而且制作也简单，可以考虑考虑哦~

@"sasuhina"#p44250 事实上，这里并不欢迎顶帖（哪怕是所谓的挽尊），而且还是无效回复。

整个主页全是你顶上来的回复！！！[tieba=pen]

还请仔细阅读此论坛的导航帖，了解相关规定。

[VTpwj][€ИЁĎĢШ !] 至少是（被）删除了
不过我真的、真的、真的怀疑，导航帖就是置顶的，他们真的。。。