波仔
🎬 第一章 FFmpeg入门简介
📄 一句话概括

Linux 上装 FFmpeg 有三条路：apt、静态包、源码编译。 三条路装完都能敲 ffmpeg，但能力天差地别——差别在谁替你决定编译开关。

📝 本节和前面几节的关系

1.2.1 讲了 Windows 那套解压加 PATH，这一节换到包管理器世界。 1.2.3 讲 macOS，思路和这一节一样。

一、三条路，三句实话

先把结论摆出来，再讲为什么：

装法 一条命令 优点 代价

发行版包 apt install ffmpeg 最快，依赖自动解决 能力被裁过 官方静态包 下 tar.xz 解压 能力最全，不动系统 要手动放 PATH 源码编译 ./configure && make 完全自己定 慢，依赖得自己凑

新手直接走第一条，别犹豫。 等你遇到「这个编码器怎么没有」的时候，再回头看第二、第三条。

第三条不是给「想装最新版」的人准备的。 最新版下静态包就有，编译的意义只在于改开关—— 比如只要 LGPL 的，或者要塞进一个没有包管理器的容器里。

二、apt 装的那份为什么常常缺东西

不是打包的人偷懒，是两条硬约束压着：

约束 导致的结果

许可证审计：不能带 GPL 组件 x264、x265 默认关掉 依赖树不能炸：不能随便加外部库 freetype、libass 这类也常常不带

所以 apt 装完的典型表现是： 能解码几乎所有格式，但要压 H.264 就得去装另一个名字更长的包。

这一条在 Debian 系上有个专门的解决方法： 换一个开了 GPL 的构建，或者直接用官方静态包覆盖掉 apt 那份。 覆盖的时候注意 PATH 顺序——which -a ffmpeg 能看到有几份。

三、静态包的用法

官方静态包最省心的用法是「放到用户目录里，改 PATH」，不动系统目录：

步 做什么 为什么这么放

1 解压到 ~/opt/ffmpeg 用户目录不需要 sudo 2 把 ~/opt/ffmpeg/bin 加进 PATH 只影响自己的账号 3 hash -r 清掉命令缓存 bash 会记住旧路径 4 which -a ffmpeg 核对 确认生效的是新的那份

第 3 步容易被忽略：bash 会把「命令名到路径」的映射缓存起来。 PATH 改了但没清缓存，敲 ffmpeg 打出来的还是老的。hash -r 就是清这个。

这个位置的另一个好处是：系统升级、换 apt 源、删包，都不会碰到它。 坏处是别的用户用不到——多人共用一台机器时才需要考虑装到 /opt 下。

四、源码编译的四步

真要走这条路，四步，一步都不能省：

步 命令 产出了什么

1 ./configure --prefix=... --enable-... config.h 与 Makefile 2 make -j$(nproc) 七个 .so 与三个 exe 3 make install 装到 prefix 指定的目录 4 ldconfig 或改 LD_LIBRARY_PATH 让系统找到新的 .so

第 3 步不写 --prefix 会装到 /usr/local，小心和系统那份打架。 养成习惯：自己编的东西一律 --prefix=$HOME/opt/ffmpeg，随时能删干净。

第 1 步最容易失败的报错是「找不到某个库」， 那一刻真正缺的往往不是那个库本身，是它的开发包（名字带 -dev 或 -devel）。 所以 configure 报错要读最后几行，它会直接告诉你缺什么。

五、动手 Demo：三种装法，差在「谁替你决定开关」

沙箱是 Windows，跑不了 apt。所以这一段只做两件能做到的事： 一是把「外挂组件的取舍」算清楚，二是把「装完怎么查」列成可执行的清单。

import av

libs = sorted([c for c in av.codecs_available if c.startswith(u"lib")])
gpl = [c for c in libs if c in (u"libx264", u"libx264rgb", u"libx265")]
print(u"外挂组件", len(libs), u"其中 GPL", len(gpl))

c = av.codec.Codec(u"h264", u"w")
print(u"写 h264 要编码器，实际拿到", c.name)

print(u"codecs", len(av.codecs_available))
print(u"formats", len(av.formats_available))
print(u"filters", len(av.filter.filters_available))

实跑输出：

--------------------------------------------------------------------
Linux 装 FFmpeg——三种装法，差在「谁替你决定开关」
--------------------------------------------------------------------

