检测到论坛CSS可能没有正确加载,如出现排版混乱请刷新重试。

We detected that the CSS might not be loaded correctly. If the website displays abnormally, Please refresh and try again.

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

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 用了这种播放器,可以去那里借鉴一些哦😏
秀一个我的效果:

然后我就不记得还有什么了,如果按照这里的东西还有什么问题的话,请告诉我以便让我想起来[tieba=huaji]

    加个精(((
    我是选择安装一个nginx-rtmp的docker容器,配置好端口映射就能直接用obs推流了(

      焊锡锡 我还没写完呢😅
      您这种方案倒是网上最常见的,到时候会顺便和另一种方法一起讲一讲

      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插件就可以直接播放。

      正因为 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.对直播的个人见解

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

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

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

      10 天 后

      10.扩展阅读

      ffmpeg 低延迟高性能推流方案 - 简书
      https://www.jianshu.com/p/7c784bbf2df8

      使用ffmpeg搭建HLS直播系统 - Tocy - 博客园
      https://www.cnblogs.com/tocy/p/using-ffmpeg-build-hls-live-system.html

      11.感谢&结束语

      感谢所有本笔记中引用的链接的作者(可能某些我看过的链接忘记了提到,敬请谅解)
      笔记已结束,希望各位能够成功地实现自己的直播。
      不过——

      DaleZ 如果按照这里的东西还有什么问题的话,请告诉我以便让我想起来[tieba=huaji]

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

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

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


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

        4 天 后

        [VTpwj][€ИЁĎĢШ !] 这是flarum的置顶机制(
        即:看完了置顶帖帖子就会沉下去回到它原来的时间线上
        所以,理论上只要我一按全部标记已读,导航贴就能“瞬间消失”

          © 2025 wvbCommunity 管理团队

          删封申诉 | 知乎专栏 | 状态监控 | 用户协议(EULA) | 隐私政策

          本站文章除其作者特殊声明外,一律采用CC BY-NC-SA 4.0许可协议进行授权,进行转载或二次创作时务必以相同协议进行共享,严禁用于商业用途。