xiaoxia/xiaoxia-saas
1
0
Fork 0
Code Issues 15 Pull Requests 2 Actions Packages Projects Releases 7 Wiki Activity

[P1] 转码速度优化：4核软编约0.5倍实时，长视频触900s超时被kill（preset faster + threads + timeout 1800） #1733

New Issue
Open
opened 2026-09-06 13:24:10 +08:00 by xiaoxia · 0 comments
xiaoxia commented 2026-09-06 13:24:10 +08:00
Owner
Copy Link
Copy Source

背景（staging 实测 2026-09-06）

业务服务器 4 核 Intel Xeon Platinum（2核×2线程，2.5GHz）、14GB 内存、无 GPU，ffmpeg 7.1.5 纯软件编码（libx264），worker 容器负载 load average 9+（已超载）。

转码实测数据（worker 容器内，与 ingest.py 生产参数一致：libx264 -preset fast -crf 18，1080×1920 竖屏 30fps）：

  • 10 秒视频转码耗时 19 秒（约 1.9 倍实时）
  • 60 秒视频转码耗时 约 131 秒（约 2.2 倍实时）

推算：1 分钟视频约需 2 分钟转码，7~8 分钟视频触顶 15 分钟，超过 TRANSCODE_TIMEOUT_SECONDS = 900（apps/worker/worker_app/tasks/ingest.py 约 159 行）的长视频会被直接 kill，素材卡 processing/失败。

修复要求

P1-1 转码提速（低成本，先做）

  1. ffmpeg preset 由 fast 调整为 faster（ingest.py 约 568-596 行转码命令）：预期提速 3040%，输出体积约 +1015%，画质损失可接受（当前 crf 18 本身偏保守）
  2. 显式配置 -threads 参数（当前命令未指定线程数，libx264 默认线程策略在容器 cgroup 限核下可能只用 1 线程，需实查确认并按容器核数显式指定）
  3. 改后在 staging 用同规格视频复测耗时，确认提速比例和画质/体积变化

P1-2 超时兜底（配合 #1714 孤儿任务修复）

  1. TRANSCODE_TIMEOUT_SECONDS 由 900 提升至 1800（30 分钟），覆盖 10~15 分钟长视频
  2. 转码超时/失败时任务必须明确置 failed 并回写 error_message，素材卡片允许用户重试，不允许静默卡死（与 #1714 processing 超时兜底同一套机制）

P2-3 容量规划（本次只出方案，不实施）

  1. 评估独立 worker 节点 / GPU 转码 worker（NVENC）方案与成本
  2. 当前 load average 9+ 说明 worker 与其他服务混部已超载，转码任务高峰期会拖慢全链路，需评估 worker 横向扩容或任务隔离

单测/验证：faster preset 输出文件可正常播放、参数正确；超时配置生效；staging 长视频（10 分钟+）端到端转码成功。

## 背景（staging 实测 2026-09-06） 业务服务器 4 核 Intel Xeon Platinum（2核×2线程，2.5GHz）、14GB 内存、无 GPU，ffmpeg 7.1.5 纯软件编码（libx264），worker 容器负载 load average 9+（已超载）。 **转码实测数据**（worker 容器内，与 ingest.py 生产参数一致：libx264 -preset fast -crf 18，1080×1920 竖屏 30fps）： - 10 秒视频转码耗时 **19 秒**（约 1.9 倍实时） - 60 秒视频转码耗时 **约 131 秒**（约 2.2 倍实时） 推算：**1 分钟视频约需 2 分钟转码，7~8 分钟视频触顶 15 分钟**，超过 `TRANSCODE_TIMEOUT_SECONDS = 900`（apps/worker/worker_app/tasks/ingest.py 约 159 行）的长视频会被直接 kill，素材卡 processing/失败。 ## 修复要求 **P1-1 转码提速（低成本，先做）** 1. ffmpeg preset 由 `fast` 调整为 `faster`（ingest.py 约 568-596 行转码命令）：预期提速 30~40%，输出体积约 +10~15%，画质损失可接受（当前 crf 18 本身偏保守） 2. 显式配置 `-threads` 参数（当前命令未指定线程数，libx264 默认线程策略在容器 cgroup 限核下可能只用 1 线程，需实查确认并按容器核数显式指定） 3. 改后在 staging 用同规格视频复测耗时，确认提速比例和画质/体积变化 **P1-2 超时兜底（配合 #1714 孤儿任务修复）** 1. `TRANSCODE_TIMEOUT_SECONDS` 由 900 提升至 1800（30 分钟），覆盖 10~15 分钟长视频 2. 转码超时/失败时任务必须明确置 failed 并回写 error_message，素材卡片允许用户重试，不允许静默卡死（与 #1714 processing 超时兜底同一套机制） **P2-3 容量规划（本次只出方案，不实施）** 1. 评估独立 worker 节点 / GPU 转码 worker（NVENC）方案与成本 2. 当前 load average 9+ 说明 worker 与其他服务混部已超载，转码任务高峰期会拖慢全链路，需评估 worker 横向扩容或任务隔离 单测/验证：faster preset 输出文件可正常播放、参数正确；超时配置生效；staging 长视频（10 分钟+）端到端转码成功。
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0
阻塞性，必须立即处理
 P1
高优先级
 P2
中优先级
 P3
低优先级/后考虑
 architecture
架构设计
 backend
后端相关
 blocked
阻塞中
 bug
Bug修复
 ci-bug
CI本身的bug
 ci-optimization
CI优化类任务
 ci-pipeline
CI流水线/workflow相关
 cleanup
代码清理
 devops
运维/部署/CI
 documentation
文档相关
 feature
新功能
 frontend
前端相关
 question
需要讨论确认
 ready
PR CI通过，可合并
 refactor
代码重构
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
auto-approve-bot xiaoxia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: xiaoxia/xiaoxia-saas#1733
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?