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