**① 三种装法摆在桌上，差别不在命令长短**

  装法           一条命令                 谁决定编译开关
  ----------------------------------------------------------
  发行版包       apt install ffmpeg       发行版的打包者
  官方静态包     下 release 的 tar.xz     FFmpeg 官方
  源码编译       ./configure && make      你自己

**② 为什么 apt 装的那份常常「缺东西」**

**发行版的打包者要顾两件事：许可证审计，和依赖树不能炸。**
**于是 GPL 组件默认关掉，要开就单独打个包，或者让用户自己编。**
**落到用户身上就一句话：apt 装完能解码，但压不了 H.264。**

**这不是猜的，用本机这 13 个外挂组件反推就清楚：**

  类别             数量     少了它，能干的事
  --------------------------------------------------------
  外挂组件总数     13       这 13 个全都在本机构建里
  其中 GPL 的      3        少了就不能压 H.264 / H.265
  其余非 GPL       10       少了还能用别的方式绕

**本机写 h264 要编码器，拿到的是 libx264——它就是三个 GPL 组件之一。**
**一个按 LGPL 政策裁过的构建，这一列会是空的。**

**③ 装完怎么一条命令查清楚自己有没有**

  你想知道         敲什么                          看什么
  --------------------------------------------------------------------------
  带不带 x264      ffmpeg -encoders | grep 264     有没有 libx264
  带不带 x265      ffmpeg -encoders | grep 265     有没有 libx265
  编了哪些开关     ffmpeg -version                 第二行的 --enable-xxx
  认多少种格式     ffmpeg -formats | wc -l         能不能读出几百行

**④ 沙箱里只能给出这些，说清哪部分是实测**

**上面所有数字都来自本机真实的这个构建：557 个 codec、414 个格式、468 个滤镜。**
**但 apt 那一步没法在这儿跑——沙箱是 Windows，没有 apt。**
**所以「发行版会裁掉 GPL 组件」这条是按打包政策推的，不是在这儿验出来的。**
**想自己验，就在 Linux 上跑 ffmpeg -version 看第二行有没有 --enable-gpl。**

第一张表把三条路的取舍摆清楚：快、全、自由，三者只能挑两个。

第二张表把「apt 会裁掉什么」量化了：13 个外挂组件里 3 个是 GPL。 这 3 个正是压 H.264 / H.265 的唯一选择，裁掉就等于不能编码。

第三张表一行就够说明问题：本机写 h264 要编码器，拿到的是 libx264。 一个按 LGPL 政策裁过的构建，这一列会是空的。

第四节把话说清楚了：这些数字是实测的，但 apt 那一步不是。 沙箱里没有 apt，「发行版会裁 GPL」这条是按打包政策推的—— 想自己验，就在 Linux 上敲 ffmpeg -version 看第二行有没有 --enable-gpl。

30 秒实验

  1. 数路径：which -a ffmpeg，看打出几行。两行以上说明装了两份，生效的是第一行那个。
  2. 查开关：ffmpeg -version | head -3，第二行的 --enable- 列表就是能力清单。没 --enable-gpl 就不能压 H.264。
  3. 验缓存：改完 PATH 立刻敲 ffmpeg -version，如果还是老版本，敲 hash -r 再试。这一条能省掉很多「明明改了却没生效」的困惑。

常见误区

  1. 以为 apt 装的和官网下的是同一个东西。同一个项目，不同构建。apt 那份按发行版政策裁过，通常不能编码 H.264。
  2. 改完 PATH 不 hash -r。bash 缓存了命令路径映射，不清缓存的话，敲的还是老那份。which -a 能看到真实情况。
  3. 源码编译不带 --prefix。默认装到 /usr/local，和系统包管理器的那份混在一起，将来想删都删不干净。
自测三问（点开对答案） 1. 为什么 Debian 系的 ffmpeg 包通常不带 x264？ —— 因为打包政策要求避免 GPL 传染。x264 是 GPL，编进去会让整个包的许可证变复杂，所以默认关掉，需要的话另行处理。 2. 静态包解压到 ~/opt/ffmpeg 后，PATH 改了，敲 ffmpeg 还是老版本，为什么？ —— bash 的命令缓存没清。敲 `hash -r` 清掉，或者直接 `~\/opt/ffmpeg/bin/ffmpeg` 用全路径验证。 3. configure 报「找不到 libx264」，该装什么？ —— 装 x264 的开发包（Debian 系是 `libx264-dev`，RedHat 系是 `x264-devel`）。configure 要的是头文件和 .so 的软链，不是那个可执行文件。

相关笔记