一、执行摘要
方案不把视频增强视为一条不可观察的命令，而是拆成可校验、可缓存、可恢复的阶段式任务。 超分负责空间分辨率，补帧负责时间分辨率，FFmpeg 负责媒体解析、时间轴和封装，任务编排层负责可靠性。
空间增强
使用 Real-ESRGAN 对帧进行 2× 或 4× 超分，再按目标分辨率缩放，避免直接拉伸造成细节模糊。
时间增强
使用 RIFE 在相邻帧之间预测中间帧，实现 30→60fps 或其他 2× 帧率提升。
工程治理
记录源媒体参数、阶段产物、模型版本和校验结果，解决临时目录、断点恢复、音画不同步与重复执行问题。
二、问题定义与约束
业务目标
- 将横屏 720p 输出为 1920×1080，竖屏输出为 1080×1920。
- 支持保持原帧率，或按配置执行 2× 补帧。
- 保留原音频、时长、旋转信息和宽高比。
- 支持单文件、本地批处理和未来网络任务模式。
硬件与工程约束
- Windows 11，RTX 4070 Laptop GPU，约 8GB 显存。
- 优先使用 NCNN Vulkan 版本，降低 Python/CUDA 依赖复杂度。
- 真人视频需要控制人脸漂移、眼睛变形和帧间闪烁。
- 源帧率可能是 30、29.97 或有理数，不能简单取整。
典型失败模式
| 问题 | 根因 | 架构应对 |
|---|---|---|
| 音画不同步 | 帧数变化后仍沿用错误时间基，或音频被重复拉伸 | 视频时间轴与音频时间轴独立处理，最终按目标时长封装 |
| 输出时长变化 | 错误使用源 FPS、目标 FPS 或图片序列编号缺失 | 以 ffprobe 的有理帧率和实际产物帧数共同校验 |
| 人脸闪烁 | 逐帧超分缺少时间一致性 | 保守锐化、帧间质量检测，必要时切换视频时序模型 |
| 显存或内存不足 | 高分辨率、过大 tile、PNG 中间帧数量过多 | Tile 推理、分段处理、临时空间预估和自动降级 |
| 处理一半失败 | 脚本缺少阶段记录，只能全部重跑 | 阶段 Manifest、幂等目录和断点恢复 |
三、完整处理流水线
每一阶段都有输入、输出、校验器和幂等键。阶段成功后写入 Manifest，失败可从最近成功点恢复。
默认顺序：超分 → 补帧
先增强真实帧细节，再让 RIFE 基于更清晰的运动边界生成中间帧。适合画质优先、片段较短的本地处理。
低资源顺序：补帧 → 超分
先在低分辨率完成插帧，再超分全部帧。单次插帧负载更低，但超分帧数量翻倍，总耗时可能更高。
四、系统架构
五、任务模型与状态机
EnhanceJob 聚合
维护任务状态、当前阶段、处理计划、输入输出资产、失败原因和重试次数。
Invariant 同一阶段同一参数只能提交一次有效产物。
MediaProfile 值对象
保存宽高、SAR、DAR、帧率分数、时长、时间基、音频流和旋转信息。
Invariant 帧率使用分数表达，禁止在核心逻辑中提前取整。
PipelinePlan 值对象
冻结目标尺寸、处理顺序、模型、tile、输出编码和质量参数。
Invariant 任务执行期间参数不可隐式变化，修改需创建新版本。
状态流转
任务 Manifest 示例
六、超分与补帧算法策略
超分策略
- 默认：Real-ESRGAN NCNN Vulkan，2× 推理后缩放至精确 1080p。
- 原因：直接 4× 后强降采样耗时和临时空间更高；直接插值则无法恢复纹理。
- 真人视频：使用低锐化、低降噪，避免皮肤塑料感和眼部伪纹理。
- 资源控制：根据显存自动选择 tile，失败时逐级降低 tile。
补帧策略
- 默认：RIFE 2×，例如 30→60fps、29.97→59.94fps。
- 时间基：目标帧率由源帧率分数乘倍率得到，不写死为 60。
- 复杂运动：镜头切换、遮挡和快速肢体运动区域容易产生融合伪影。
- 保护：镜头切换检测可禁止跨场景插帧。
处理参数建议
| 场景 | 超分 | 补帧 | 编码建议 |
|---|---|---|---|
| 真人 720p → 1080p | 2× 后 Lanczos 下采样，轻锐化 | RIFE 2×，启用场景切换保护 | H.265 10-bit 或高质量 H.264 |
| 动漫 / 插画 | 动漫专用模型，可适度锐化 | RIFE 2× | H.265，保留线条 |
| 低清压缩视频 | 先轻度去块，再保守超分 | 视运动质量决定 | 避免低码率二次压缩 |
| 短视频批处理 | 固定模板与分辨率策略 | 按需开启 | 统一色彩和像素格式 |
推荐默认配置
竖屏输出 1080×1920，横屏输出 1920×1080；保持原画幅，不裁切主体；GPU 固定为 -g 0。
明确不做
不把逐帧超分宣传为真实细节还原；不强行把所有视频补到 60fps；不在未验证时开启高强度人脸增强。
七、音画同步与媒体封装
补帧增加的是视频帧数量，不应改变内容时长。系统需要重新构建视频时间轴，但音频通常保持原时长和采样率。
帧率计算
源帧率为 30000/1001 时，2× 目标应为 60000/1001，而不是直接写成 60。
音频映射
优先直接映射源音频；容器不兼容时再转 AAC。音频不参与补帧，不做速度变化。
结束策略
以视频与音频合理的共同边界结束；出现毫秒级差异时，按容器和播放器兼容性处理。
同步校验
| 校验项 | 判定条件 | 失败处理 |
|---|---|---|
| 时长差 | 输出与源视频差异在允许阈值内 | 检查输入帧率、输出帧率和尾帧处理 |
| 预期帧数 | 约等于源帧数 × 插帧倍率 | 检查 RIFE 输出编号、缺帧和重复帧 |
| 音频流 | 存在且可解码，声道和采样率符合计划 | 重新映射或转码音频 |
| 播放器兼容 | 主流播放器可正常拖动与播放 | 修正时间戳并重新封装 |
八、质量评估体系
客观指标
| 分辨率与帧率 | 必须与处理计划一致 |
| VMAF / SSIM | 用于压缩与重编码质量比较 |
| 帧间差异 | 检测闪烁、重复帧和异常跳变 |
| 光流一致性 | 检测补帧运动是否连续 |
| 黑帧 / 冻结帧 | 识别处理链路损坏 |
主观验收
| 人脸稳定性 | 眼睛、牙齿、发丝是否跳动或变形 |
| 运动自然度 | 快速动作是否出现重影、拉丝和融合 |
| 纹理真实性 | 是否产生虚假毛孔、过锐边缘 |
| 色彩一致性 | 帧间亮度、肤色和饱和度是否漂移 |
| 音画同步 | 口型、节奏和声音事件是否一致 |
质量门禁
尺寸、帧率、时长、音频正确。
文件可解码、可拖动、无损坏。
首、中、尾及高运动片段通过。
严重闪烁、黑帧或音画偏移禁止发布。
九、可靠性、资源治理与可观测性
断点恢复
- 每阶段输出独立目录。
- 成功后写完成标记和校验和。
- 重启时验证产物后跳过已完成阶段。
- 参数变化创建新计划，不复用旧产物。
资源治理
- 执行前预估帧数和临时磁盘空间。
- 限制单机同时运行的 GPU 任务数。
- 使用 tile、分段和流式删除中间帧。
- GPU 失败时自动降低 tile，而非静默切换核显。
可观测性
- 任务级 traceId 和阶段耗时。
- 记录 FFmpeg、模型和参数版本。
- 采集 GPU 利用率、显存、温度和磁盘空间。
- 保留 stderr 摘要和退出码。
失败处理矩阵
| 失败类型 | 处理策略 | 自动恢复 |
|---|---|---|
| 工具或模型文件缺失 | 启动前依赖检查，输出缺失路径 | 否 |
| 显存不足 / Vulkan 失败 | 降低 tile、减少并发、重新执行当前阶段 | 是 |
| 帧序列不连续 | 定位缺失编号，重跑产生异常的阶段 | 是 |
| 临时磁盘不足 | 暂停任务、清理未引用产物、保留恢复点 | 条件恢复 |
| 封装失败 | 保留已增强帧，单独重跑编码阶段 | 是 |
| 质量门禁失败 | 切换保守参数或标记人工检查 | 最多一次 |
十、本地工具与网络服务形态
形态 A：本地工具链
组成：BAT / PowerShell + FFmpeg + Real-ESRGAN NCNN + RIFE NCNN + 本地 Manifest。
优势：部署简单、数据不出本机、无云端 GPU 成本，适合作品展示和个人批处理。
代价：任务管理、远程访问和多用户能力有限。
形态 B：Cloudflare + 本地 GPU Worker
组成：Pages、Workers、D1、R2、Queues 与 Windows GPU Worker。
流程：上传到 R2 → 队列派发 → GPU Worker 拉取 → 上传成品 → Worker 通知结果。
代价：需要处理大文件分片、Worker 心跳、任务租约和上传安全。
十一、架构与算法权衡
关键 ADR
ADR-001：采用逐阶段 Manifest
Context：拆帧和 AI 推理耗时长，处理中断后全部重跑成本高。
Decision：每阶段记录参数、产物和校验和。
Consequences：增加元数据和清理逻辑，但获得可恢复性与审计能力。
ADR-002：帧率使用有理数
Context：29.97fps 等帧率直接取整会积累时长误差。
Decision：领域模型中保留分子和分母。
Consequences：计算稍复杂，但避免长视频音画漂移。
ADR-003：默认使用 NCNN Vulkan
Context：Windows 上 Python、PyTorch、CUDA 版本冲突维护成本高。
Decision：MVP 使用独立可执行文件和 Vulkan 推理。
Consequences：部署稳定，但训练和深度定制能力低于 PyTorch。
ADR-004：模块化单体而非微服务
Context：当前是单机单 GPU，团队和任务规模有限。
Decision：先统一任务编排，通过端口隔离工具。
Consequences：开发与部署简单；规模扩大后再拆 GPU 调度和媒体服务。
十二、接口与数据设计
核心 API
| POST /v1/enhance-jobs | 创建视频增强任务 |
| GET /v1/enhance-jobs/:id | 查询任务与阶段进度 |
| POST /v1/enhance-jobs/:id/resume | 恢复失败任务 |
| POST /v1/enhance-jobs/:id/cancel | 请求取消任务 |
| GET /v1/enhance-jobs/:id/artifacts | 获取成品与质量报告 |
核心数据表
| enhance_job | 任务状态与处理计划 |
| media_asset | 源视频、成品和预览资产 |
| stage_execution | 阶段执行、退出码和耗时 |
| artifact_manifest | 阶段产物、数量和校验和 |
| quality_report | 结构与视觉质量结果 |
| worker_lease | 网络模式下的任务租约 |
十三、实施与演进路线
拆分服务的触发条件
| 触发条件 | 演进动作 |
|---|---|
| 出现多台 GPU Worker | 拆出 Worker Registry 与任务租约服务 |
| 上传和下载成为性能瓶颈 | 拆出媒体资产服务，支持分片和断点续传 |
| 质量评估耗时明显增加 | 评估异步化，独立 Quality Worker |
| 不同模型需要独立扩缩容 | 按 Upscale、Interpolation、Encode 分队列 |
十四、结论
本方案将 FFmpeg、Real-ESRGAN 和 RIFE 从若干命令行工具，组织成一套可恢复、可观测、可扩展的视频增强流水线。 它不仅解决 720p→1080p、30→60fps 和音频保留问题，还明确处理了帧率精度、时间轴、显存限制、 临时文件、质量门禁和网络服务化等工程风险。