站长为什么绕不开 FFmpeg

很多人觉得"视频处理"离个人站长很远，其实不然。只要你的站涉及到这几件事，迟早会遇到 FFmpeg：上传一段教程录屏想放到文章里、把手机拍的竖屏视频转成能网页播放的格式、给视频压缩体积省带宽、从视频里抽一帧当封面图、把音频转成 MP3 方便听众下载。这些需求看起来零散，但底层都是同一套东西：音视频的编解码与封装，而 FFmpeg 是这个领域事实上的标准工具。

FFmpeg 是命令行的，这让很多人一开始望而生畏——参数多、报错晦涩。但好消息是，个人站常用的操作其实就那么十几个，学会之后就能覆盖 95% 的场景。这篇文章从最基础的格式转换讲起，一路到网页视频的压缩、HLS 切片和 Nginx 分发，把站长真正用得上的部分讲清楚，最后附上几个我踩过的坑。

先装好它。FFmpeg 在各大发行版的仓库里都有：

# Debian/Ubuntu
apt update && apt install -y ffmpeg

# 查看版本与支持的编解码器
ffmpeg -version
ffmpeg -encoders | grep -E "libx264|libx265|aac|libvpx-vp9"

看到 `libx264`（H.264 编码器）和 `aac`（音频编码器）就说明装好了。这两个是做网页视频最基础的编码器。

理解 FFmpeg 的三个核心概念：输入、输出、编码

FFmpeg 命令的结构其实很规整：全局参数 → 输入文件 → 输出参数 → 输出文件。初学时把这条结构记住，参数就不容易放错位置。最简的格式转换：

# mp4 转 webm
ffmpeg -i input.mp4 output.webm

# 单纯换封装格式（不重新编码，秒级完成）
ffmpeg -i input.mov -c copy output.mp4

这里 `-i` 指定输入，`-c copy` 是关键技巧——它告诉 FFmpeg "音视频流原样复制，不要重新编码"。因为只是换了个容器（把 MKV 里的流塞进 MP4 的壳），不需要解码再编码，所以速度快到几乎瞬间，画质也零损失。什么时候能用 `-c copy`？当目标格式支持源视频里的编码时。比如 H.264 的视频转成 MP4 容器就可以，但如果是把 H.264 转成 VP9，就必须重新编码，因为编码格式变了。

真正的转码（重新编码）长这样：

ffmpeg -i input.mp4 \
  -c:v libx264 -preset medium -crf 23 \
  -c:a aac -b:a 128k \
  output.mp4

逐段拆解：`-c:v libx264` 指定视频编码器，`-c:a aac` 指定音频编码器，`-b:a 128k` 是音频码率。最需要理解的是 `-crf 23` 和 `-preset medium`——这两个决定了转码的质量和速度，是网页视频压缩的核心旋钮。

CRF 与 preset：视频压缩的两个关键旋钮

CRF（Constant Rate Factor，恒定质量因子） 控制画质。它的取值通常从 0 到 51，数字越小质量越高、体积越大。经验值：18 接近视觉无损，23 是默认值（质量与体积的平衡点），28 以上开始明显糊。做网页视频，18 到 23 之间是合理区间。和固定码率（`-b:v 2M` 指定 2Mbps）相比，CRF 的好处是"按画面复杂度动态分配码率"——静态画面少花码率，动作多的画面多给码率，总体更省带宽且观感更均匀。

preset（预设） 控制编码速度与压缩率的取舍，取值从 `ultrafast` 到 `veryslow` 共九档。越慢的 preset 压缩率越高（同样画质下体积更小），但编码时间成倍增长。

# 对比不同 preset 的输出体积
ffmpeg -i input.mp4 -c:v libx264 -preset ultrafast -crf 23 out_uf.mp4
ffmpeg -i input.mp4 -c:v libx264 -preset medium     -crf 23 out_med.mp4
ffmpeg -i input.mp4 -c:v libx264 -preset slow       -crf 23 out_slow.mp4
ls -lh out_*.mp4

我的经验是：个人站视频量不大，用 `medium` 或 `slow` 就够了，不必追求 `veryslow`（时间成本翻好几倍，体积只再省百分之几）。如果你有一批视频要在服务器上批量转，服务器 CPU 又弱，那就用 `fast`，保证能在可接受的时间内跑完。preset 的选择没有标准答案，取决于你更缺 CPU 时间还是更缺带宽。

给网页视频做真正的优化：faststart 与 Web 播放

一个新手最容易忽略、但对网页播放体验影响巨大的参数是 `-movflags +faststart`。

