核心是流媒体与转码解耦：流媒体服务器（如MediaMTX、ZLMediaKit）专注低延迟分发，转码由专用FFmpeg或HandBrake容器异步处理，支持GPU/Intel QSV加速、资源隔离及SSD存储优化。
用 Docker 实现容器化的流媒体服务器并加速视频转码，核心不是把“流媒体服务”和“转码”硬凑在一起，而是按角色拆解、各司其职：流媒体服务器专注低延迟分发（如 MediaMTX、ZLMediaKit），转码任务交给专用容器（如 FFmpeg 或 HandBrake）异步处理。强行让一个容器既推流又实时转码，反而会拖慢整体性能、增加延迟、难以扩展。
下面从三个关键环节讲清楚怎么做才真正“加速”：
明确分工：流媒体与转码解耦
流媒体服务器（如 MediaMTX、ZLMediaKit）本身不负责转码，只做协议转换（RTSP→WebRTC/HLS/HTTP-FLV）和流路由。 需要转码时，应由独立的转码服务接收原始流或文件，完成处理后输出新流或文件，再交由流媒体服务器发布。 这样做的好处： - 转码压力不干扰流分发稳定性 - 可为不同分辨率/格式/设备需求启动多个转码实例 - 支持 GPU 硬件加速（需宿主机透传设备）而不影响流服务容器
选对转码容器：轻量 + 加速支持
优先使用预编译、多架构、含硬件加速的镜像： - **FFmpeg 场景**：用 `jrottenberg/ffmpeg:latest`（CPU）或 `nvidia/cuda:12.2.0-runtime-ubuntu22.04` + 自编译 `ffmpeg-nv`（NVIDIA GPU） - **GUI/批量场景**：用 `jlesage/handbrake`，支持 Intel QSV（需挂载 `/dev/dri`）、NVIDIA（需 `--gpus all` 和 `nvidia-container-toolkit`） 验证是否启用加速： ```bash docker run --rm jrottenberg/ffmpeg -hwaccels # 查看可用加速器 docker run --rm --gpus all jlesage/handbrake -h | grep -i nvenc ```
加速落地的关键配置
- **GPU 透传**（NVIDIA）： ```bash docker run --gpus all -v /path/to/input:/input -v /path/to/output:/output \ jrottenberg/ffmpeg ffmpeg -hwaccel cuda -i /input/in.mp4 \ -c:v h264_nvenc -preset p7 -b:v 2M -c:a aac /output/out.mp4 ``` - **Intel QSV**（需挂载 `/dev/dri`）： ```bash docker run -v /dev/dri:/dev/dri -v $(pwd):/work jrottenberg/ffmpeg \ ffmpeg -hwaccel qsv -c:v h264_qsv -i /work/in.mp4 -c:v h264_qsv /work/out.mp4 ``` - **存储优化**：转码过程 I/O 密集，务必使用 SSD 挂载输入/输出目录，避免 NFS 或机械盘成为瓶颈 - **资源限制**：用 `--cpus 4 --memory 4g` 防止单个转码吃光宿主机资源，影响流媒体服务
与流媒体服务协同工作流
典型生产流程： - 摄像头推 RTSP 流到 MediaMTX（监听 `rtsp://server:8554/stream`） - 后台脚本或 Celery 任务检测新事件（如告警触发），调用 FFmpeg 容器拉流转码并存为 HLS 片段 - ZLMediaKit 或 Nginx 将 `/hls/out.m3u8` 暴露为 HTTP 接口供前端播放 或者更简单： - 把原始录制文件丢进 `/watch` 目录 → HandBrake 容器自动转码 → 输出 MP4 → 由 ZLMediaKit 的 `http_push` 或 `record` 模块自动加载为点播流
不复杂但容易忽略。
