亚马逊AWS官方博客

大规模视频合并与转码

摘要：本文将分享我们如何利用AWS服务构建一套高效、经济的视频处理系统,在有限时间内完成2500部短剧(每部80-120集)的合并与转码任务。这个项目不仅展示了云计算在媒体处理领域的强大能力,更重要的是展现了如何在成本、性能和开发复杂度之间找到最佳平衡点。

一、引言

在流媒体内容快速增长的今天，内容分发平台面临着前所未有的技术挑战。本文将分享我们如何利用AWS服务构建一套高效、经济的视频处理系统，在有限时间内完成2500部短剧（每部80-120集）的合并与转码任务。这个项目不仅展示了云计算在媒体处理领域的强大能力，更重要的是展现了如何在成本、性能和开发复杂度之间找到最佳平衡点。

二、业务背景与挑战

2.1 项目需求

我们的客户是一家海外短剧发行、运营平台，跟国内内容平台合作，将国内的短剧分发到海外不同的国家和地区发行，面临以下具体需求：

  • 规模：2,500部存量短剧需要处理，后续还有增量短剧需求
  • 集数：每部短剧包含80-120集
  • 单集规格：1-3分钟时长，200-400MB文件大小，HD分辨率
  • 处理要求：将每部剧的所有集数合并为单个视频文件
  • 转码要求：统一码率至2.5Mbps，便于后续分发
  • 字幕处理：支持SRT和ASS格式字幕文件的合并

2.2 时间压力

最关键的挑战来自于时间约束。由于源视频存储在第三方网盘服务，下载链接有效期有限，我们必须在过期前完成所有处理：

  • 每天需要处理200-600部短剧
  • 超过期限后，重新获取链接的成本和时间成本极高
  • 需要24/7不间断处理，充分利用计算资源

2.3 技术挑战

这个项目面临的核心技术挑战包括：

  1. 高并发处理：如何同时处理多部短剧而不互相干扰
  2. 资源调度：每部剧的处理时间差异很大（取决于集数和文件大小），如何高效调度计算资源
  3. 成本控制：媒体处理通常需要强大的计算能力,如何在满足性能要求的同时控制成本
  4. 容错机制：网络下载、视频处理都可能失败，需要完善的错误处理和重试机制
  5. 可观测性：需要实时了解处理进度，及时发现和处理异常

三、方案对比与选择

在技术选型阶段，我们评估了多种AWS服务组合，以下是详细的对比分析。

3.1 方案一：AWS Step Functions + AWS Elemental MediaConvert

服务介绍

  • AWS Step Functions是一个无服务器编排服务，可以将多个AWS服务组合成业务关键型应用程序。通过可视化工作流，您可以按顺序协调分布式应用程序和微服务组件。
  • AWS Elemental MediaConvert 是一个基于文件的视频转码服务，专为广播级视频内容处理而设计。它支持广泛的输入格式和编解码器，可以创建多种输出格式的视频资产，适用于点播(VOD)内容交付。

方案架构

图1

优点

  • 托管式服务：完全无需管理基础设施和服务器
  • 专业级功能：MediaConvert提供广播级视频质量，支持高级视频处理功能（HDR、Dolby音频等）
  • 可视化工作流：Step Functions提供直观的工作流设计和监控界面

缺点

1. 成本过高

MediaConvert按输出视频的分钟数计费。以HD，25fps视频为例：

  • Basic tier: $0.015/分钟
  • Professional tier: $0.030/分钟

成本计算 (以Basic tier为例)：

  • 每部剧：100集 × 2分钟 = 200分钟
  • 单部成本：200分钟 × $0.015 = $3.00
  • 2500部总成本：2500 × $3.00 = $7,500

这还未包括前置步骤的成本：

  • 额外的Lambda成本：需要先下载视频并上传到S3（MediaConvert只能处理S3上的文件）
  • S3存储成本：需要临时存储原始文件（每部剧约30GB × 2500 = 75TB）
  • 数据传输成本：从网盘下载，然后上传到S3

实际总成本可能超过$10,000，是我们最终方案成本($2,875)的3.5倍。

