利用 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

测试方案

测试样本

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

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

参考 zhixue 的测试项目：

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

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

根据需要，将原视频使用 ffmpeg 拆分成若干个 clips，方便启动多个转码进程（即 Map-Reduce），参考命令

ffmpeg -nostdin -loglevel info -vsync 0 -i inputvideo.mp4 -c copy -f segment -segment_time 8 -y

启动若干个 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
...

根据 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官方博客