波仔
🎬 第七章 流媒体开源库简介
📄 一句话概括

ZLMediaKit 的卖点是「一进多出」：一路流推上去，五种协议同时能看。 它把「协议转换」这件事做成了标配。

📝 本节和前面几节的关系

7.5 讲 SRS，这一节讲定位相近的另一个。 7.7 开始整章讲 WebRTC——那是网页直播的底层。

一、它解决的核心问题

同一路流，同时提供 RTSP、RTMP、HLS、HTTP-FLV、WebRTC 五种出口。 推上来一次，五种播放器都能看。

这件事看起来简单，实际很难： 五种协议的封装格式完全不同，还要共享同一份解码后的帧。 所以它内部是「一份媒体数据、多个协议出口」的结构。

这个结构带来的最大好处是「不用转码」： 五种出口共享同一路编码数据，只是换封装。 如果要转码，CPU 立刻就顶不住了。

二、一进多出的成本

按 100 人看 2048 kbps 一路流算： RTSP 200 Mbps、RTMP 204、HLS 216、HTTP-FLV 202、WebRTC 208。

开销的差别全在封装上： HLS 最高，因为切片有额外头部与重复的表； RTSP 与 HTTP-FLV 最低，因为基本是裸封装； WebRTC 略高，因为要加密，还有 SRTP 的头。

注意这只是「封装开销」，不包含 CDN 的成本差。 真要比总成本，HLS 反而常常最便宜——因为它能被缓存。 而 HTTP-FLV 与 WebRTC 都很难缓存，每个观众都要占源站或边缘的出口。

三、它适合什么场景

① 多端同时看：PC 用 FLV、手机用 HLS、网页低延迟用 WebRTC。 一套服务全包，不用为每种端单独部署。 ② 协议迁移期：老设备只认 RTSP、新设备要 WebRTC， 它可以同时提供，不用一次切完。 ③ 内网与边缘：单机就能跑，资源占用低，适合放在边缘节点。

它相对 SRS 的差别主要在生态与定位： SRS 更偏「直播平台」的整体方案，配置项多、集群能力成熟； ZLMediaKit 更偏「媒体能力组件」，接口简单、嵌入方便。 选哪个更多看团队熟悉哪一个。

四、动手 Demo：ZLMediaKit——一进多出，协议随便挑

先把「一进多出」这件事讲清楚，再按五种协议算封装开销。 最后指出一个反直觉的结论：HLS 的封装最贵，但总成本常最低。

base, viewers = 2048, 100
protos = [("RTSP", 1.00), ("RTMP", 1.02), ("HLS", 1.08),
          ("HTTP-FLV", 1.01), ("WebRTC", 1.04)]
print("协议        相对开销   %d 人出口 Mbps" % viewers)
for name, k in protos:
    print("%-10s  %.2f        %.0f"
          % (name, k, base * k * viewers / 1024.0))

print()
print("封装差额最大只有 %.1f%%"
      % ((max(k for _, k in protos) / min(k for _, k in protos) - 1) * 100))

实跑输出：

--------------------------------------------------------------------
ZLMediaKit——一进多出，协议随便挑
--------------------------------------------------------------------
**① 它解决的核心问题**

  **同一路流，同时提供 RTSP、RTMP、HLS、HTTP-FLV、WebRTC 五种出口。**
  **推上来一次，五种播放器都能看——这就是「媒体服务器」的价值。**

**② 算「一进多出」的转发成本**

  协议         相对开销     100 人时出口 Mbps
  -----------------------------------------------
  RTSP         1.00         200
  RTMP         1.02         204
  HLS          1.08         216
  HTTP-FLV     1.01         202
  WebRTC       1.04         208

  **开销的差别全在封装上：**
  **HLS 最高，因为切片有额外头部与重复的表；**
  **RTSP 与 HTTP-FLV 最低，因为基本是裸封装。**
  **WebRTC 略高，因为要加密，还有 SRTP 的头。**

  **注意这只是「封装开销」，不包含 CDN 的成本差。**
  **真要比总成本，HLS 反而常常最便宜——因为它能被缓存。**

五种协议的出口带宽几乎一样，差的那几个百分点全在头上。 所以选协议不该看「省不省字节」，要看缓存能力与延迟。 HLS 贵 8%，但能被 CDN 无限缓存，总账反而是最省的。

30 秒实验

  1. 把观众数改成 1000，看五个出口——都过 2000 Mbps，这就是「多协议同时在线」的真实压力。
  2. 把 WebRTC 的相对开销改成 1.20，想想为什么可能更高——如果要做 SRTP 加密加 ICE 保活，开销确实会上去。
  3. 把 HLS 那一行删掉，看总开销降多少——降得很少，说明封装开销不是选型依据。

常见误区

  1. 「一进多出要转码」——不转码，多个出口共享同一份编码数据。
  2. 「协议越多越费带宽」——封装差别只有百分之几。
  3. 「ZLMediaKit 与 SRS 完全一样」——定位不同：组件与平台。
自测三问（点开对答案） 1. 「一进多出」的关键是什么？ —— **一份编码数据、多个封装出口**，所以不需要转码。 2. 五种协议的出口带宽差多少？ —— **只差百分之几**，全在封装头上。 3. 为什么 HLS 反而常是最省的？ —— **它能被 CDN 长期缓存**，源站出口压力不随观众数增长。

相关笔记