Zee5 如何使用内部开发的转码器对垂直视频进行转码

背景介绍

随着时间的推移，竖屏（9:16 宽高比）格式的短视频越来越受欢迎。在各种社交媒体平台上，你都能发现大量用户正在观看这类内容。这些视频通常时长较短（少于 2 分钟），用户可以在很短的时间内获得观看的满足感。这些竖屏（9:16 宽高比）的视频与手机设备的自然宽高比完美契合。随着屏幕尺寸的增大，高质量 Reels 内容的重要性也日益凸显。

印度视频流媒体平台 Zee5 娱乐大众的众多方式中，短视频扮演着重要的角色。

由于用户群体庞大，需要处理和发布的内容量也非常巨大。2024年9月之前，所有这些内容的转码工作均由该领域一家领先公司的托管转码解决方案完成。虽然转码内容的质量相当不错，但对如此大量的内容进行转码的成本却相当高昂。

作为一家公司， Zee5去年计划将其基于云的基础设施迁移到使用Google 云平台(GCP)。但上述托管转码服务在 GCP 上无法使用。虽然有商业替代方案，但其想法是提出一个可扩展的转码解决方案，以相同的速度（与现有解决方案相同）生成质量更高（比现有解决方案生成的内容更好）且成本更低（既然如此，为什么不让生成的内容压缩得更好呢）！

只有内部构建的转码解决方案才能实现所有这些！

要求

生成的内容应具有 AVC 视频和 AAC 音频，并封装在 MP4 容器格式中。
对于单个内容源，需要生成 5 个不同的版本，所有版本均具有相同的分辨率 (720×1280)，但比特率不同。上述某些版本需要嵌入多个徽标（不重叠）。
上述某些版本需要与简短的（几秒钟的）广告视频拼接在一起。
还需要支持从源内容中提取音频以及从源内容的任意点提取缩略图。
源内容可以是任何帧速率、编码类型，但通常最高可达 1080×1920 分辨率。
解决方案需要能够根据要转码的内容量进行扩展，通常，白天和晚上（印度标准时间）要转码的内容量比深夜到清晨（IST）时段要高得多。
完成转码（生成所有必需的演示内容以及其他操作，例如插入徽标、添加场记板等）所需的时间必须小于源内容的时长，并且越短越好。尽可能缩短发布这些内容的时间是必需的，而转码时间是内容发布时间的主要影响因素之一。

架构

内部开发的转码解决方案部署在云原生节点集群上，可根据集群 CPU 的使用情况进行增减。由于转码是计算密集型活动，因此选择了适当的 CPU 类型，以最具成本效益和容错的方式最大限度地提高计算效率。

转码器以消息驱动的方式工作，下图描述了转码器之间的数据流和控制流：

一旦内容上传到源存储桶，预先存在的服务（在图表上称为Transcoding Input service）就会创建一条消息，描述要转码的内容的路径、要执行的操作和目标路径，并发布到消息队列（在图表上称为Transcoding Input Message Queue）。
消息格式经过精心设计，以满足当前和未来的需求。
与 Transcoder 相关的 Pod 从队列中获取消息并确保操作完成。
一旦给定的转码器 pod 完成请求的操作，它就会通过按照预定义规范将消息写入另一个消息队列（在上图中表示为Transcoding Status Message Queue）来通知操作状态和其他相关详细信息，然后从队列中读取下一条可用消息。
然后，发布服务负责根据现有流程发布已完成转码的内容。

消息驱动、定义清晰的架构和精妙的实现确保了转码器与现有服务的无缝集成，并按计划准时部署。集成过程中，转码解决方案未出现任何错误报告。更重要的是，完全没有用户投诉任何关于内部构建的转码器生成内容播放失败的情况。

结果

当转码器部署完毕并开始承担 100% 的生产工作量时，下一个明显的重点就是看它的性能如何。

以下部分描述了转码器在项目开始时如何实现既定目标，即：

以更低的基础设施成本创造更好的用户体验。
与现有解决方案相比，存储/CDN 成本更低。

用户体验

这就像俗话说的“布丁测试”（也就是转码器）。团队把它视为挑战，要提供比之前方案（之前方案已经相当不错）更好的用户体验。

在 Zee 生态系统中，来自 Conviva 的指标被用作衡量用户体验的客观分析机制。使用内部构建的转码器生成的内容在最重要的用户体验指标上都有令人印象深刻的改进。

下表列出了 Conviva 提供的相关用户体验指标，与前一个月相比，自家开发的转码器在一个月内（从 2024 年 9 月 5 日开始）对将在该 UGC 平台上发布的内容进行了 100% 的转码。

日期范围	视频开始时间	重新缓冲比率	视频开始前退出	流媒体性能指标	高缓冲率	启动时间长
9月5日至10月4日	0.75秒	1.31%	24.4%	96.6	0.908%	0.632%
8月6日至9月4日	0.935秒	1.41%	25.6%	95.1	1.05%	0.836%