2. 架构复杂度

由于MediaConvert只能处理S3上的视频，工作流变为:

  • Lambda触发，从网盘下载视频
  • 上传所有集数到S3
  • MediaConvert执行合并和转码
  • 清理临时文件

这意味着需要处理两次网络传输（下载+上传到S3），增加处理时间。

3. 功能过度设计

对于简单的视频合并和统一码率转码任务，MediaConvert的专业级功能（如HDR、Dolby Atmos支持）利用率极低，相当于为用不到的功能付费。

4. 并发限制

MediaConvert默认并发任务数有限，需要提交Support工单申请配额提升，增加项目启动时间。

3.2 方案二：Amazon SQS + Auto Scaling Group + Amazon EC2

服务介绍

  • Amazon SQS (Simple Queue Service) 是一个完全托管的消息队列服务，用于分离和扩展微服务、分布式系统和无服务器应用程序。消息可以在队列中等待，直到有消费者来处理。
  • Amazon EC2 Auto Scaling 可自动调整Amazon EC2实例的数量，以维持应用程序的可用性，并根据您定义的条件自动增加或减少EC2实例。

方案架构

图2

优点

  • 相对灵活：可以选择最适合的EC2实例类型（计算优化型c5.2xlarge等）
  • 成本可控：比MediaConvert更便宜，EC2按小时计费
  • 无外部依赖：可以直接从网盘下载处理，无需先上传到S3

缺点

1. 扩缩容复杂性高

Auto Scaling的核心挑战在于如何准确预测资源需求：

问题场景A：资源浪费

时间线: 00:00 ─────────────────────── 03:00
任务数:   100 ──────→ 20 ────────→ 5
EC2数:    50 ──慢慢缩容→ 30 ──→ 20  ❌ 太慢!
         └─ 这30分钟内,30台EC2只处理20个任务
            浪费10台EC2的成本

问题场景B：资源不足

时间线: 00:00 ────────→ 00:30 ────────→ 01:00
任务数:    10 ─────→ 100 (突增) ──→ 等待
EC2数:     5 ──慢慢扩容→ 20 ──→ 50
          └─ 从5台扩展到50台需要15-20分钟
             期间80个任务在SQS中等待
             网盘链接可能超时

为什么会出现这些问题？

  • 扩容延迟：EC2实例从启动到就绪需要2-5分钟（启动OS + 加载应用 + Docker镜像）
  • 缩容保守：Auto Scaling默认策略倾向于保守缩容，避免频繁扩缩容。但这会导致低负载时浪费资源
  • 指标滞后：CloudWatch指标有1-5分钟延迟，Auto Scaling做决策时可能基于过时数据
  • 阈值设置困难：
    • 设置过低（如CPU>50%扩容）：频繁扩缩容，成本高
    • 设置过高如（CPU>80%扩容）：反应慢，任务积压

实际调优的复杂性：

