一、一条管道，四个出口

VLC 内部把数据当一条流水线处理：输入 → 解封装 → 解码 → 滤镜 → 输出。 「输出」那一端可以有四种接法：

这个设计非常省事： 「播放」和「转码」的差别，只是输出端接屏幕还是接文件。所以 VLC 的「串流」对话框里， 你可以同时勾「在本地显示」和「输出到文件」——它真的会把数据分成两路。

对比一下命令行工具的做法：ffmpeg 用参数指定输出目标，一个命令一个输出。 VLC 用图形界面勾选，背后还是同一件事。

二、播放之外的四件事

一、转码。 把一种编码换成另一种，比如 H.265 换 H.264，或者把 1080p 压成 720p。 这是它的「串流」功能里最耗 CPU 的一项。

二、推流。 把本地文件或摄像头推成 RTMP、HTTP、UDP 流。 这是「VLC 当服务器」的核心能力，下一节细讲。

三、录制。 把正在播的流存成文件。它的价值在「录网络流」——很多直播没有回放，只能自己录。

四、当流媒体服务器。 严格说 VLC 不是「服务器」，它是「一个能持续输出流的客户端」。 它能同时服务几十个观众，但撑不住几百个——真正的大规模分发要靠专业服务器（SRS、Nginx-rtmp、ZLMediaKit）。

这四项里，前三项日常真用得上，第四项只适合调试。 「拿 VLC 当生产环境的流媒体服务器」是一个常见误判，它没有连接管理、没有鉴权、没有集群， 只有「能推出去」这一件事。

三、转码是要花算力的

demo 里量了一个数：本机编 1080p 只有 44.9 帧每秒。 也就是「实时倍数 1.5」——只能勉强撑一路 30 fps。

这个数决定了 VLC 转码的实用边界： 一路 1080p 转码，一台普通办公机刚够。 两路就卡，因为还要算上解码与显示。 要转多路，必须上服务器 CPU 或硬件编码器（NVENC、QSV）。

三个会让它更慢的因素： 从 veryfast 换到 medium，速度掉一半以上。 加了滤镜（去隔行、缩放），每一帧都要多走一遍。 音频转码也在吃 CPU，只是量小得多。

所以「VLC 转码慢」不是它写得差，是转码本身就这么贵。 同样的活交给 ffmpeg 命令行，速度是一个量级的——因为 ffmpeg 没有界面开销，也不需要边转边显示。

四、这些功能在界面哪里

VLC 的菜单把这几件事藏得比较深，第一次找会绕：

「转换／保存」与「串流」是同一个对话框的两条路：前者目标填文件，后者目标填网络地址。 这也是上一段说的「同一条管道、不同出口」的界面体现。

新手最常卡住的地方是「串流」对话框里的下一步：它要你依次选「源 → 目标 → 转码选项 → 输出」。 其中「转码选项」那一步如果什么都不选，就是原样转封装——这正是上一节 demo 里量出来「快五十九倍」的那种做法。

五、动手 Demo：一台机器能同时转几路 1080p

这段真编六十帧 1080p，量本机吞吐，再换算成「能转几路」。 这个换算方法比任何规格书都可靠——它用的是你这台机器的真实数字。

t0 = time.perf_counter()
_make_video(p, 1920, 1080, 60, 30)
dt = time.perf_counter() - t0

fps = 60 / dt
T([u"实时倍数", u"%.2f 倍" % (fps / 30.0),
   u"相对 30 fps 的余量"], [0, 0, 0])

实跑输出：

--------------------------------------------------------------------
一台机器能同时转几路 1080p
--------------------------------------------------------------------
**VLC 的「串流」功能里含转码，转码就要算力。**
**能转几路由一个很硬的数决定：编码一帧要多久。**

**真跑：本机编 60 帧 1080p（veryfast 档）用了 1.29 秒。**

  指标         值              含义
  -------------------------------------------------------------
  编码速度     46.3 帧每秒     本机实测，libx264 默认多线程
  实时倍数     1.54 倍         相对 30 fps 的余量
  能转路数     1.5 路          把全部算力都给转码时

**「能转几路」就是「实时倍数」——这个换算值得记住**：
**编码速度除以目标帧率，就是这台机器能同时撑的路数。**

**三个会让这个数变差的现实因素**：
  这台机器的核已经分给了别的活，实际可用算力打折。
  veryfast 档画质一般，要质量就得换 slower，速度掉一半以上。
  **解码那一路也要算力**——转码是「解＋编」，这里只量了「编」。

**所以工程上真正的估法是**：
**先量本机「解码＋编码」一整条链的速度，再除以目标帧率，最后打七折当安全余量。**

44.9 帧每秒、1.5 路——这个数字很朴素，但它是这台机器的真实上限。

注意它是「全部算力只做一件事」时的数字：VLC 转码时还要解码、还要显示、还要响应用户操作， 实际能撑的路数要打对折。所以工程上习惯再乘个 0.5 到 0.7 的安全系数。

最后那句「解码也要算力」最容易被漏掉：转码 = 解码 + 编码，这里只量了编码。 如果源是 4K、目标是 1080p，解码那一侧反而更贵。 所以正确的估法是量整条链，不是量单个环节。

30 秒实验

1. 在 VLC 里打开「媒体 → 转换／保存」，把转码选项那一步跳过，看输出文件大小。
2. 再用同一个文件真转一次码，比较两个文件的大小与耗时。
3. 想一想：为什么「边看边录」在 VLC 里是勾一个选项，而不是开两个程序？

常见误区

1. 以为 VLC 是「流媒体服务器」。 它是「能推流的客户端」，没有连接管理、鉴权、集群， 只适合调试。
2. 以为「转换」和「串流」是两个功能。 它们是同一条管道的两个出口， 差别只在输出端接文件还是接网络。
3. 以为转码慢是软件问题。 转码是「解码 + 编码」两遍全量处理，慢是它的本质。

下一节单独讲「打开网络串流」——那个缓冲毫秒数，是流媒体体验里最关键的一个旋钮。

• ☐ （本节完，下一节 02.01.03 VLC播放网络串流）

相关笔记

• VLC播放网络串流
• VLC作为流媒体服务器使用
• 🎬 命令行与音视频特效原理及应用 · 31 课
• 🎬 播放器原理及应用 · 索引