我们为什么放弃在服务器上转码

一台四核 ARM 的机器跑 ffmpeg 会慢到什么程度？我们实测了一百二十秒的素材，顺便算清了预转码与直传的成本差。

结论先放前面：在 ARM 服务器上批量转码是错的，不是因为 CPU 不够强，而是因为这件事根本不该发生在服务端。

实测数据

一段 120 秒、4K、60fps 的素材，在 4 OCPU 的 Ampere A1 上：

输出规格	耗时	实时倍数
1080p H.264 预设 medium	418 秒	0.29x
1080p H.264 预设 veryfast	246 秒	0.49x
720p H.264 预设 veryfast	131 秒	0.92x

也就是说，上传一个十分钟的视频，服务器要忙上一个小时。这期间它还要跑数据库、跑 SSR 渲染，CPU 抢成这样，页面响应会直接崩。

正确的做法

本地用 HandBrake 或 ffmpeg 转好再传。命令大概是：

ffmpeg -i input.mov \
  -c:v libx264 -preset slow -crf 21 \
  -profile:v high -level 4.0 -pix_fmt yuv420p \
  -c:a aac -b:a 128k \
  -movflags +faststart \
  output.mp4

-movflags +faststart 这一条不能省。它把 moov atom 挪到文件头部，浏览器才能一边下一边拖进度条；不加的话，用户得等整个文件下完才能跳转。