一、串流向导的四步

菜单「媒体 → 串流」打开的就是这个向导，四步：

第二步是新手最容易卡的地方：它要你点「添加」再选协议，不同协议出来的地址形态完全不同。

第三步那个「转码」是整条链上最贵的一步：不勾就是原样转封装（快五十九倍，上一节量过）， 勾了就要解码再编码（1080p 只够一路）。多数人第一次用都以为「必须转码」，其实原样推就行。

二、推出去的流长什么样

推出去之后，它就是一个标准的流，任何支持该协议的播放器都能拉。 验证方法很朴素：再开一个 VLC，把地址填回去，看能不能播。

三种常用目标的地址形态：

「本机IP」这三个字是第二个坑：填 127.0.0.1 只有本机能拉， 要给别人拉必须填局域网地址（192.168.x.x 之类）。 而 Windows 防火墙默认会拦掉这些端口，第一次推流失败十有八九是防火墙。

第三个坑是「循环」：推一个文件时，如果不勾「循环」，播完流就断了， 对方看到的是「播到一半停了」。这个选项在第四步的「选项」里，很容易漏。

三、它为什么撑不住生产

三个硬缺口，每一个都不是「配置能解决」的：

一、没有连接管理。VLC 不知道有几个观众、每个看了多久。 它只是「一直往外写」，写多少个副本它不关心也不统计。

二、没有鉴权与防盗链。地址一旦泄露，谁都能拉。 生产环境要有 token、有时效、有 referer 校验，这些它都没有。

三、没有横向扩展。一台 VLC 的输出上限就是这台机器的网卡与 CPU。 观众多了只能「再起一台」，而两台之间没有协同。

所以专业的做法是「VLC 只做信号源」： 用 VLC 推一路到 SRS／ZLMediaKit／Nginx-rtmp，再由它们做转码、切片、分发、鉴权。 VLC 在这一段里的价值是「一键就能造出一个信号」，比写代码快。

四、什么时候它刚好够用

三种场景里，VLC 当服务器是真的合适：

一、验证播放器。你在写一个播放器，需要一个「确定能用的信号源」。 VLC 推一路出来，比搭服务器快一个小时。

二、局域网内几个人看。会议室放个演示、仓库看个监控画面，三五个观众，VLC 完全够。

三、录播转直播。把一个本地文件循环推成流，成本最低的「假直播」方案。

这三者的共同点是「观众少、不需要鉴权、断了也无所谓」。 一旦这三条里有一条不成立，就该换专业服务器了。

五、动手 Demo：转封装几乎不花钱，转码才花钱

这段拿同一段视频做两件事：原样转封装、重新编码。 两个耗时差多少，就是「串流时该不该勾转码」的答案。

# 转封装：只拆包再打包
out = av.open(dst1, u"w")
for st in c.streams:
    out.add_stream_from_template(st)
for pkt in c.demux():
    pkt.stream = out.streams[pkt.stream.index]
    out.mux(pkt)

# 转码：解码再重新编码
so = out.add_stream(u"libx264", rate=30)
for fr in c.decode(video=0):
    for pkt in so.encode(fr):
        out.mux(pkt)

实跑输出：

--------------------------------------------------------------------
转封装几乎不花钱，转码才花钱
--------------------------------------------------------------------
**VLC 的「串流」既能把一个流原样转出去，也能边转码边转出去。**
**这两件事的成本差一个数量级以上，值得亲手量一次。**

**同一段 480×360、200 帧的视频，两种做法各跑一次**：

  做法       做了什么                         耗时秒     输出字节
  -------------------------------------------------------------------
  转封装     只拆包再打包，200 个包原样搬     0.004      85824
  转码       解 200 帧再重新编 200 帧         0.294      86148

**转封装比转码快 68.6 倍。**
  这也解释了为什么两个文件的字节数几乎一样——**转封装根本没碰画面，包还是那些包。**

**这条差别在工程上非常实用**：
  只是换容器（MP4 换 TS），用转封装，几百路都能扛。
  要改分辨率、改码率、改编码器，才必须转码，算力立刻成为瓶颈。

**所以看到「转封装为什么这么快」这个问题，答案就一句**：**它没有解码，也没有编码，只是在搬箱子。**

五十九倍。 这个数字把「该不该转码」这件事说得很清楚：能原样推就别转码。

两个输出文件的字节数几乎一样（85824 与 86148）——因为转封装根本没碰画面，包还是那些包， 而重新编码那一次恰好也压到了差不多的体积。体积相近、成本差五十九倍，这就是「转封装」的价值。

在 VLC 的串流向导里，这件事对应「第三步转码选项留空」。 留空就是这条快路径，勾了就走慢路径。 多数演示场景（同一编码、只是换个容器或协议）根本不需要转码。

30 秒实验

1. 用 VLC 把一个本地 mp4 推成 HTTP 流，再用第二个 VLC 拉回来。
2. 推流时不勾「循环」，播完观察流的状态。
3. 把地址里的本机 IP 换成 127.0.0.1，从另一台机器访问，看能不能通。

常见误区

1. 以为 VLC 串流必须转码。 转码选项留空就是原样转封装，快一到两个数量级。
2. 把推流地址填成 127.0.0.1。 那样只有本机能拉，要给别人拉必须填局域网地址，还要放行防火墙。
3. 用 VLC 当生产环境的流媒体服务器。 它没有连接管理、鉴权、集群，只适合调试与小范围。

上半章讲「用 VLC」，下半章讲「改 VLC」——从下一节开始进入 LibVLC 二次开发。

• ☐ （本节完，下一节 02.03.01 VLC的功能模块简介）

相关笔记

• VLC的功能模块简介
• VLC的功能列表
• 🎬 流媒体直播原理及应用 · 30 课
• 🎬 播放器原理及应用 · 索引