新知 | 离线视频处理AOV框架&AI算力池调度

‍新知系列课程第二季来啦！我们将为大家带来全真互联时代下新的行业趋势、新的技术方向以及新的应用场景分享。本期我们邀请到了腾讯云音视频技术导师——孙祥学，为大家分享视频处理AOV框架及AI算力池调度。

本期的分享包括四个部分，分别是行业现状整体介绍，AOV框架解析，AI算力池调度设计以及MPS接入说明。

从各大云厂商的用户反馈来看，视频处理对接入用户并不友好，门槛很高。没有技术背景的用户在吐槽：“我只想把视频中的语音转成文本提取出来存档，也愿意付费，但没有开发能力，API文档看不懂，没法实现。”有技术背景的用户也在吐槽：“我想快速验证不同参数的转码效果，但每次都要写脚本调API很麻烦，处理后，对比效果也不方便。技术文档中功能太多，没法快速验证哪个功能更匹配需求场景”

视频处理门槛高，对接入用户不友好是当前行业普遍存在的问题。目前腾讯云音视频媒体处理产品对外开放的能力已达30多种，包括转码、各种截图、雪碧图、时间点采样、转动图等等。这些能力中仅转码就有四五种，再加上视频识别、视频审核、智能封面、分类标签等各种AI相关能力，用户很可能还没使用就会发懵。如何从这么多能力中快速匹配需求，并且进行验证是当前行业的一大痛点。另外，很多用户有视频处理的需求，也有付费意愿，但不具备开发能力，如何让这类用户快速完成产品接入也是亟需我们思考的问题。

为了解决这些问题，媒体处理产品团队对MPS进行了一次大升级，引入AOV框架降低用户使用门槛。这次MPS 2.0升级的核心就是万物皆可编排（这里的物是指各种视频处理原子任务）。

首先，我们保留了原有的模板概念。用户在控制台可以创建各种任务模板，用来描述单个子任务的相关参数。之后，用户可以对模板进行编排，组成任务组，即通过编排描述任务组的执行序列。任务处理的逻辑被简化，对于单个视频，逻辑变为输入加编排ID，对于视频批处理，逻辑变成了触发源加编排ID。对用户开发来说，其只需关心输入在哪里，剩下的事情在控制台就可全部完成。MPS此次升级为2.0的目标就是让接入用户能少写一行代码就少写一行，最好是一行都不用写，直接0代码接入MPS。

上图右侧是编排的示例。从输入到输出，内部包含各种原子任务，例如审核、转码、采样截图、雪碧图等等。这样的序列是由原子任务构成的编排序列，即一个任务的执行流。通过编排，用户接入的流程被大幅简化。在控制台创建模板，完成后继续创建编排并开启，用户上传视频便能自动触发任务执行逻辑，从而将处理后的文件输出到指定的目录，也就完成了0代码的MPS接入。没有技术背景的用户也可以通过这一流程快速地接入MPS能力。对于部分需要感知任务处理进度的用户，可能还需要理解任务处理完成后的任务回调，但也仅需额外理解一条协议即可。这一流程很大程度上降低了用户的接入门槛。

支撑零门槛、零代码接入MPS的底层逻辑是编排。底层编排的实现依托于AOV视频处理框架，利用AOV网描述任务组。我们将图中每个任务定义成一个activity，从左到右、从上到下依次编号。从图中可以看到，示例的输入编号为0，审核任务编号为1，音视频转码任务编号为2……以此类推，从左到右、从上到下依次编号。经过编号，对于左侧任务的编排描述，就转化成了右图中的JSON串。网中的每一个节点都被定义成了一个原子任务。每个原子任务可以定义四个属性，分别是任务名称（区分不同任务，包括像转码、截图等）、入度（即有多少前驱节点指向该任务，例如Input节点没有前驱任务所以入度为0，而Output节点的前置节点有三个，审核、截图以及转动图，所以Output的in-degree就是3）、任务参数（不同原子任务对应的任务参数）、后驱任务索引（Input 「0」这个任务的后节点为审核 「1」和音视频转码「2」，所以后驱任务索引是「1，2」）。通过编号和定义，整个编排的任务描述便转化成了一个AOV网。

