用Docker搭建音视频转码服务需基于轻量镜像（如jrottenberg/ffmpeg）封装FFmpeg，支持常用编码器与硬件加速；通过Shell+netcat或FastAPI提供API，结合Nginx、Redis、Celery实现上传、队列与状态查询；注重CPU/内存限制、SSD存储、日志优化及健康检查。
用 Docker 搭建音视频转码服务，核心是把 FFmpeg 封装成轻量、可复用、易扩展的容器服务。不依赖宿主机环境，一次构建、随处运行，还能按需横向扩容。
选择合适的基础镜像与 FFmpeg 版本
优先使用官方 alpine 或 ubuntu:slim 镜像，体积小、攻击面低。避免用 full Ubuntu 或 CentOS，除非有特定编解码器依赖。
FFmpeg 必须启用常用编码器（如 libx264、libx265、libvpx-vp9、aac）和硬件加速支持（如 vaapi、nvenc）。推荐直接使用 jrottenberg/ffmpeg 镜像（多架构、预编译、定期更新），或自己基于 ffmpeg:alpine 构建：
- 检查是否含关键 codec：
docker run --rm jrottenberg/ffmpeg -encoders | grep -E "(264|265|vp9|aac)" - 若需 NVIDIA GPU 加速，必须用
nvidia/cuda:12.2.0-runtime-ubuntu22.04基础镜像 + 安装支持 nvenc 的 FFmpeg（如ffmpeg-nv或自行编译）
编写最小可用的转码服务容器
无需复杂框架，一个监听 HTTP 请求、触发 FFmpeg 命令、返回结果的轻量服务即可起步。推荐用 Python + Flask/FastAPI 或 Node.js + Express，但更推荐 Shell 脚本 + netcat 实现极简 API（适合学习和测试）。
示例：Dockerfile（基于 jrottenberg/ffmpeg）
FROM jrottenberg/ffmpeg:5.1-alpine COPY transcode.sh /transcode.sh RUN chmod +x /transcode.sh EXPOSE 8080 CMD ["/transcode.sh"]
transcode.sh 可监听本地端口，接收文件 URL 和参数，执行类似：
ffmpeg -i "$INPUT_URL" -c:v libx264 -crf 23 -c:a aac -b:a 128k -f mp4 /output/out.mp4
注意挂载 /output 为卷，或用 curl -F "file=@out.mp4" 回传结果。
支持文件上传、异步任务与状态查询
生产中需处理大文件上传、避免请求超时、支持任务排队。建议引入以下组件：
- 用 Nginx 做前置代理，处理文件上传（
client_max_body_size 2G）、静态资源分发 - 用 Redis 存储任务 ID、状态（pending/running/done/failed）、输出路径
- 用 Python Celery 或 Node Bull 管理后台转码任务队列，主服务只负责接收请求并推入队列
- 提供 REST 接口：
POST /transcode提交任务 → 返回task_id；GET /task/{id}查询进度（FFmpeg 可通过-progress输出 JSON 到管道）
性能优化与生产注意事项
容器化转码不是“一塞就跑”，几个关键点决定是否稳定可用：
-
CPU 绑定与限制：用
--cpus=2或--cpuset-cpus="0-3"避免争抢；FFmpeg 加-threads 0自动匹配逻辑核数 -
内存安全：大分辨率视频（如 4K）可能吃光内存，加
--memory=2g --memory-swap=2g并监控 OOM -
存储 IO：输入/输出目录尽量挂载 SSD 卷；避免 NFS；临时文件用
/dev/shm（tmpfs）加速 -
日志与调试：FFmpeg 加
-v quiet -stats减少干扰；错误信息重定向到 stderr，方便 Docker logs 查看 -
健康检查：在 docker-compose.yml 中添加
healthcheck，例如curl -f http://localhost:8080/health || exit 1
不复杂但容易忽略：转码服务本质是 I/O 与 CPU 密集型任务，容器只是封装层，底层资源规划和 FFmpeg 参数调优才是性能关键。先跑通单任务，再加队列、监控、自动扩缩容。