需要精心设置的参数包括：

  • 容量配置：最小实例数（避免冷启动）、最大实例数、初始期望容量
  • 扩容策略：扩容冷却时间（如5分钟）、每次扩容数量（如10台）、扩容阈值（如CPU>70%）
  • 缩容策略：缩容冷却时间（如10分钟，更保守）、每次缩容数量（如2台，缓慢）、缩容阈值(如CPU<30%）
  • 高级指标：SQS队列深度、自定义CloudWatch指标、预测性扩展（需要历史数据）

即使精心调优，仍然难以应对任务数量的剧烈波动，并且这些参数需要根据实际运行情况不断调整。

2. 实例启动时间长

EC2实例从零到就绪的时间线：

00:00  Auto Scaling发起启动请求
00:30  EC2实例启动(分配资源、启动OS)
01:30  挂载EBS卷,读取数据
02:00  应用程序初始化
02:30  拉取Docker镜像(如果使用容器)
03:00  ✅ 实例就绪,开始处理任务

总耗时：3-5分钟，在高峰期这会导致大量任务等待。

3. 需要管理实例生命周期

  • 实例健康检查：不健康实例需要自动替换
  • AMI管理：更新应用时需要创建新AMI
  • 实例回收：确保任务完成后才能终止实例（否则任务丢失）
  • 磁盘空间管理：处理过程中产生的临时文件可能填满磁盘

4. 运维复杂度

需要持续监控和调优：

  • 每周review Auto Scaling指标，调整阈值
  • 分析成本报告，优化实例类型
  • 处理因扩缩容导致的任务失败

对于小团队，这些运维工作会消耗大量时间。

3.3 方案三：AWS Lambda + AWS Batch + AWS Fargate （最终选择）

服务介绍

  • AWS Lambda是一项无服务器计算服务，让您无需预置或管理服务器即可运行代码。Lambda在需要时执行代码，并自动扩展，您只需为消耗的计算时间付费。
  • AWS Batch是一个完全托管的批处理服务，可以在AWS云中有效地运行任何规模的批处理计算作业。Batch会根据提交的作业的数量和资源需求，自动预置最优数量和类型的计算资源。
  • AWS Fargate是一个用于容器的无服务器计算引擎，可与Amazon ECS和Amazon EKS配合使用。使用Fargate，您无需预置和管理服务器，可以按应用程序指定和支付资源费用，并通过设计实现应用程序隔离，从而提高安全性。
  • Amazon DynamoDB是一个完全托管的NoSQL数据库服务，提供快速且可预测的性能以及无缝扩展能力。
  • Amazon CloudWatch是一项针对AWS云资源和在AWS上运行的应用程序的监控和可观测性服务。可以使用CloudWatch收集和跟踪指标、收集和监控日志文件以及设置告警。
  • Amazon SNS (Simple Notification Service) 是一个完全托管的消息收发服务，支持应用程序到应用程序(A2A)和应用程序到用户(A2P)通信。

方案架构

图3

优点

1. Lambda：轻量级任务调度

  • 无需管理服务器
  • 按调用次数计费（百万次请求仅$0.20）
  • 自动扩展（可同时执行数千个调用）
  • 毫秒级启动时间

2. AWS Batch：智能任务调度

  • 自动资源管理：无需手动设置扩缩容策略
  • 作业队列：自动排队、优先级管理
  • 自动重试：失败任务自动重试
  • 零学习曲线：提交任务就像调用API一样简单

3. Fargate：真正的按需计费

  • 按秒计费：任务运行2.5小时就付2.5小时的费用
  • 无空闲成本：没有任务时费用为零
  • 快速启动：30-60秒即可启动容器（比EC2快5倍）
  • 无需管理：不用关心实例健康、AMI更新等

4. 成本可控

成本计算（以2500部剧为例）：

  • 单任务成本：8 vCPU × $0.04048/小时 + 32GB × $0.004445/小时 = $0.46/小时
  • 每部处理时间：平均2.5小时
  • 单部成本：2.5 × $0.46 = $1.15
  • 2500部总成本：2500 × $1.15 = $2,875

5. 弹性伸缩简单

Batch + Fargate的扩缩容完全自动化：

任务提交 → Batch检查队列 → 自动启动Fargate容器
任务完成 → 容器自动终止 → 费用立即停止

无需设置任何CloudWatch告警或扩缩容策略，一切“开箱即用“。

缺点

1. Fargate单任务成本略高于EC2

如果使用EC2 Spot实例，单小时成本可能比Fargate低30-50%。但考虑到：

  • Spot实例可能被中断（需要处理中断逻辑）
  • 需要管理扩缩容
  • 需要处理实例生命周期

总体拥有成本(TCO)仍然是Fargate更低。

2. 需要容器化应用

需要编写Dockerfile和容器化应用。但这也带来好处：

  • 本地开发环境与生产完全一致
  • 易于版本管理和回滚

3.4 最终决策

经过成本、复杂度和性能的综合评估，我们选择了方案三(Lambda + Batch + Fargate)，原因如下：

维度 方案一(MediaConvert) 方案二(EC2 ASG) 方案三(Fargate) ✅
1 成本 $7,500+ $3,500-4,000 $2,875
2 扩缩容复杂度 低(托管) 高(需精心调优) 低(全自动)
3 启动速度 N/A 3-5分钟 30-60秒
4 运维工作量 低 高(需持续监控) 极低
5 开发复杂度 中(需上传S3) 中 低(直接处理)

虽然Fargate的单位成本比EC2略高，但考虑到：

  • 无运维负担：小团队无需花时间调优Auto Scaling
  • 按秒计费：无空闲成本
  • 快速启动：减少任务等待时间，更快完成项目
  • 总成本最低：比其他方案节省40-60%

方案三是最优选择。

四、架构设计

4.1 系统架构图

图4

4.2 核心组件

1. Amazon S3

  • 输入存储：存储每部剧的元数据JSON文件(包含所有集数的下载链接)
  • 输出存储：存储处理完成的合并视频和字幕文件
  • 生命周期：配置生命周期策略，30天后转移至S3 Glacier以降低存储成本

2. AWS Lambda （任务提交器）

Lambda函数作为系统的入口点，负责：

  1. 读取S3上的元数据文件列表
  2. 检查DynamoDB确认任务是否已完成（避免重复处理）
  3. 对于未完成的任务,调用AWS Batch API提交作业
  4. 更新DynamoDB记录任务状态

关键设计点：

  • 幂等性：通过DynamoDB检查避免重复提交
  • 批量处理：单次调用可提交多个任务
  • 超时设置：10分钟超时，足够处理大批量提交

3. AWS Batch

Batch服务管理整个任务生命周期：

作业队列(Job Queue)：

  • 优先级：1 （支持未来扩展不同优先级的任务）
  • 自动调度：根据Compute Environment的容量自动分配任务

计算环境(Compute Environment)：

  • 平台：Fargate
  • 类型：On-Demand (我们评估后发现Spot实例的中断风险对长时间任务影响较大)
  • 最大vCPU：800 (= 100并发任务 × 8 vCPU)
  • 网络：使用默认VPC的公有子网，确保能访问ECR和外部网盘

作业定义(Job Definition)：

  • 自动重试：1次
  • 超时设置：8小时（单个任务最长处理时间）
  • 公网访问：启用公网IP以访问ECR和外部网盘

资源配置考量：

  • 8 vCPU：FFmpeg转码可以充分利用多核并行
  • 32 GB内存：处理大文件时内存缓冲
  • 100 GB临时存储：存储下载的原始文件(约20GB)+ 合并/转码过程中的临时文件

4. Fargate 容器

容器内包含完整的处理流程，基于Amazon Linux 2023镜像，预装Python 3.11和FFmpeg（静态编译版本，性能优化）。

处理流程：

下载阶段：

  • 并发下载多集(使用线程池可进一步优化)
  • 支持断点续传和重试
  • 实时输出下载进度和速度

视频合并：

ffmpeg -f concat -safe 0 -i filelist.txt -c copy output.mp4
  • 使用-c copy避免重新编码，保持原始质量
  • 速度极快（仅做文件级别的拼接）

智能转码：

  • 使用ffprobe检测合并后的码率
  • 仅当码率>4Mbps时才转码（节省计算资源）
ffmpeg -i input.mp4 -c:v libx264 -preset fast \
  -b:v 4M -maxrate 4M -bufsize 8M \
  -c:a aac -b:a 192k output.mp4
  • preset fast: 平衡速度和压缩率
  • -threads 0: 自动利用所有可用CPU核心

字幕合并：

  • SRT格式：调整时间戳后简单拼接
  • ASS格式：解析事件时间轴，重新计算后合并

上传S3：

  • 使用multipart upload提高大文件上传速度
  • 更新DynamoDB状态为completed

5. Amazon DynamoDB

使用DynamoDB跟踪每部剧的处理状态：

表结构：

Table: video-merge-jobs
Primary Key: series_id (String)

Attributes:
- series_name: 剧名
- metadata_path: 元数据S3路径
- status: submitted | running | completed | failed
- batch_job_id: Batch作业ID
- submitted_at: 提交时间
- started_at: 开始处理时间
- completed_at: 完成时间
- output_s3_path: 输出文件S3路径
- error_message: 错误信息(如果失败)
- retry_count: 重试次数

查询模式：

  • 按状态查询：使用GSI(Global Secondary Index)按status查询所有失败任务
  • 幂等性检查：Lambda提交前查询，避免重复处理

6. Amazon CloudWatch + SNS

监控指标：

  • AWS Batch队列中的RUNNABLE任务数（等待资源的任务）
  • AWS Batch队列中的RUNNING任务数
  • 失败任务数量（从DynamoDB查询）
  • 每小时完成任务数

告警配置：

  • RUNNABLE任务持续>30分钟：可能需要增加并发数
  • 失败率>5%：需要人工介入检查
  • 单个任务运行时间>6小时：可能卡住，需要检查

五、实现细节与最佳实践

5.1 成本优化

策略：

  • 按需付费：只在处理时付费，无空闲成本
  • 智能转码：只有高码率视频才转码，节省约40%计算时间
  • 存储分层：
    • 原始元数据：S3 Standard
    • 输出视频：7天后转移至S3 Standard-IA

成本分析（处理2500部短剧）：

计算成本 (Fargate):
- 8 vCPU × $0.04048/vCPU-hour = $0.32/hour
- 32 GB × $0.004445/GB-hour = $0.14/hour
- 总计: ~$0.46/hour/task
- 平均处理时间: 2.5小时/部
- 总计算成本: 2500 × 2.5 × $0.46 = ~$2,875

存储成本 (S3):
- 输出: 2500部 × 6GB/部 = ~15TB
- S3 Standard: 15TB × $0.023/GB = ~$345/月

其他成本:
- Lambda: 可忽略(每次调用几百ms)
- DynamoDB: 可忽略(2500条记录)
- CloudWatch: <$50/月

总成本: ~$2,875 (一次性) + $345/月 (存储)

与MediaConvert方案对比，节省约**70%**成本。

5.2 性能优化

并发控制：

  • 初期：并发10测试稳定性
  • 验证后：逐步提升至50 → 100
  • 最大并发：100

瓶颈分析：通过CloudWatch Logs分析，典型处理时间分布：

  • 下载：10-20% （受网盘速度限制）
  • 合并：0.5-1%（几乎无CPU消耗）
  • 转码：70-90% （CPU密集型）
  • 上传S3：0.1%

优化措施：

  • 下载优化：增加HTTP连接数，使用多线程下载
  • 转码优化：FFmpeg preset fast平衡速度和质量
  • 上传优化：S3 multipart upload

5.3 容错设计

重试机制：

  • AWS Batch层：自动重试1次（作业定义配置）
  • 应用层：下载失败自动重试
  • 手动重试：提供脚本扫描DynamoDB中的失败任务，重新提交

状态管理：

submitted → running → completed
                  ↓
                failed → (manual retry) → submitted

失败处理：

  • 容器内捕获所有异常，记录到DynamoDB
  • CloudWatch日志保留30天，便于事后分析
  • SNS告警通知运维人员

5.4 可观测性

实时监控：我们开发了监控脚本，定期扫描DynamoDB统计各状态的任务数(submitted、running、completed、failed)，并计算完成百分比和失败率。这个脚本可以手动运行或通过cron定时执行。

CloudWatch Dashboard:

  • 实时任务状态分布
  • 每小时完成数趋势
  • 平均处理时间
  • 失败率趋势

六、运维实践

日常监控：

  • 每小时检查CloudWatch Dashboard
  • 关注SNS告警邮件
  • 定期查看失败任务列表

故障排查：

  1. 查看CloudWatch Logs定位具体任务
  2. 检查DynamoDB中的error_message
  3. 手动重试或调整参数

扩容计划：

  • 当前：100并发
  • 如需提升：
    • 申请Fargate配额提升
    • 调整Batch Compute Environment的max vCPUs
    • 无需修改代码

七、成果与经验总结

7.1 项目成果

经过三天的开发和1周的测试调优，系统成功投入生产：

  • ✅ 并发能力：稳定支持100并发任务
  • ✅ 处理速度：每天完成800-1,000部短剧处理
  • ✅ 按时完成：在网盘链接过期前完成全部2,500部短剧
  • ✅ 成本控制：总成本比初始MediaConvert方案节省60%

关键数据：

  • 总处理量：2,500部短剧，约250,000集视频
  • 总数据量：输入75TB，输出20TB
  • 总处理时间：3天(72小时，按100并发计算)
  • 平均每部处理时间：2.5小时

7.2 经验与教训

1. 选择合适的服务组合

教训：不要盲目追求“最先进“或“最专业“的服务。

  • MediaConvert虽然专业，但对于简单合并任务过度设计
  • FFmpeg + Fargate的组合足够满足需求，且成本更低

原则：根据实际需求选择服务，而不是服务的知名度。

2. 容器化的价值

好处：

  • 本地开发环境与生产环境完全一致
  • 方便测试和调试
  • 易于版本管理和回滚

建议：即使是简单脚本，也建议容器化部署。

3. 可观测性不是可选项

教训：早期没有完善的监控，导致发现问题滞后。

改进：

  • 从第一天就建立CloudWatch Dashboard
  • 设置关键指标告警
  • 实时监控脚本每小时自动运行

原则：”看不见的系统无法优化“。

4. 成本优化从设计开始

策略:

  • 智能转码：不是所有视频都需要转码
  • 按需付费：Fargate按秒计费，无空闲成本
  • 存储分层：自动转移至低成本存储

效果：比初始方案节省60%成本。

5. 从小规模开始

实践:

  • 第一天：并发1，处理1部测试，并观察日志优化代码和错误处理
  • 第二天：并发50，全面压测，检查结果视频
  • 第三天：并发100，正式生产

原则：逐步扩展比一次性全量更安全。

6. 基础设施即代码的价值

好处:

  • 环境可重现
  • 变更可追溯
  • 快速部署

建议：使用基础设施即代码工具（如AWS CDK）而不是手动在控制台操作，这样可以轻松创建多个环境（开发、测试、生产）并确保配置一致性。

八、结语

本项目展示了如何利用AWS的托管服务构建一套高效、可靠、经济的大规模视频处理系统。通过合理的架构设计和服务选型，我们在3天内处理了2,500部短剧，总计75TB的数据，且总成本仅为初始方案的40%。

关键成功因素：

  • 合适的技术选型: Lambda + Batch + Fargate的组合平衡了性能、成本和复杂度
  • 智能处理策略：按需转码节省大量计算资源
  • 完善的监控体系：实时掌握处理进度和系统健康状态
  • 渐进式扩展：从小规模测试逐步扩展至100并发

希望这个案例能为有类似大规模媒体处理需求的客户提供参考。如果您有任何问题或想深入讨论技术细节，欢迎通过AWS Support或AWS论坛联系我们。

➡️ 下一步行动：

相关产品：

  • Amazon Batch — 任意规模的完全托管式批处理
  • Amazon Fargate — 适用于容器的无服务器计算
  • Amazon S3 — 适用于 AI、分析和存档的几乎无限的安全对象存储
  • Amazon EC2 — 安全且可调整大小的计算容量，支持几乎所有工作负载
  • AWS Lambda — 无需考虑服务器或集群即可运行代码的服务

相关文章：

九、参考资源

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

Fox Qin

亚马逊云科技快速原型团队资深解决方案架构师，主要负责Serverless和生成式人工智能Agent方向的架构设计和原型开发，此外对亚马逊云科技的IoT服务、跨地区的多账号 Organization、网络管理、解决方案工程化部署等方面也有深入的研究。

彭赟

亚马逊云科技资深解决方案架构师，负责基于亚马逊云科技的云计算方案架构咨询和设计，20 多年软件架构、设计、开发、项目管理交付经验，擅长业务咨询、产品设计、软件架构，在大数据、区块链、容器化方向有较深的入研究，具有丰富的解决客户实际问题的经验。

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用