任务调度的逻辑通过AOV网的遍历来实现。首先程序会寻找AOV网内数据结构中入度为0的节点，在找到“输入”这个入度为0的点后，进一步对输入文件进行元信息探测，检测文件是否存在且正常、是否有音频轨、是否有视频轨、是否能够支撑后面的子任务处理逻辑。执行完入度为0的输入节点后，其后驱节点入度减1，再循环查找AVO网中入度为0的节点执行，直到所有节点执行完毕。

AOV框架采用AOV网的描述逻辑简化了执行流，从而最大程度减少了用户的代码开发工作量。所有操作全部在控制台完成，用户在控制台配置好编排后，后端直接按任务流执行逻辑序列执行。对用户来说，基本不需要开发工作量就能完成零代码接入。即使不懂技术，用户也能通过任务配置，保证视频按预期进行处理，并存储至指定目录。用户按照此流程操作即可接入，门槛非常低。

这部分主要介绍有关AI算力池调度的逻辑，这是针对转码子任务的处理逻辑。

我们在研发过程中发现AI算法的效果越来越显著，但集成落地却变得愈发困难。现在集成的各种AI算法，包括超分、画质增强、插帧、绿幕抠图、色彩增强等，效果相比传统算法确实要好很多，但也存在很大的集成问题。AI算法的算力消耗很大，通常需要跑GPU，且引擎的语言框架不统一。各种AI算法更多偏python开发，转码模块则更多偏C、C++语言开发，两者集成时语言体系不统一，性能、效率都很低。这也导致转码集成AI算法很困难，上线周期很长，需要长时间的联调测试。

在点播转码场景中，集成超分引擎最常见的办法是FFmpeg滤镜方案，即通过FFmpeg原生插件使用方式实现。这对部分实时性要求较低，且视频处理较复杂的场景非常实用。点播场景的各种filter可以自由叠加组合拼接，测试也很方便。但这种方式也会带来两个很明显的问题。第一是转码通常跑CPU，而超分引擎这种大算力引擎则需要跑GPU，如果通过filter集成，就会导致原本只需CPU机器的转码任务需要跑GPU机器。这会导致两种资源利用不均衡。原先一台单机可能可以跑三到四路转码，但集成超分之后可能只能跑一到两路，出现GPU跑满CPU资源空置，或者CPU跑满GPU资源不够等情况。CPU与GPU资源无法实现完美的平衡，资源碎片化严重，即使上容器也无法很好的解决。第二个问题是引擎与业务逻辑耦合非常重，迭代升级很不方便。当我们需要对超分算法进行迭代更新时，转码模块必须重新链接该filter，非常不方便。

在直播场景中，Server引擎集群是最常见的集成方案。该方案通过帧队列，用HTTP请求单帧超分集群来进行处理，将引擎与转码模块解耦，互不干扰，只是通过HTTP协议串起来。独立集群的资源利用率很高，转码继续跑CPU，集群跑GPU，解决了资源利用不平衡的问题。但HTTP协议也带来了新的问题。首先是通信带宽高，延时大，这对于直播场景来说是很难容忍的。其次是引擎无法热升级。对超分引擎进行热升级会出现原有帧由旧算法处理，新进帧则采用新算法处理的情况，导致算法效果不连续，所以无法做到热升级。

总结一下，上文介绍了点播直播场景最常见的两种算力资源集成调度方案——FFmpeg滤镜方案和Server引擎集群方案。但它们分别存在资源碎片化严重，耦合过重以及通信带宽高，延迟大，引擎无法热升级等问题。除此之外，它们还有两个共性问题，一是同一算法点播直播场景需维护两套，维护麻烦。二是方案可扩展性非常差，如需扩充其他算法，像插帧、画质增强、色彩增强，上线周期非常长，既要和点播转码模块联调，又要和直播转码模块联调。每次上新算法都需要做多方联调。

那怎么解决这些问题呢？MPS中引入的AI算力池调度方案就能够很好地解决刚才提到的六个问题。

简单的说就是通过通用filter+ 算力池代理的方式完成 。代理根据转码模板中指定的算力引擎，请求调度中心分配对应的引擎实例，剩下的引擎交互逻辑全部由代理完成，转码只需写帧、读帧即可。这样转码实例、算力池集群、算力池调度中心相互之间都是解耦的。

这套框架，能够很好地解决刚才的六个问题。