MP4 文件里有一段叫 moov 的元数据，记录了视频的结构信息。默认情况下，FFmpeg 会把 moov 放在文件末尾。这对本地播放没影响，但放到网页上就糟了：浏览器必须先下载整个文件才能找到 moov、才知道怎么播放，用户看到的是长时间的黑屏等待。加上 `+faststart`，FFmpeg 会把 moov 挪到文件开头，浏览器一拿到头部就能开始播放，实现"边下边播"。

ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium \
  -c:a aac -b:a 128k \
  -movflags +faststart \
  output.mp4

这是给网页视频转码时应该默认加上的参数，不加就是白白牺牲用户体验。配合 HTML5 的 `

<video controls preload="metadata" poster="cover.jpg" width="720">
  <source src="video.mp4" type="video/mp4">
  你的浏览器不支持 HTML5 视频。
</video>

`poster` 指定封面图，`preload="metadata"` 让浏览器只预加载元数据（时长、尺寸）而不下载整个视频——这两个属性能显著降低页面的初始加载负担。

从视频里抽封面图、截取片段、提取音频

封面图是文章配视频的标配，用 FFmpeg 一帧就能抽出来：

# 抽取第 5 秒的一帧作为封面
ffmpeg -ss 00:00:05 -i input.mp4 -frames:v 1 -q:v 2 cover.jpg

# 批量抽多张候选封面（每秒一张，前 10 秒）
ffmpeg -i input.mp4 -vf fps=1 -frames:v 10 cover_%02d.jpg

`-ss` 放在 `-i` 前面是"快速定位"，FFmpeg 会先跳到目标时间点附近再精确解码，比放在后面快得多。`-q:v 2` 是 JPEG 的质量参数，数字越小质量越高（2 已经是高质量）。

截取片段和提取音频也常见：

# 截取从 1 分 30 秒开始、长 30 秒的片段（不重编码，快）
ffmpeg -ss 00:01:30 -i input.mp4 -t 30 -c copy clip.mp4

# 提取为 MP3 音频
ffmpeg -i input.mp4 -vn -c:a libmp3lame -q:a 2 audio.mp3

# 音频转码为体积更小的参数
ffmpeg -i input.wav -c:a aac -b:a 96k output.m4a

`-vn` 表示"不要视频流"（video none）。`-q:a 2` 是音频 VBR 质量，数字越小质量越高，2 对应约 190kbps 的平均码率，对语音类内容足够。

批量处理：给一堆视频统一压缩

单个文件处理会了，真正的效率来自批量。用一条简单的 shell 循环，把目录下所有视频统一转成网页友好的格式：

mkdir -p output
for f in *.mp4; do
  ffmpeg -i "$f" -c:v libx264 -crf 23 -preset medium \
    -c:a aac -b:a 128k -movflags +faststart \
    "output/$f"
  echo "done: $f"
done

需要注意的是，批量转码是 CPU 密集型任务，多个文件串行跑会占用大量 CPU，可能影响服务器上的其他服务。两个缓解思路：一是用 `nice` 降低优先级，让它在空闲时跑；二是限制 FFmpeg 使用的线程数，避免把 CPU 吃满。

# 降优先级 + 限制 2 线程
nice -n 19 ffmpeg -threads 2 -i "$f" -c:v libx264 ... "output/$f"

如果视频量大、又不想占用网站服务器的 CPU，更好的做法是把转码放到一台专门的低配机器上，或者外包给云函数——但对绝大多数个人站，`nice` + 限线程已经足够。

进阶：HLS 切片，让长视频流畅播放

当视频比较长（比如半小时的教程），用单个 MP4 文件很吃亏：用户要下载完相当一部分才能流畅播放，而且无法自适应网速。这时该用 HLS（HTTP Live Streaming）——把视频切成一段段几秒的小文件，配一个播放列表，播放器按需拉取。它的最大好处是天然支持多码率自适应：网速好就拉到高清切片，网速差就切到低清，中途不会卡。

FFmpeg 直接支持 HLS 切片的生成：

ffmpeg -i input.mp4 \
  -c:v libx264 -crf 23 -preset medium \
  -c:a aac -b:a 128k \
  -hls_time 6 \
  -hls_playlist_type vod \
  -hls_segment_filename "hls/segment_%03d.ts" \
  hls/index.m3u8

参数含义：`-hls_time 6` 把每段切成约 6 秒；`-hls_playlist_type vod` 声明这是点播（Video On Demand），生成的 m3u8 会包含完整时长信息；`-hls_segment_filename` 指定切片文件名模板。生成的目录里会有一堆 `.ts` 切片和一个 `index.m3u8` 播放列表。用 HTML5 播放需要引入 hls.js（因为 Safari 原生支持 HLS，Chrome/Firefox 需要这个库）：

<script src="https://cdn.jsdelivr.net/npm/hls.js@latest"></script>
<video id="player" controls></video>
<script>
  var video = document.getElementById('player');
  if (Hls.isSupported()) {
    var hls = new Hls();
    hls.loadSource('hls/index.m3u8');
    hls.attachMedia(video);
  }
</script>

更进一步，可以做多码率版本——用同一份源，分别生成 360p、720p、1080p 三套切片和一个 master 播放列表，播放器会自动选择。这对带宽成本敏感、观众网络条件参差的站点很有价值，但配置也更复杂，属于"视频站"级别的投入，普通博客用单码率 HLS 或直接 MP4 就够了。

Nginx 分发视频的配置要点

切片和 MP4 生成好之后，让 Nginx 高效地把它们发出去，有两个关键配置。第一是给视频文件开启 `sendfile` 和合理的缓存头——视频是典型的"大文件、少变动"，缓存应该设长：

location ~ \.(mp4|ts|m3u8)$ {
    root /var/www/media;
    # 视频是静态大文件，让浏览器/SG 长时间缓存
    expires 30d;
    add_header Cache-Control "public";
    # m3u8 播放列表更新频繁，缓存设短
    if ($request_uri ~ \.m3u8$) {
        expires 1m;
    }
}

第二，HLS 需要在 Nginx 里声明正确的 MIME 类型，否则浏览器拿到 `.m3u8` 会因为类型不对而拒绝播放：

# 在 http {} 块或 server {} 块里
types {
    application/vnd.apple.mpegurl m3u8;
    video/mp2t ts;
}

第三，别忘了防盗链。视频文件体积大，是别人盗链的头号目标，一旦被外站直接引用，你的带宽会被迅速吃光。用 Nginx 的 referer 校验挡掉：

location ~ \.(mp4|ts)$ {
    valid_referers none blocked server_names *.yourdomain.com;
    if ($invalid_referer) {
        return 403;
    }
}

这三项配好，你的视频分发就既有性能、又不会被盗刷带宽。

真实复盘：一次"转码把服务器跑挂了"的教训

说个真事。有次我在主站服务器上直接跑批量转码，十几个视频一次性丢进去，`preset` 还用了 `slow`。转码是高度并行的 CPU 任务，FFmpeg 默认会用满所有核心，结果服务器 CPU 被吃到 100%，网站响应从几十毫秒飙到好几秒，等于自 DDoS。更糟的是有一个视频源文件编码异常，转码中途报错卡住，脚本没有错误处理，整条 `for` 循环就那么悬在那儿，占了半个核心到天亮。

这次之后我定了两条规矩。一、永不把批量转码放在生产服务器上跑，要么放到测试机，要么在服务器空闲时段用 `nice -n 19` 配合 `-threads` 限核。二、批量脚本必须能跳过失败文件、能记录进度。改过的脚本长这样：

for f in *.mp4; do
  out="output/$f"
  if [ -f "$out" ]; then
    echo "skip (already done): $f"; continue
  fi
  if nice -n 19 ffmpeg -threads 2 -i "$f" -c:v libx264 -crf 23 \
       -preset fast -c:a aac -b:a 128k -movflags +faststart \
       -y "$out" 2>>transcode.log; then
    echo "ok: $f"
  else
    echo "FAIL: $f" >> failed.txt
  fi
done

这段脚本加了三个保险：已经转好的文件跳过（可断点续跑）、失败的不中断循环而是记进 `failed.txt`、成功的静默、失败的留日志。批量任务的第一原则是"可中断、可续跑、失败可查"——因为在生产环境里，一个跑一半就崩且不知道崩在哪的任务，比不跑还麻烦。

小结

FFmpeg 看起来参数繁多，但个人站真正高频用到的就三组：转码压缩（`-c:v libx264 -crf -preset`）、网页优化（`-movflags +faststart`）、以及抽取/截取/批量（`-ss`/`-t`/`-c copy`/shell 循环）。把这三组吃透，你就能搞定上传视频、生成封面、压缩体积、适配网页播放的全流程。再往上一步是 HLS 切片，用于长视频的流畅播放；分发环节则交给 Nginx，配好缓存、MIME 类型和防盗链。最后记住那条用血换来的经验：批量转码别放在生产服务器上裸跑，用 `nice` 限速、让脚本可续跑，把 CPU 资源留给你真正在服务的网站。