FFmpeg 自动安装脚本：从源码编译到静态构建的完整指南

简介这是一个面向 Linux 用户的 FFmpeg 快速部署脚本尤其适合在 Amazon Linux 等服务器环境中使用目标是让不熟悉源码编译或依赖处理的用户通过一条命令完成安装。压缩包内仅包含 1 个 sh 脚本体积约 2KB下载后赋予执行权限即可运行对磁盘和网络占用都极小。脚本会自动完成更新系统软件源、安装所需依赖库、拉取最新源码、配置编译选项、执行编译安装并清理临时文件整个流程对使用者透明几乎无需手动干预。已有 558 人学习下载适合不熟悉编译安装的开发者、运维人员以及需要在纯命令行环境下快速部署多媒体处理能力的读者。借助该脚本用户可以马上获得 FFmpeg 的视频转码、剪辑合并、音频提取和常见流媒体协议处理能力把精力集中在业务代码和视频处理流程上。1. ffmpeg 自动安装脚本为什么我删掉手写笔记改成一条命令跑到底拿到一台新机器先跑一段 ffmpeg 自动安装脚本已经成了我配置环境的第一步。以前不是这样。以前我靠手写笔记apt install 一次、官网下载 tar.xz 解压一次、再把 bin 目录写进 PATH 一次三行笔记横跨三种姿势。真正翻车的是 apt 源里那个 ffmpeg 常常老得离谱而官网的静态构建又依赖系统 glibc 版本笔记在 Ubuntu 上顺的步骤换到 CentOS 就断在解压之后。ffmpeg 自动安装脚本要解决的就是这三件事装得上、装得对、换台机器还能复现。适合谁隔三差五要开新 CI 机器、搭视频处理环境、或者帮同事的 Ubuntu 补 ffmpeg 的人。对这些人来说脚本省的不是十分钟是省掉「今天在哪台机器上踩过什么坑」的查证成本。2. 选错安装源脚本写得再好也白搭包管理器、静态构建与源码编译怎么选写自动安装脚本第一步不是写 curl是决定安装源。这一点定了脚本里「下载什么、装到哪里、要不要解压、要不要编译」才有的写。同一个 ffmpeg从不同来源拿到系统里的东西完全不一样包管理器给的是发行版维护的二进制静态构建是官方编译的单文件源码编译是你自己现场生成的二进制。三者各有一笔账要算下面逐个说。2.1 包管理器省心但版本永远慢半拍在 Debian/Ubuntu 上一句apt install -y ffmpeg是所有方案里最省心的依赖自动解决后续apt upgrade还能跟着系统一起维护。CentOS/RHEL 对应的则是dnf install -y ffmpeg不过在 EPEL 与 RPM Fusion 源未启用时这条命令大概率直接报「没有可用软件包」这也是脚本要单独处理的一个分支。macOS 上brew install ffmpeg体验更接近官方。# Ubuntu / Debian apt update apt install -y ffmpeg # RHEL / CentOS 8 dnf install -y ffmpeg # macOS brew install ffmpeg这三条命令差一个字判断条件却完全不同apt 系只要源里有就能装RPM 系要先确认 EPEL 和 RPM FusionHomebrew 必须先有 brew 本体。仓库判断要在脚本里分岔而不是一把梭。包管理器版本滞后的幅度实际体验下来通常比官网慢一到两个大版本。如果你的业务不追求新编码器比如只做 H.264 转码、基础抽帧这个滞后完全无所谓但等你发现ffmpeg -encoders里没有 libx265 的时候就已经晚了。2.2 静态构建拿来即用的单文件但 glibc 会把旧系统卡住静态构建是跳过包管理器的最快路径。ffmpeg 官网下载页里除了源码包外还列了一份 static build 的下载项解压后里面是 ffmpeg、ffprobe 等完整二进制x264、x265、mp3lame、opus 这些常用编码库全部编译进去不需要用户补任何系统依赖。脚本的处理通常是把 tar.xz 解压到 /opt/ffmpeg再把 /opt/ffmpeg/bin 放进 PATH一个软链的事。静态构建最大的坑在 glibc 版本。这种二进制编译时用的 glibc 往往较新拿到旧系统上直接报version GLIBC_2.34 not found之类的错误。所以脚本在决定走静态构建前要额外加一步发行版代次判断较老的 CentOS 7、Ubuntu 18.04 这类环境静态构建容易翻车不如走包管理器。反过来如果你日常就是新装的 Ubuntu 22.04、Debian 12、Rocky Linux 9静态构建的安装脚本是最短路径秒级完成也最不容易在「缺依赖」上出幺蛾子。很多人习惯搜「ffmpeg 下载官网」直接找二进制这个习惯没错但要注意下载页里会用小字标注 licensestatic build 和源码包通常带 GPL 标识和 LGPL 版本的区别会直接影响你能不能把 ffmpeg 里编出来的库塞进自己的闭源项目里。自动安装脚本不用替用户做法律判断但至少要在下载时挑对 license 对应的包别把 GPL 的当成 LGPL 的装进去。2.3 源码编译全家桶自由代价是十分钟起步源码编译是自由度最高的路径要 AV1 就加 libsvtav1要 x265 就加 libx265要 debug 符号就开 --disable-stripping。代价是时间——普通 vCPU 上 configure 加 make 走一遍十分钟起步装完还得处理 make install 的权限问题。自动安装脚本一般不会默认选这条路只会用--sourcesource显式开启。./configure --enable-gpl --enable-libx264 --enable-libx265 \ --enable-libvpx --enable-libmp3lame --enable-libopus make -j$(nproc) make install这里的--enable-gpl和--enable-libx265之所以绑在一起是因为 x265 本身是 GPL 协议不带 --enable-gpl 编译时直接拒绝。这也是「msvc 编译 ffmpeg libx265」这类问题反复出现的原因Windows 上那条链路要配 MSVC 环境、配 pkg-config比 Linux 上麻烦一个量级脚本里基本不碰。make -j$(nproc)是唯一值得动脑筋的参数-j 不对时编译时长和把 CPU 跑满的焦虑程度都会翻倍。到这里安装源的选择逻辑就完整了。脚本要不要支持三种安装源取决于使用场景内网离线机大概率只能用包管理器或者离线拷贝的静态包CI 容器和公网云主机走静态构建最快只有想尝鲜最新编码器或者准备二次开发的人才值得为源码编译多等十分钟。我自己的默认值是「静态构建优先包管理器兜底」下一章就按这个策略把完整脚本写出来。3. 写一个能跑三年的自动安装脚本旧版本检测、curl 下载与 PATH 写入的最小流程选完安装源脚本框架就定了。我一般会把脚本拆成三个动作先检查系统里 ffmpeg 的现状再决定要不要装最后装完验证。下面的脚本默认走「静态构建优先、包管理器兜底」的路径能在主流的 apt 系和 RPM 系发行版上跑核心逻辑三块发行版检测、下载解压、PATH 写入。先看安装前要做的检查。3.1 安装前的三项检查缺了哪一项脚本都会变成黑匣子检查一当前系统属于哪个发行版。区分 apt 系还是 RPM 系决定后面用包管理器兜底时用哪条命令也决定是否适合装静态构建。detect_os() { if [ -f /etc/os-release ]; then . /etc/os-release case $ID in debian|ubuntu) echo apt ;; centos|rhel|rocky|almalinux|fedora) echo rpm ;; *) echo unknown ;; esac else echo unknown fi }如果是 Windows 环境发行版检测走的是另一条路径这里不展开。/etc/os-release里的ID字段比uname可靠得多——后者只会告诉你「Linux」不会告诉你「这个 Linux 是 Ubuntu 还是 CentOS」。这一步判断错了后面的分支都会跟着错脚本就成了黑匣子。检查二系统里是不是已经有一个可用的 ffmpeg。这一步能避免脚本在每次开机时都把下载重跑一遍。if command -v ffmpeg /dev/null 21; then ffmpeg -version 2/dev/null | head -n1 echo found else echo missing ficommand -v查的是 PATH 里的可执行文件所以脚本能找到的和用户实际能敲出ffmpeg的那个是同一个。这里只做存在性检查版本号是否足够新再单独判断——只判断「有没有」不管「新不新」重装时就会踩到旧版本遗留的坑这也是第 4 章要展开的第一个翻车点。检查三工具链里有没有 curl 或 wget。静态构建的下载依赖其中一项源码编译则还要 gcc、make、pkg-config。缺了再临时装。for cmd in curl wget; do if command -v $cmd /dev/null 21; then DL_CMD$cmd break fi done [ -n $DL_CMD ] || { echo need curl or wget 2; exit 1; }三项检查做完脚本的前置状态就明确了知道自己在什么系统上、知道系统里有什么、知道用什么工具下载。剩下的就是安装主流程。3.2 完整脚本三个函数加一次主流程下面是脚本主体可以直接保存为install_ffmpeg.sh运行。我把逻辑拆成detect_os、install_via_pkg、install_via_static三个函数和一个主流程#!/usr/bin/env bash set -euo pipefail LOG_PREFIX[ffmpeg-install] log() { echo $LOG_PREFIX $(date %F %T) $*; } detect_os() { [ -f /etc/os-release ] || { echo unknown; return; } . /etc/os-release case $ID in debian|ubuntu|linuxmint) echo apt ;; centos|rhel|rocky|almalinux|fedora) echo rpm ;; *) echo unknown ;; esac } get_existing_ffmpeg() { if command -v ffmpeg /dev/null 21; then ffmpeg -version 2/dev/null | head -n1 | sed s/^ffmpeg version // else echo none fi } install_via_pkg() { local os$1 if [ $os apt ]; then apt update apt install -y ffmpeg elif [ $os rpm ]; then dnf install -y epel-release || true dnf install -y --nogpgcheck ffmpeg || { echo rpm 源没有 ffmpeg尝试安装 RPM Fusion 后重试 2 dnf install -y --nogpgcheck \ https://download1.rpmfusion.org/free/el/rpmfusion-free-release-$(rpm -E %rhel).noarch.rpm dnf install -y --nogpgcheck ffmpeg } fi } install_via_static() { local dest/opt/ffmpeg local url$(curl -s https://ffmpeg.org/download.html | grep -oE https?://[^]static[^]ffmpeg[^]*\.tar\.xz | head -n1) if [ -z $url ]; then echo 未能在官网解析到 static 下载链接改用包管理器兜底 2 return 1 fi log download $url mkdir -p /tmp/ffmpeg-install if command -v curl /dev/null 21; then curl -L --fail --retry 3 -o /tmp/ffmpeg-install/ffmpeg.tar.xz $url else wget -O /tmp/ffmpeg-install/ffmpeg.tar.xz $url fi tar -xJf /tmp/ffmpeg-install/ffmpeg.tar.xz -C /tmp/ffmpeg-install mkdir -p $dest cp -a /tmp/ffmpeg-install/ffmpeg-*/* $dest/ if ! grep -q export PATH.*$dest/bin /etc/profile.d/ffmpeg.sh 2/dev/null; then echo export PATH$dest/bin:\$PATH /etc/profile.d/ffmpeg.sh fi ln -sf $dest/bin/ffmpeg /usr/local/bin/ffmpeg ln -sf $dest/bin/ffprobe /usr/local/bin/ffprobe } os$(detect_os) [ $os ! unknown ] || { echo 无法识别系统请手动安装 2; exit 2; } log detect os: $os, current ffmpeg: $(get_existing_ffmpeg) SOURCE${SOURCE:-static} if [ $SOURCE static ]; then install_via_static || install_via_pkg $os elif [ $SOURCE pkg ]; then install_via_pkg $os fi log done: $(ffmpeg -version 2/dev/null | head -n1)这里要解释几个关键设计的理由。第一set -euo pipefail让脚本在「命令失败但不返回错误码」的情况下也能被拦下来避免下载失败后继续解压空文件。第二静态安装部分用/usr/local/bin软链而不只是改 PATH是为了让/usr/local/bin在命令查找顺序里优先于/usr/bin把系统里可能已有的旧版本压住。第三install_via_static失败时回退到包管理器是这条兜底路径的真正含义。install_via_pkg里 RPM 分支比较克制只在 EPEL 不起作用时才尝试 RPM Fusion并且把 GPG 检查关掉避免企业内网源没有 GPG key 时直接退出。这两个分支的行为差异正对应第 2 章说的「包管理器行为不统一」的前提脚本必须让每种系统的失败路径都各自可控。3.3 参数说明为什么 --force 和 --source 要留成开关脚本里我特意没把SOURCE写死而是用环境变量SOURCEstatic|pkg指定。原因很现实静态构建能跑通的前提是能访问官网下载页内网机器上这一步大概率失败把它们留成开关脚本就能在离线环境里直接改用SOURCEpkg。再加一个FORCE1开关用于强制重装第 4 章的版本检测坑也需要它来解围。实际上脚本还可以接受一个--prefix参数把静态构建的安装目录从/opt/ffmpeg换到用户目录比如$HOME/ffmpeg。这样做的好处是用户级安装对系统目录零改动适合没有 root 权限的 CI 账号代价是 PATH 和软链都要跟着改脚本里需要把输出路径参数化。这个参数通常不设默认值只在使用者主动要求时才启用。到这一步一个最小的自动安装流程就完整了。但真正把它从「我机器上能跑」变成「任意机器上能跑」的不是这些顺利路径而是失败路径。下面这一章我把自己维护脚本期间踩过的坑按现象列出来每条都对应一个具体的代码缺陷。4. 自动安装脚本的 4 个常见翻车点版本判断失效、下载中断、PATH 写入与软链冲突脚本写完能跑不代表半年后还能跑。下面 4 个问题是我在维护安装脚本过程中真实踩过的每条按「现象 → 原因 → 解决」来讲希望你不要在同一处翻两次车。4.1 版本判断失效装上等于没装脚本跑完还是旧版现象脚本每次都显示「已安装跳过」但机器上 ffmpeg 版本停在两年前新编码器一概不支持。某天用 ffmpeg 做-c:v libx265压视频命令直接报 unknown encoder才意识到装的不是自己以为的那个。原因检测逻辑只写了command -v ffmpeg判断「有」就跳过。问题是旧版本通常来自发行版自带路径在/usr/bin/ffmpeg而静态构建装到/opt/ffmpeg/bin后软链放在/usr/local/bin/ffmpeg——命令查找顺序会让新版本优先但脚本判断时不会去比较「检测到的版本」和「目标版本」谁新。解决把判断从「存在性检查」升级成「版本号对比」。目标版本用一个最低值卡位低于它就重装installed$(get_existing_ffmpeg) if [ $installed ! none ] [ $FORCE ! 1 ]; then ver$(echo $installed | sed -E s/^([0-9]\.[0-9]).*/\1/) if awk -v v$ver BEGIN{exit !(v 4.4)}; then log ffmpeg $installed already ok exit 0 fi fi这里awk的作用是跨版本号比较比sort -V可移植性好一些。最低版本卡在 4.4 是行内惯用做法低于这个版本老编码器缺太多装了也白装。4.2 下载中断重跑脚本永远在同一处失败现象静态构建下载到 80% 断网脚本退出。重跑一遍又是在 80% 附近失败日志里没有明确报错。原因curl -L默认没有--fail时断点续传不会启用重跑时重新下载而且脚本里set -e在下载失败时会直接退出不给你看失败原因。更隐蔽的是-L只为 3xx 重定向服务如果官网返回 200 但内容被中间代理截断tar在解压时才报「unexpected EOF」此时脚本早已退出。解决下载加--fail --retry 3 -C -并让解压单独判断返回值失败时打印 curl 退出码curl -L --fail --retry 3 -C - -o /tmp/ffmpeg.tar.xz $url \ tar -xJf /tmp/ffmpeg.tar.xz \ || { echo download or extract failed, exit$?; exit 1; }--fail让 HTTP 4xx/5xx 立即以非零码退出-C -断点续传--retry覆盖瞬时抖动。这段改完之后最常见的效果是原来 80% 断网要等整套下载重跑现在补上剩余 20% 就好。4.3 PATH 写入终端新开一个窗口照样找不到 ffmpeg现象脚本执行成功日志也打了ffmpeg installed但用户新开一个 SSH 会话敲ffmpeg提示command not found。老窗口能用新窗口不能用。原因脚本只把 PATH 写进了当前 shell 的环境变量没有写入 shell 配置文件。当前窗口的export不会遗传给之后新开的登录 shell。而如果你写入的是~/.bash_profile在 Ubuntu 默认的.bashrc只被非登录交互 shell 读取时配置也离奇失效。所以双写才是稳定路径。解决写到/etc/profile.d/ffmpeg.sh对所有用户生效并双写用户级~/.bashrc兜底。脚本里已经做了注意写入时先grep去重避免同一行 PATH 被追加多遍。追加多遍除了 PATH 过长之外还会在用户echo $PATH时看到一长串重复的/opt/ffmpeg/bin异常丑且不好排查。4.4 软链冲突/usr/bin 已被旧版本占位新软链建不出来现象CentOS 机器上静态构建安装成功/usr/local/bin/ffmpeg软链也建好了但敲ffmpeg出来的还是旧版本。查which ffmpeg答案指向/usr/bin/ffmpeg。原因/usr/bin在 PATH 里的优先级比/usr/local/bin高。旧发行版包管理器自带的 ffmpeg 占用/usr/bin/ffmpeg而脚本只建了/usr/local/bin软链从结果上看就是「旧版本压制新版本」PATH 排在前面的路径先被命中。解决静态安装成功之后把/usr/bin下的旧软链或旧二进制改名备份再把新二进制软链指过去。注意别用rm -f删旧文件改名成ffmpeg.bak才是后悔药if [ -e /usr/bin/ffmpeg ]; then mv /usr/bin/ffmpeg /usr/bin/ffmpeg.bak fi ln -sf /opt/ffmpeg/bin/ffmpeg /usr/bin/ffmpeg这一条也解释了为什么第 3 章脚本里两个软链都在还不够——因为目标路径里/usr/bin才是决定最终命中谁的那个关键位置。类似现象也常出现在 Windows 上「ffmpeg 安装后怎么配置环境变量」的提问里本质是 PATH 顺序问题不是安装问题。到这里避坑部分就完了。剩下的内容会让脚本更稳重给下载加上完整性校验并让它在无人值守的 CI 里跑得更安静。5. 让脚本多活两年的两个细节SHA256 校验与无人值守安装静态构建脚本最容易被人忽略的一段是下载后的完整性校验。官网下载页会同时给出 tar.xz 的 SHA256 散列值脚本在解压前先做一次校验能同时挡住两件事下载文件损坏以及下载源被掉包。散列值我会写死在脚本里或者单独放在ffmpeg.sha256文件中让脚本读取if echo $SHA256_VALUE /tmp/ffmpeg.tar.xz | sha256sum -c - /dev/null 21; then log sha256 ok, unpack else echo sha256 mismatch, remove downloaded file 2 rm -f /tmp/ffmpeg.tar.xz exit 1 fi这段代码要放在tar解压之前。校验失败时直接删掉损坏文件比留在/tmp里让下次重跑断点续传接上一个坏文件要干净得多。写死散列值听起来麻烦但静态构建每个 release 才更新一次脚本维护者只需在升级脚本时同步更新这一个字符串。无人值守是另一个现实问题。手动跑脚本时apt 的交互确认和 RPM Fusion 源的 GPG 提示都可以人工点掉CI 里跑任何一次交互都会让流水线卡死。做法是把所有安装命令统一加-y或--noconfirm以及为 RPM 分支的dnf加--nogpgcheck同时把日志集中输出到固定文件方便事后按时间戳回溯。这些都是小动作但缺任何一处脚本进 CI 的第一天就会翻车。我自己的一个习惯是每写完一版脚本会刻意在一台全新容器里跑一遍确认从零到ffmpeg -version输出不超过两分钟。版本号写死、PATH 双写这些事都是吃过亏之后才学乖的你照这份思路写的时候建议把「换系统、换网络、强制重装」这三个场景都预演一遍。这份脚本的价值不在它能跑通一次而在半年后你换了一台机器它还能一次跑通。希望帮到你。本文还有配套的精品资源点击获取