• 因为转码实例与算力池集群相互独立，CPU业务逻辑和GPU引擎逻辑能够很好的分离，互不干扰，那么资源利用率就可以很高。
• 引擎与业务逻辑解耦后，迭代升级很方便。通过AI-agent将转码与引擎拆分，新架构对算法进行升级时无需像原来一样，让filter和转码重编，只需在算力池集群中更新引擎算法，便可实现算法独立升级。
• 相比原先HTTP服务短连接的方式，新架构通过TCP长连接能够降低延时。
• 支持热升级。假设当前超分服务正在处理一路直播流，该框架在升级后，针对已在处理中的直播流，可以让它停留在就旧有的超分服务上继续处理，而新分配的直播流则能够调度到新算法上，避免了算法效果不连续的问题。
• 对于直播点播转码模块，这套框架能够做到统一的filter。接口统一后，不同引擎只是参数不同，通过转码模板下发需要哪种算法，之后传递到对应的AI-agent，最后请求相应实例即可。对直播点播转码模块来说，这套框架集成非常统一，后续有算法更新也不用迭代更新转码模块，只需配置直接申请对应实例即可。
• 可扩展性非常强。假设在现有算法基础上，我们想要新增抠图能力，那只需将服务模块引擎部署后注册上报，调度中心感知到抠图服务的存在，在转码模块配置转码模板时配置抠图的字符串模板，传递后直接去算力池调度中心分配实例。转码模块是完全透明的，不需要做任何变更，效果能够直接生效。

MPS算力池调度方案能够很好地解决常见方案中存在的诸多问题。但仍有一个遗留问题——延时与带宽的平衡。这个方案虽然通过TCP长连接能够减少部分延时，但它的传输带宽依然很大。原始方案我们从AI-agent发送一帧YUV（1080P视频YUV420P单帧大概在3兆左右）2K超分后返回约12Mbps左右，即发送YUV到超分服务，它的IO大概在15Mbps数据传输。这就导致带宽占用很高，且延时很大。在优化过程中，我们结合超分算法的特性，发现它对于UV通道不敏感。所以在优化方案中，AI-agent只发送Y通道给超分服务，剩下的UV通道在本地通过scale操作放大至2K，再与处理后的Y通道数据打包在一起进行返回。仅发送Y通道，单帧大小只有2Mbps，2K超分后约8Mbps。这样发送的数据量就从原来的15Mbps降低至10Mbps，带宽占用降低近33%，延迟也会减少很多。

方案优化后，发送的数据量还在10Mbps左右，依然很大。为了进一步压缩数据量，我们引入了不同的压缩算法进行测试，包括Zstd、zlib、lz4，发现对Y通道数据进行压缩后，能够使单帧数据减少到0.69Mbps~0.95Mbps左右，超分后也仅有2.77Mbps~3.81Mbps。这样整个数据传输量就降到了3.5Mbps左右。从10Mbps到3.5Mbps，带宽占用进一步降低65.5%。引入压缩和解压增加的耗时，对延时增加并不明显，但能够成倍地降低内网的传输带宽，累计可降低77%左右，达到延时和带宽的平衡。

最后这部分再介绍一下MPS的接入。前文提到的这些特性，包括AOV调度、AI算力池调度方案均已打包入MPS2.0中，目前MPS2.0也已经上线。

图中的四个链接分别是国内站接入地址、国际站接入地址、转码体验馆及视频AI体验馆。转码体验馆中可以体验极速高清转码、普通转码、画质重生、超分、色彩增强等各种能力。视频AI体验馆可以体验识别审核等视频AI相关的功能。欢迎大家扫描下方的二维码进入体验。

关于新知

随着行业数字化转型加速，线上线下一体化、数字技术与真实世界融合的全真互联时代正加速到来。腾讯云音视频技术导师将在新知栏目中分享在全真互联时代下新的行业趋势、新的技术方向以及新的应用场景与大家共同探索视界，创见未来！

腾讯云音视频在音视频领域已有超过21年的技术积累，持续支持国内90%的音视频客户实现云上创新，独家具备 RT-ONE™ 全球网络，在此基础上，构建了业界最完整的 PaaS 产品家族，并通过腾讯云视立方 RT-Cube™ 提供All in One 的终端SDK，助力客户一键获取众多腾讯云音视频能力。腾讯云音视频为全真互联时代，提供坚实的数字化助力。