00:00
大家晚上好,我是来自于腾讯云视频云音视频平台的研发工程师孙翔学。啊,我一直在做视频处理相关的一个后台研发工作,今天跟大家分享的主题呢,是视频处理AOV框架和AI算池调度。我今天分享的目录呢,主要包括四个部分啊,首先是一个行业现状的一个介绍,第二点是AOV框架的一个描述,第三点是算力词调度啊,最后一点是关于MP接入的一个说明。啊,首先呢,想聊一下现在行业的一个现状。啊,从各大云厂商来看呢,目前从用户反馈看,视频处理的门槛其实一直都很高,对于接入用户来说都不是很太友很友好,我们经常听到一些用户就没有技术背景的用户吐槽说,然后我只想把视频里面的语音提成文本啊提取出来,然后存档。也愿意付费,但是呢,没有开发能力,API文档也看不懂。
01:00
啊,有些有技术背景的用户呢,也吐槽,我想快速验证一下不同参数的转码效果,每次都要写脚本去调API,很麻烦啊,处理完呢,对于效果也不是很方便。我们也听到有些用户C吐槽啊,他是有技术背景的啊,他说看技术文档的功能特别多,但是呢,没法快速去验证哪个功能能更匹配用户的一个我自己的一个需求场景。从用户一些出来看呢,就普遍从啊云场上来看,视频处理的门槛都很高,对于接入用户不是非常友好。那我在视频呃音视频平台中视处理里面,我们引入了一个AOV框架来处理这些问题,从而使降低用户的一个使用门槛。刚才提到的都是用户层面的一个吐槽,那么我们正在内部层面去看这个问题呢,其实确实有这个问题确实也存在,包括我们视频处理啊,这个产品对外开发能力呢,有30多个能力。包括转码,转码就有四五种对吧,截图各种截图啊,雪碧时间点采样动图等,然后包括还有各种AI的相关能力,包括视频识别啊,视频审核,封面分类标签等能力非常多,但是呢,用户可能会发蒙,如何能够快速去匹配需求进行进行验证。
02:15
确实我们也发现又有很多用户有视频处理的需求呢,也有付费意愿,但是确实没有开发能力,然后他们如何才能快速完成一款产品的接入呢?就是为了解决这些问题呢,我们对于MP做了一个2.0的一个升级。那么核心想法呢,就是万物皆可编排啊,这里的物呢,是指各种原子视频处理人物。那么首先呢,用户会在保留原有模板的一个概念,用户在控制台可以创建啊各种任务的一个模板,去描述单个子任务的一个一个相关参数。定要通过模板去编排啊,组成一个任务组。也就是通过编排去描述任务组的一个执行的训练。
03:00
那么对于任务处理的逻辑的被简化成了啊,对于单个视频呢,变成了一个输入加编排ID的一个逻辑。啊,对于视频批处理呢,就变成了一触发表N加变ID。这样对用户开发来说,我就只需要关心啊,我的输入在哪里。剩,剩下事情全部在控台可以完成。那2.0的一个目标呢,就是相当于让能让接入用户少写一行代码就少写一行,最好是一行都不写,能够完成零代码接入MPS。那么可以看到右边这个图呢,是一个编排的一个示例。啊,从输入到输出啊,里面有各种原子任务,包括审核转码啊,采啊,采样截图,学位图等。这样的一个序列就是原子任务构成的一个编排序列,就是一个任务的一个执行流。那么最后用户接入的一个流程被简化成从在控制台去创建模板,创建完模板之后呢,继续创建一个编排,然后进行编排的一个开启。通过用户对于视频的一个上传,能够自动触发任务的一个执行逻辑,从而将文件处理后的文件输入到用户指定的目录。
04:03
从而也就完成了连代码的一个MPS接入。这样对于一个没有技术背景的用户来说,他也可以快速的。也有MPS能力。当然,对于有些有有技术背景的用户来说,我需要去感知任务处理的一个实时通知,那么他可能就需要去理解任务消费完、处理完之后的一个任务回调。啊,这样子呢,其实最多也只需要理解一条啊协议就可以了。这样的很大程度上呢,能够降低用户的一个接入门槛。然而支撑这个啊零门槛代码接入的,零代码接入MPS的一个逻辑的底层是有一个叫啊编排的一个逻辑,那底层的编排的一个实现呢,其实就是基于AO AV视频处理框架。我们采用了AOV网去描述这样一个任务,一个任务组。我们把图中每个任务呢定义成一个activity,那么所以呢是从左到右,从上到下一编号,那你可以看到我们这个设啊输入我们编的是ind,然后审核是一,编码是二啊左右。
05:12
那么这样对于任务这样的一个编排的一个一个描述呢,就转化成右边的一个阶层串。每一个这个网里面的每一个节点呢,我们就把它定义成一个原子任务,每个原子任务呢,我们给它定义了四个属性,包括任务名称,对吧,我们会区分不同原子任务,包括像转码截图等。那么第二个属是叫入度。也就是有多多少个前驱节点指向该任务,例如说input节点它是没有前置任务的,也就没有前置任务,那么它入入就是零,那对output节点呢?它的前置节点有三个项,审核是它的前节点,然后截图,然后转动,对吧?都是它前置点,那么它有三个前前节点,也就是说它录入就是三。所以output int就是就是三包,Input就是零。
06:00
那么第三,第三个属性是它的一个任务参数,就是不同原子任务对应的任务参数。然后最后一个是后期任务的一个索引。也就是说对,也就是说该任务假设我们INPUT0这个任务它的后节点有审核跟音视频转码也是一跟二,所以input的它后续索引节点是一跟二。这样子我们就把整个一个编排的一个任务描述转化成了一个AV网,那么任务调度的这些逻辑呢,就是从通过就是转化成了一个AV网的一个便利,首先我们寻找这个这个数据结构里面,这个网里面的一个入度为零的节点,假设我们现在找到。第一个入驻文件的节点是输入这个点,对吧,它入入很零,那么在输入环节我们做一个逻辑,就是做一个输入文件的一个原信息探测,我们去检测这个文件是否存在以及是否。正常啊,是否有音频轨,是否有视频轨,是否能够支撑后面的一些子任务的一个处理逻辑,所以我们把刚才做了一个最短落最最短落定的一个测算,就是保证这个在输入环境去做探测。
07:03
保证后面任务的一个执行流。然后执行完啊,入度为零的输入节点之后呢,我们会把后续节点的入度全部减少减减减一。这样子对于审核来说,以及音视频转码来说,那个任务来说,它的入度版本是一,等到input这个节点执行完之后,那么它的入度就简成零,那么这样子就变成两个入度为零的节点都可以开始执行,也就说审核跟运行转码是可以同时并行执行的。那么进而开始往后迭代。到音视频转码模板完成以后,那么截图两个截图任务就可以同时执行了。然后等所有的任务执行完之后,然后所将输出的节点的它的入度最开始为三等所有的前置任务处理完之后,它入的也变零,然后最后变离输出啊对吧,最后最后最后一个的节点。然后保证整个任务链路的执行完毕。所以说AOV框架它是采用A网的描述的逻辑去简化的这个这样一个执行流,从而能够说最大程度的减少用户的一个代码开发工作量,整个东西都全部在后台完成,让用户在控制台配置的编排后,整个任务流执行逻辑全部由啊就在页面完成之后,后端直接按这个序列去执行。
08:20
所以说对于用户来说就很基本上不用做做什么开发工作量了,能够完成零代码接入,对吧,即使我不懂技术,我也能够把这个任务都配好了之后,我保证我的视频能够按我的预期做一个处理,然后所有的输出呢,我能够存到用户指令的一个目录。这样对于用户来说,他的门槛就非常低了。OK,那么第三部分我们想介绍的一部分就是关于AI算力词调度的一个逻辑。这是对于转码子任务的一个处理逻辑。那么我们在研发过程中,我们经常发现就是AI算法的效果呢,是越来越显著,效果越来越好啊,但是呢,集成落地啊,是越来越困难。
09:03
我们现在集成各种AI算法,包括像超分画的增强,然后插针啊,内幕抠图,色彩增强等一些AI算法,它效果确实确实比传统算法要好很多。那么其实带来的问题也存在,就是说它的算力消耗很大,一般都要要跑GPU,而引擎的语言框架不统一,因为各种算法它更更多的是偏啊,更多是他是开发的,对吧,然后转码模块呢,更多是偏CC加语言开发的那两个集成的时候呢。语言体系不一不统一。然后性性能。效率都很低。所以导致说转码其实很困难,然上线的周期也也很长,包括我们新上一个算法对吧,联调测试周期很长。那么我们怎么去解决这个问题呢?所以我想举个例子,就是点播场景啊,点播转码的一个场景,去集成超分的和引擎。那么我们自然而然会想到,很容易想到一个办法呢,就是通过啊F的方案去实现。
10:02
也就是说我通过安原生的插件使用方式呢,能够对于实时要求比较低,然后数据处理比较复杂的场景呢,是非非常非常实用的。然后各种点播场景啊,各种我们的叠加组合拼接,然后测试也很方便对吧,但是其实带来的问题也很也很很明显。因为我们刚提到是CPU啊,转码一般跑CPU对吧,然后呢,引擎这种大的引擎一般都是跑GPU的。如果说通过非集成呢,导致说原来转码可能我只需要CP机器,现在变成不要GPU机器了,那就会导致说两种资源它利用不均衡。反那一台单机可能跑三四转码对吧,这样其实超分之后可能只能跑一路一路两路对吧,假如说CPU他们跑不上去,那么GPU呢,或者说我们GPU跑满之后啊,CPU空出来了,或者CPU跑满之后GPU不够。发生自然碎片化很严重。即使上容器也没办法很好的解决这种问题。然后第二点是引擎跟业务逻辑呢,耦合非常重。
11:02
迭代升级很不方便,假如我现在超宽算法就是进行迭代更新,那么你要去去更新到转码里面去呢,你说转码模块要重新去念这个filter,对吧。耦合非常重啊,对他身体也非常不方便。那这两个问题没办法解决呢,也可以解决,我们想一想,在直播场景我们集中超分的时候,我们把它转成了走服务啊,生物引擎的方案。也就是说我们通过针对面去走SP请求到单帧超分集群对吧进行处理。这样子很明显是啊,引擎跟转码模块呢,也解耦了,各自啊各自不干扰是吧,通过SSP协议串起来。然后独立集群呢,自然利用率也很高,对吧。转码还是继续跑CPU,那集群呢,发布集群呢,跑GPU,各自是各自集群,然后呢,自然利用率我也能跑到很高。那么带来新的问题是什么?走SP协议,有网络IO对吧,通信带宽高,延迟大。
12:00
在直播场景来说啊,其实是很难容忍的,可能我现在啊走IO之后导致延迟之后它的IPS跟不上。第二点是它引擎也无法做做升级对吧,然后我现在要做超分引擎的一个迭代。这是一个独立集群嘛,你如果你升级的话,前面真是用旧旧算法处理的,然后到新增的时候。到新进的的时候,可能就应了新的现场,导致说算法效果不不连续,而且就是根本原因还是说引擎的无法做到做升级。那我们总结一下。刚才提到了那个常见算力。自然去。集成调度的一个方案呢,就是无非就是滤镜对吧,然后集群,这是两种很常见的方案。那带来的问题呢,我们刚才提到就是有啊,碎片化,耦合过重,带宽共性带宽高,延迟大,然后就是引进无法升级,除此之外呢,还有两个共性问题,你像同一个算法呢,点播直播场景,它可能需要维护两套。维护起来也很麻烦。
13:01
第二点是说啊,方案可扩展性也非常差,如果我需要扩充其他其他算法,算法包括下插针啊,画条自上业周期非常长,我就要跟转码模块去联调,我要去跟子目转码模块去联调,对吧。那商业周期很长,然后扩展性也很差,我每次上个新算法都要去多多放链条。那么我们在MPS里面引入的single,一种AI算力调度方案。能够很好的解决刚才提到六个问题。首先我们把啊统一的一个叫AI去集成这些。算算法到啊转码模块里面去。这个菲塔呢,是一个统一的filter,它能够跟本机同机代一个代理叫an检去做通信。也就是说。我们在转码模板里面去。指定不同的啊,算算力引擎。
14:01
通过在初始化,在非初始化的时候呢,通过UN的通信,在的通信传递这个算法的一些模型的一个参参数,叫我来,我需要哪种模型。然后呢?A呢,会通过。啊,请求算力调度中心去请求分配对应的算力资源的IP。然后与对应的实例IP建立一个连接。然后与此同时还会分配两个共享内存队列,用来与标ta进行一个通信。那么转码模块的集成逻辑就变成了我不断的往filter,通过filter里面去写真,那么帧呢,会通通过输入帧对列传递到an an会通过DV长链接把这个帧传递给对应的超分,然后超分实例对吧?然后处理完之后呢,再写回共享的队列,数字帧队列,然后非导把这帧传传给转码,对上上的模块再做一个编码。从而完成整个链路的一个一个,一个转码,一个逻辑。
15:03
那么转码实力啊,跟商业实集群,包括调度中心都是相互之间都结合的。我说这套算法,这套框架呢,能够很好解决刚才提到六个问题。首先第一点,因为转码实力跟双列式集群是独立的,对吧,那么导致说我们CPU业务逻辑跟GPU引擎逻辑能够能够很好的分离,那么自然利用率也很高。就互不干扰嘛,对吧,那么第二点呢,引擎跟业务逻辑解耦之后呢,那么迭代升级很方便。假设我现在超纵服跑了,在直接在处理一个直播流,那么我们在升级的时候,对吧,我们算法升级之后这个实力。我升级完之后,保证原来已在处理中的直播流在停留在就旧有的超分服务上面去去做做一个处理,那么在新处理这新的一个直物流的一个超分,我们能够去调度到新的算法上去,对于转码测来说它是透明的,对吧。比如说在请求的时候,我们上计调中心,发现有新的引擎算法去上报了、注册了,那么我们就会分配新的实例。
16:03
这样等于说我既不影响原有的直播流处理,我也能够快速的迭代操作服务。而不要像原来一样,我要去把编转码重编转码吧,码编。这个是很麻烦的。那么第三点是说啊,我们通过啊基术链接能够走原有的那个服务走走短链接的方式,我们能够降一点延时。那么第四点是我们刚才提到说支持热升级。也就是说我们通过an的拆出来之后,我们能够跟转码独立的一个做升级,我们不需要跟转码做做关联,对吧。那么第五点是说我们对于直播点播转码块来说,能够做到一个统一的一个。接口统一了对吧,不同的引擎无非就是参数的不同,通过转码模板下发,要哪种算法要哪种模板。然后传到对应的按键的请求,对应的实例即可。对于转化转播,对于直播点播转模块来说,我的集成就非常统一,统一了就后面上新算法,我又不用迭代,我又我又不用变更对吧,模板你们配一下那支付上传下来。
17:10
直接去申请对应的实例即可。那么第六点就是说。它的可扩展性非常强的。也是我们后面去上新算法。假设我现在有超分,有插针画增强,自载增强对吧,各种,然后我现在上抠图。那么上课的之后,我们无非就是把模块服务,模块引擎部署之后呢。多上报,把调度中心感知这个共同服务的存在。那么在转码模块去配置转码模板的时候。啊,配置一个啊,抠图的一个字符串模板。传递下来之后超分模传递过来之后直接去算中心分配,分配这个实例,那么转码我看它是完全透明的。不需要做任何变更。从而使效果能够直接生效。所以说。MPS算式调度方案能够很好的解决刚才我们提到了一个常见的及时方案的一个存在六个问题。
18:05
那么这里其实还有一个遗留问题,就是关于延时跟带宽的一个。我们可以可以看到,刚才这个方案虽然说通过汽车长连接能够减少它的一定延时,但其实它的传输带宽还是很大。我们可以看一下。原始最开始方案,我们从啊AI的。发送一帧YV1080P的啊,420PYV要420P,单帧大概在三兆左右。2K超分之后呢,返回大概是15兆左右,也是方案一,原是开始方案15道数据,比如说。如果是发送YUV到服务,那么它的一个IO大概有15兆数据。这15兆数据呢,带来问题就是带宽占用很高,而且延时很大。那么我们结结合超算法的一个特性。发现他对于UV通道是不敏感的。所以我们考虑优化呢,我们就是A只发送外。
19:01
到餐服务。剩下的UV呢去做在本地做scale操作到2K。然后再跟操作完之后的外通道数据。打包在一起。然后再反馈给。Beta。也是这样,会导致说我发送的数据量啊,只发送外的话,单帧的话只有两帧两兆。处理完之后呢,23分之后大概是八兆。这样导致我们的传输量从原来的15兆降到了十兆。那带宽占用呢,降低百分之三十三一个会减少很多。啊,那两优化方案优化优化之后,它的数据量呢,还有大概在啊十兆左右,其实也很大,那我们在想。能不能进一步的去把数据量压缩?所以我们引入了不同的压缩算法去测试。包括像ZCD。对吧,再内,然后呃,L4。我发现就是通过对外通道数据进行压缩之后,能够使得单帧数达变成0.69兆到0.995兆左右。
20:08
要拆分完之后呢。也只有2.77~3.81。那么整个的长输数量一下就降到了3.5兆左右,对吧,3.5兆。从十兆到3.5兆,那么带宽占用呢,又降低了65.5%,延时呢?也会不是很明显,增加不是很明显,因为这里引入了压缩跟解压,会导致它的一个耗时会有少量增加,然后呢,能够成倍的降低它的内网的一个传输带宽,累计降低呢,有77%左右。所以我们做能够使的延时达到平衡。能够保证出生稳定。OK,那第四部分呢,我们想去介绍就是关于MPS的一个接入。我们刚刚提到这些特性啊,包括像a AV调度对吧?啊,AI3电池调度方案呢,都在MPS2.0里面去打包进去了,202.0呢,我们也即将上线,大概在七月左右,我们目前已经在发发布相关模块了。
21:11
那么这里呢,也附了有四个链接,一个是国内站接入地址,还有就是国际站接入地址。验。增超增种都可以在里还有频A相关功能体包大家可都可以一。OK,今天分享内容呢,这么多,谢谢大家。
我来说两句