亚马逊AWS官方博客

利用 vt1 实例打造极致性价比转码平台

全球对视频内容的需求迅速增长,在线点播/直播公司正越来越多地寻求采用敏捷的云基础设施,期望在不牺牲可靠性的情况下降低成本,并有效地根据需求进行扩展。

2023 年 3 月 28 日,xilinx 发布了最新的 SDK v2.0.1,以提供更好的性能。基于该版本 SDK 我们对 vt1 实例进行了性能测试,测试结果超出预期。

Amazon EC2 VT1 实例类型介绍

EC2 VT1 实例有三种大小可供选择。加速的 H.264/AVC 和 H.265/HEVC 编解码器集成到 Xilinx Zynq ZU7EV SoCs 中。每张 Xilinx® Alveo™ U30 媒体转码加速器卡均包含两个 Zynq SoCs。

A B C D E F G
1 实例大小 vCPU 数量 Xilinx U30 内存 网络带宽 EBS 优化带宽 每个实例 1080p60
2 vt1.3xlarge 12 1 24GB 高达 25 Gbps 高达 4.75 Gbps 8
3 vt1.6xlarge 24 2 48GB 25 Gbps 4.75 Gbps 16
4 vt1.24xlarge 96 8 192GB 25 Gbps 19 Gbps 64

VT1 实例适用于为每个实例转码多个流。这些流可以单独进行并行处理,也可以混合处理(画中画、并排、转换)。vCPU 内核有助于实现图像处理、音频处理和多路复用。Xilinx® Alveo™ U30 卡可以在 H.264 和 H.265 中同时输出不同分辨率(1080p、720p、480p 和 360p)下的多个流。

每个 VT1 实例都可以配置为生成具有不同设置、分辨率和传输比特率(“ABR 阶梯”)的并行编码。例如,4K UHD 流可以按每秒 60 帧的速度编码,使用 H.265 进行高分辨率显示。可以使用 H.264 编码多个较低的分辨率,以便传输到标准显示器。

每个可寻址设备和实例类型的转码流数量

性能测试

测试环境信息

硬件环境

参考:https://thinkwithwp.com/cn/ec2/instance-types/vt1/

vt1.3xlarge:1 个 U30 加速卡,2 个 xcu30 soc,12 个 vcpu,24G Ram,价格 $0.65/h (On demand)

系统及软件环境

AMI:prebuilt VT1 Amazon Machine Images (AMIs) 基于 AL2

Xilinx Video SDK release:U30_AmazonLinux_2_v2.0.1

ffmpeg n4.4.xlnx.1

测试方案

测试样本

  1. 1080p 30fps h.264 
  2. 4k 60fps h.265


测试脚本以及参数调整过程

参考 zhixue 的测试项目:

结合 Xilinx Video SDK 官方文档进行参数调整:

脚本的流程分为 3 个部分:

  1. 根据需要,将原视频使用 ffmpeg 拆分成若干个 clips,方便启动多个转码进程(即 Map-Reduce),参考命令
ffmpeg -nostdin -loglevel info -vsync 0 -i inputvideo.mp4 -c copy -f segment -segment_time 8 -y
  1. 启动若干个 ffmpeg 进程,并使用 Xilinx Video SDK 插件,完成每个 clip 的转码工作,当所有进程完成后,统计所花费的总时间。需要注意 3xlarge 有 2 个 xcu soc,所以启动并发转码任务的时候,需要将任务平均分配给 2 个转码 device 如:
ffmpeg -loglevel info -xlnx_hwdev 0 -vsync 0 -c:v mpsoc_vcu_h264 -i tmpfile00.mp4 -f mp4 -bf 2 -g 120 -periodicity-idr 120 -qp-mode uniform -temporal-aq 1 -spatial-aq 0 -scaling-list 0 -lookahead_depth 20 -b:v 2.5M -max-bitrate 2.5M -c:v mpsoc_vcu_h264 -y tmpfileout00.mp4
ffmpeg -loglevel info -xlnx_hwdev 1 -vsync 0 -c:v mpsoc_vcu_h264 -i tmpfile01.mp4 -f mp4 -bf 2 -g 120 -periodicity-idr 120 -qp-mode uniform -temporal-aq 1 -spatial-aq 0 -scaling-list 0 -lookahead_depth 20 -b:v 2.5M -max-bitrate 2.5M -c:v mpsoc_vcu_h264 -y tmpfileout01.mp4
...
  1. 根据 ffmpeg 获取的原视频总帧数除以上一步的转码总时长,就得到了最终的转码 fps 的指标,最后再将视频合并并上传 S3,用于验证
ffmpeg -f concat -safe 0 -i mylist.txt -c copy output.mp4

关于 cores 和 slices 参数

Deep Dive on Amazon EC2 VT1 Instances 这篇文档中提到,Xilinx Video SDK 在转码的工作流程中,是针对低延迟的实时转码设计的,也就是说,Xilinx Video SDK 转码输出的 fps 不会超过原视频的 fps 太多,不然也没有意义。但是对于 offline 的转码 workload,可以尽用满 xcu30 device 的性能,可以使用-cores 4 -slices 4

但是在这次测试中,使用这个参数性能并没有增加,有可能是因为已经通过 map-reduce 的方式拆分多个进程,基本榨干了 xcu30 的性能了。

关于拆分进程数

根据官网介绍:vt1.3xlarge 支持同时 8 条 1080p60,2 条 4k60 的转码 streams,在这次测试中也进行了对应的验证。

结果发现对于 4k60 h265 的视频,如果当前已经存在一个 ffmpeg 进程占用一个 xcu30 设备进行转码,新提交的进程会抢占掉正在执行的进程,同时被强占的进程会报错,所以本测试依然采用 2 个进程的方式测试。

根据计算,1080p60 最大可以使用 8 个并发进程,理论上最多 1080p30 的转码进程可以有 16 个,在实际测试过程中发现,在 32 个进程时可以达到最佳性能。

测试结果

1080P 30FPS H.264 视频转码结果


40K 60FPS H.265 视频转码结果


总结

利用 vt1 实例对比 x86 EC2 实例,性价比可以提升高约 400%vt1 是我们用于高负载视频转码任务的不二选择。而 SDK v2.0.1 对比过去 SDK v1.5,提高了稳定性和性能,因此强烈建议使用 vt1 实例的时候采用最新版本的 SDK。

参考

本篇作者

林业

AWS 资深解决方案架构师,负责基于 AWS 的云计算方案的咨询与架构设计。拥有超过 14 年研发经验,曾打造千万级用户 APP,多项 Github 开源项目贡献者。在游戏、IoT、智慧城市、汽车、电商等多个领域都拥有丰富的实践经验。

夏宁

亚马逊云科技解决方案架构师,曾就职惠普软件和声网,超过 10 年前端后端开发经验,主导过各类软件项目设计。熟悉移动互联网,音视频,云计算相关领域。