4k/8k超高清时代，如何利用媒体处理技术加速数字化升级原创

嗯，大家好，我是腾讯云音视频导师吴浩，今天呢，由我向大家介绍一下，呃，广电级媒体数字化转型中的一些直播基础及应用。首先呢，先通过这个赛事活动线上化的一些背景，介绍一下如何提高赛事活动的稳定性，然后呢，再介绍一下播放的用户协议，呃，以及所遇到的一些问题，最后再简介一下呃，一些场景化的创新应用。从2020年以来，疫情改变了人们的生活和工作方式，越来越多的线下活动被搬到了线上，与此同时呢，人们对于娱乐体育赛事的关注度也是逐年的增长，线上制作和直播成为了呃，大家的一个核心需求。通常呢，一个完整的赛事流程，赛事现场可能是遍布全球的，那么他就需要把原始采集好的音视频信号通过远程传输的方式推送到这个制作中心，然后经二次制作后，经由那个云端服务进行媒体处理，呃，封装以及分发，最终呢才能触达到观众端的播放器上。

因此，整个电路的稳定性和质量成为了关键。那么接下来呢？从两个方面来介绍一下这个赛事直播的稳定性，呃，一个是前面提到的这个现场传输的一个网络问题。其次呢，还有一个就是这个云端媒体源站如何提升这个稳定性。呃，我们经常会遇到一些现场的网络问题，比如说网络切换，那么它容易发生在一些公共场所或者运动场下，呃，比如说4G5g WiFi，其中有一个链路出现了抖动，呃，发生切换的一个问题，那么还有一呢，就是现场可能呃。单一网络出现这个带宽不足的情况。还有就是在前面提到的这个远程传输的阶段，可能在这个国外网传输，可能会因为传输误码，或者呃高峰期网络拥塞，导致传输过程中有丢包出现等等。

那么媒体行业里面，呃，我们常用的流媒体传输协议其实有很多啊，大家比较熟悉的像RTMP。呃，因为它比较成熟，然后生态也做的比较良好，呃，目前还是主流的一个流媒体的传输协议，但是它呢，存在一些局限，比如说。它依赖于TCP，那么它的抗性比较差，而且RTMP支持的编码格式呢也比较有限，这些原因呢，都限制了它的进一步的扩展。呃，RP。呃，也是广电媒体行业里面一个用的比较久的一个协议。MTS的封装呢？它其实支持的编码格式比较丰富，而且RTP借助于udp的传输，延迟相对更低。但是因为没有较完整的一个控制，抗性比较差，往往呢需要采取发送的方式，比如说我们在P里面通过授，或者通过SMPT20227，也就是多路用于聚合的方式进行这个发送。

嗯，而ST呢，是近些年一个呃逐渐在推广使用的一个流媒体传输协议，呃，因为其具备这个低延迟，高抗动性，不断的成为了主流的这个媒体协议。而且它自身所带的多乐复用，多路镜等等一些呃，比较好的特性呢，也使其目前成为了大型赛事的一个首选的一个成熟协议。呃，不足的地方呢也有，主要是在于其用塞控制比较弱，因此呢，它往往适用于一些在呃这个传输带宽比较充足，它是网络可能存在抖动的这样的情形。那么quick呢，其实严格来讲，其实是属于互联网呃应用场景的一个传输协议，在广电媒体行业里面用的不多，因为它的开源以及外部的生态做的比较好，呃目前也是作为了三的一个标准。呢，也是近些年逐渐兴起的一个基于RTP和RTCP的一个流媒体协议。

因为其具备低延时、高抗主动性。呃，也是做的比较好，但是呢，呃，因为成熟的原因，目前相对于前面的一些其他的协议呢，使用量比较小。广电媒体行业，其实除了这些公网传输的协议，其实还有一还有一些是属于那种呃，局域网传输的流媒体协议。比如。呃，SD1等么，可以一些音视频信号，比如说这个ST2110所传输的叉S，那么它只采用了这个针对预测，因此它的这个压缩率比较小。呃，那么这些特点呢，其实呃更多是在这个局域网内传输，呃，因为他们的传输带宽成本比较高，也限制了他们在公网传输这个领域里面的一个使用情况。

那么针对于这个直播流媒体的一些特性，我们需要做哪些优化呢？首先是这个链接机制上面。比如说支持这个链接快链接其。通过精确的RT的测量，可以调整这个冲单间隔。呃，并且呢，丰富重传机制，以及呢知适应去调整这个乱序容忍度，我们知道乱序是可能会引引起充传的，那么。当网络波动的时候，那么可能这个乱序度，呃，可能会有变化。所以我们需要有一些机制能够自适应的去适应，去调整这个耐性容忍度，从而呢减少不必要的重传。其次呢，就是我们需要更好的去识别是丢包还是误码传输导致丢包。我们通常的做法呢，是通过基于RTT一个延迟梯度的一个带宽估计去判断是否真实的真正的出现了，从而来进一步角色是否调整码率。

此外呢，还有一些个是，就是在一些电池优先的场景。我们需要可以设置允许允许丢包，因为我们知道。链路中的延迟其实是由这个链路中的各个模块的呃，Buffer引起的。那么我们需要在尽可能不影响观看体验的同时呢？呃，可以可选择的丢包去维持一个稳定的一个延迟，那么这是一些在一些呃，特别呃，新闻媒体制作领域所遇到的一些。呃，共性的问题。腾讯视频语呢也提供了一个远程传输的平台，提供了低延迟，高的性的能力，以及前面所提到的这些很多协议之间的一些互相的转换。

呃，除了云端的方案。也提供SDK的方式。主要是增强这个弱网下推流的一个质量问题，同时具备高抗丢包和电池的特性。在推流这一段应用了媒体传输加速的一些协议之后呢，卡顿和延迟可以得到很大的改善。除了一些基础的优化还呃，这里再介绍一下流媒体传输中一个常用的质量提升方法，就是多路传输。比如说在一些场景，现场可能有多种网络接入类型。比如说4G5g或者WiFi。那么通过多路径发送或者聚合的方式，可以很好的去避免单一网络波动带来的一个影响。并且呢，在一些呃，需要高码率传输的一些场景，这种方法可以极大的扩展所需要的这个带宽上限。比如说在切换时，当单一网络出现。

断网或者是波动的时候，可以通过其他的通数据通道快速的将这个数据补上，能够达到一个平滑切换的一个效果。或者呢，通过多通道聚合发送的模式，可以过扩展整个的开关上线。而另一种场景。比如说针对边缘地区或者户外这种场景，那么云端节点往往不能做到本地覆盖。这种呢，我们常规的做法是在推流传输前进行一个参数，然后选择一个最优，呃，最优的一个链路接入点。但是这样会有一个问题，因为我们知道通常很多活动，那么它的。呃，时间会比较长，在这个过程中，网络是不断变化的。所以呢，我们需要有一个多接入点的一个动态路由策略，也就是在传输过程中，我们需要根据不同链路的一个质量情况，去动态的去调整这个发送的比例，去自适应角色这个路由。

嗯，收到了。媒体传输上面。呃在还有一方面就是这个媒体源站，我们也需要提高稳定性，那么一方面呢，呃通常会采用比如说勇于多路镜河流的方式去针对呃真级别。但是这里面会有一个问题，就是。哦，这这个标准呢，它是基于发送端，是同一个编码器推出来的。因此呢，我们还需要去处理不同编码区的一个融合问题。我们通常的做法是基于时间和G力度做一个平滑的切换，来处理在不同编码源之间切换的一个平滑问题。还有呢，就是在断流期间，我们也可以上传，呃，插入一段静态的图片，甚至是一个提前上传好的一段广告，比如说这这种图片。

来去优化观众端的一个播放体验。而在媒体分发阶段。呃，通常我们需要结合链路的一个可量化的一个质量指标去动态的调整电路。啊，并且呢，可以根据历史的。统计信息去调整静态的一个覆盖策略。而且呢，呃，特别的一点就是在重要的一些活动中，往往需要采取这个多回跟分发的模式，因为我们的切换它是会有一个过程的，就是你感知到这个质量有变化之后，然后再去切换，那么这实际上会有一个时间损耗。那么通常采取这个多。会员和分发的模式呢，可以减少这个切换的时间。接下来呢，再简单介绍一下这个流媒体常用的一些播放协议。

啊，用户。播放端的协议其实有很多，但是总体的来说的话是分为三类，最常见的像2000BFLV这种连续流式的。他们呢，可以做到较低的延迟，但是他们有一些问题，比如说呃，编码格式支持的比较少，扩展性比较差。而且呢？这两个协议在多码率，还有甚至说多音轨这种呃场景下是支持不了的，或者是说需要一些私有化的改造。即便是比如说A线S和代性能很好的去解决了这个可扩展性的问题。但是延迟比较高，因为他们的根本原因是因为因为像这种切片式的HS的代写需要每一个切片编码封装完之后，然后才能通过CD分发出去，那么这就带来整个的播放延迟是这个切片力度的，而一个切片至少是一个G力度的，往往就在两秒、四秒或者甚至更高的一个水准。

因此呢，在这个背景下，D切片流媒体应运而生。像CLAS，也就是DS。通过分块编码和嵌传输，可以把延迟控制在两秒的级别。目前呢，比如像iOS等也支持。那么对于赛事直播这种场景，观众的网络条件是多种多样的。而且有些用户网络也经常波动。所以呢，我们需要能够支持多马力自适应，而且在多语言环境下，甚至会有一些多多音轨，多语言的需求。但是多玛利常常会有一个问题，就是。不同马力之间的切片如果边缘不一致，会造成快进或者回退，有些播放器甚至会卡住，那么需要有一些机制可以使不同切片进行对齐。这里可以用到一个一次性欺骗的方法，就是在激流端在数据里进行标记，然后呢可以使得不同码率。

呃，在编码和封装阶段。他们的GP以及切片的边缘协调一致。这样的话就是在这个马力切换的时候啊，不会出现这个画面的。快进或者回退的现象。那么前面也提到如何做到这个低延迟？呃，传统和代写，究其原因，是因为一个分辨长度在编码和封装好后才能分发。那么这样的话就是带来了极大的延迟，低延迟的大值，原理呢，就是把这个力度降到了一个更小的级别，也就是。我在。一呃，一个切片，还没有编码和封刀。呃，完之前呢，我可以先把已经编码封装好的分块，尽早的通过嵌改的方式分发出去。那么这样的话就是整个的延迟由一个切片的力度就降到了一个的级别。

其实还有一种。目前。呃，逐渐。得到广泛应用的更低延迟的就是基于这个外其实的一个快直播方案。那么除了优化可以优化一些传输机制以外。他还结合了一些流媒体的特性，比如有选择的，根据优先级。进行分级重传或者。丢帧，从而呢，能够在即使弱网下也能达到低延迟的目的。最后再简单介绍一些，呃，我们在赛事直播场景上一些比较有意思的应用，比如说在直播的基础上可以实现。统一直播和时宜的请求协议和格式。这样呢，可以极大的简化这个播放器的逻辑，而且呢，比较有意思的一点是，我们可以通过AI视频内容的识别的技术呢，把赛事中的一些精彩画面通过打点的方式呃，呈现给。

用户。那么具体的这个技术流程呢，就是在这个媒体处理时，可以对视频帧进行一个理解，利用深度学习和视频的分类啊，识别到的事件信息，通过回调的方式。推送给。客户。其次呢，在这个直播过程中，生成的切片会直接的归档存储起来。并生成时间点对应的11索引文件。那么这样呢，有个好处就是可以使得直播和适宜的切片保持一致。简化播放器的。请求格式，那么在用户界面上呢的效果就是可以实现拖拽即时宜的一个效果。最后呢，再简单说一下。流媒体里面一个，呃，常用的一个场景就是这个广告插入。根据这个插入的位置呢，一般广告它分为三类，比如视频前广告，视频中广告以及视频后广告，当然视频后广告主要是针对于点播的场景。

呃，在技术实现上呢，比如说通过垫片式的方式，可以直接把这个广告通过编码嵌入到这个视频流里面。但是这样的话，它是千人一面，就是说大家看到的广告都是一样的内容，或者呢，利用一个广电级的一个标准三五。那么这个标签呢？呃，通常在ifest文件描述信息里面，就是比如说MD。呃，生成相应的标签，那么播放器，呃，支持这个标准的播放器识别这个标签后，可以执行所规定的一些一系列的行为操作，比如说开始播放一段指定的广告或者停止等等。还有一种呢，就是个性化的方式，也就是说千人千面的一个效果，那么大致的做法呢，是通过在直播流里面打上一些标记。那么播放器识别这个标记之后会去请求。这个标记里面所。

带的这个广告投放方的平台接口。广告通话方呃的接口，拿到这个请求之后呢，会去根据不同的用户类型去下发不同的广告，那么最终可以实现一个千人千面的广告效果。呃，这里就是我今天所给大家介绍的一些。呃，广电媒体中的一些直播流媒体的应用，呃，感谢大家。大家好，呃，我叫刘兆瑞，那目前呢，在腾讯呃视频云负责编码器优化，那以及呢，直播点播系统的一个呃，转码系统的一个构建。那今天跟大家主要想分享一个内容呢，就是说呃，随着目前分辨率的呃，观看设备分辨率的一个更大，然后观看设备越来越高清。那其实我们已经面临了一个4K和8K超清时代的一个来临，那面对于这种4K8K的一个超高分辨率，那超高码率的一个视频，那我们有哪些，呃一些新的一些亟待处理的问题，有哪些新的痛点问题需要处理，那以及呢，我们如何利用媒体处理的一个技术来处理这些。

呃，超高码率，超高分辨率的新的问题来辅助大家来进行一个加速的媒体数字化升级。那今天分享的内容呢，主要分为几部分，那第一部分呢，就是呃4K8K一些超高清视频，那它有一些什么样的特点，那这些呃，新的一些视频的出现，有哪些新的一些问题需要我们去面临，需要我们去解决。那后面的几部分的内容呢，主要是根据于我们前面所说的面临的一些问题，然后呢，我们来进行一些分门别类的一些呃，媒体分门别类的用一些为我们媒体处理的技术来分别的来解决这些问题。

那其实主要呢看呢，可以分为几方面吧，第一方面呢，就是对于一些编码器的优化，来使得我们编码器来更适应这种一些，呃，超超大分辨率啊，超大码率的一个视频，那第二部分呢，是在编码器之外呢，那我们结合一些其他的技术，能使这些超高分辨率的处理能适用于直播的一个场景，那我们的整体架构需要进行哪些的优化，那以及我们前后处理的一些技术啊，在最后一部分呢，也就是说。呃，其实虽然我们的一个官方设备达到了一个很高的一个呃，播放的分辨率，那但是呢，我们在制作端。在采集端，很多时候呢，还没有一个这么高的分辨率的一个视频制作出来，那除此之外呢，那还有很多一些老的片源和电影，它其实并没有1080P的一个分辨率，但是呢，呃，人们对于这些相对较老的一个片源，还是有一些高清播放的一个诉求存在。

对，第一部分是一个背景。呃，背景相关的一个介绍。那我从我们从我们这，呃，从我们的这个背景来看吧，啊，那目前呢，其实从播放端来看，我们播放的一个设备，其实它的所支持的分辨率是越来越高的，那其实现在的一个新的，不论是电视还是手机往都已经支持了4K的一个分辨率播放，当然了8K肯定也是未来的一个趋势，也是大家会支持的一个来的一个分辨率，虽然现在可能对8K分辨率播放的一个知设备还太多。那4K8K这种超高清视频的一个特点呢，就是它的分辨率非常大，它的码率非常高，对，那其实对于呃，这么高的一个分辨率和码率，对下游的很多系统都带来了一些新的挑战，那比如说对于直播的一个系统来说，那直播中的一个转码系统，那在转码的过程中呢。

我们知道转码机制往往呃，它的一个处理速度以及性能消耗，是跟视频源的一个视频输出的一个分辨率以及码率相关，那如果说要转码实时的输出一个这么高的一个分辨率。那其实呢，呃，对于整个的一个转码系统，有非常多的一个呃挑战，那如何去满足一个实时的一个高分辨率一个转码系统，那我们无论是在编码器上，还是在我们的系统架构上，都有很多新的要优化的一个点。那第二个，呃，问题呢，就是说。现在呢，有很多硬件厂商，那通过他通过一些硬件的方式来支持那4K8K分辨率的一个实时编码，来解决那个超高分辨率编码的一个痛点。那通过硬件的方式来解决的一个问题呢，就是说呃，硬件呃所编码出来的一个视频，虽然它的速度编码速度是足够快的，但是呢，它的压缩率相对来说比较差，也就是说呢，如果要达到一个4K8K的清晰清晰度，那硬件编码过程中呢，需要一个更多的一个码率。

那比如说几十兆甚至上百兆的马力来传输呢，4K8K的一个视频，那其实。对于整个的一个传输链路来说，有一些更多的一个挑战存在。那所以呢，我们希望还是能够通过技术手段，那通过一些软编的方式来实现一个速度足够快，那同时呢，啊，我们的一个压缩率能达到一个普通软边的一个效果，压缩率足够好的一个解决方案。那从另一方面来看呢，其实ARVR慢慢在一个进行一个兴起。那随着AR啊，以及VR能力的一个兴起，那这些技术呢，往往都是进行一个视频来进行一个传输，那如果要满足一个足够的真实卡，其实也是需要一个4K8K的一个超高清的一个视频，所以呢，从这里来看呢，那这种超高清的视频啊，也真的是未来的一个越来越重要的一个趋势，和很多相关技术的发展都息息相关。

呃，那第二个部分呢，主要是来跟大家分享一下呢，那我们在编码方面所做的一些优化，以及呢，我们目前呃，自研的编码器所达到的一个编码的性能。那首先呢，那从我们的编码器来说呢，那呃，其实我们整个内部的无论是264还是265，还是ay，包括最新的266，那我们所有的编码都是在我们腾讯内部自研的，那自研的编码器的好处呢，就是可以符合我们的不同的业务场景，进行一些针对性的专门的优化，那比如说。

啊，在北京冬奥会的时候，那我们的一个直播系统呢，就承载了我们4K8K的一个实时的编码压缩啊，甚至达到了120FPS，那在这个背景下，为了达到这个效果，那我们在编码器的内核也做了很多一个，呃，针对性的一个优化。呃，那首先来看一下，那我们目前优化后大概编码器能够达到一个什么样的指标，这样的指标呢？呃，来配合我们一个超清视频的一个编码。首先呢，从我们自然的一个265编码器来看呢，那我们的265的编码器，那和比如说开源的叉265相比，那可以在呃远远提升速度情况下，同时呢，提供一个更好的一个压缩率啊，比如最左边这一个图，呃，它的纵力是一个速度的表，那可以看到那我们呃所建的一个265的编码器，它在速度的指标上，那最快的档位可以远远的快于那叉265的一个最快的档位，提供一个呃。

高分辨率下的一个快速编码。呃，那除此之外呢，那目前呢，我们的C编码器呢，也支持了4K8K啊，甚至比的一个HDR的一个编码，以及杜比的一些处理。呃，那我们自研一个AV的编码器的话呢，其实也支持了一个4K8K的一个实时编码，那对于AV的一个编码器来说呢，它通用的一个处理速度，复杂度相对比265来说是更高的，那在这里的情况下呢，针对于超高清的一个情况，那我们也支持一些呃快速的算法，那比如说我们和开源的一个SV相比呢，可以有55%的一个工程性能加速。

同时呢，还能带来16.8%的一个压缩增益。那除此之外呢，其实我们对解码器也进行了一定的自研，那我们的David，我们和比较开源的比较好的A的解码器相比呢，可以加速10%以上的一个效果，大概和呃回是因为C265的一个软解性能速度相当。对，那前面主要跟大家大概分享一下，那我们呃，自研编码器能够达到什么样的一个压缩率以及速度的标准，那这里呢，主要跟大家说一下，那我们具体优化的点，那所去关注的点是哪几个点，我们怎么样去做的，那对于这个超高清的一个快速的一个编码，那我们核心的呃，有几个点呢？第一个呢。就是说我们怎么样能更好的提高他的病情度，那我们知道在编码的过程中呢，有啊征集的病情啊，有红块级的病情对吧，那我们做。

我们进行优化的时候呢，那我们首先对于这种呃，需要实时快速的一个大合辨率的编码的时候，那升级的并行，那我们把它的帧结构来进行一些调优，那我们使中间的一些针能够更好的进行一个快速的针尖并行，那在红花型的并行，那我们通常是使用T来进行一个呃宫格的一个编码，那我们在T内的那不进行一些。呃，额外的参考来进行一个红二级的票内的一个行级并行的一个加速，那第三个部分，那我们知道其实呃，在编码之前往往会有一个look high的预分析的一个过程。那只有一个视频进行一个look ahead分析结束之后才能够进行后续的一个编码操作，那所以呢，在有的时候呢，Look ahead会成为一个整个链路进行的一个卡点，那我们这里呢，对于预分期以及后处理的一个复杂度的瓶颈啊进行一些优化。

对，那主要进行这些方式的优化，那使我们的整个编码的一个处理速度达到更高我们的并行度。更高啊，提高CPU的利用率。呃，那第二部分呢，主要是我们4K8K的一个呃，极速高清的能力，或者是说我们在一个前面说的是我们编码器的一个情况嘛，那这里主要是说我们整个的一个呃系统的一个架构，尤其是对于直播的来说，那如果在直播的场景，其实仅仅是编码器的优化，还是难以达到一个呃8K的一个编码实施，那在这样的背景下，我们怎么样在达到8K的一个编码实施的一个情况下，尽可能的利用我们软软编的一个特性来提高我们的一个编码压缩率。

那目前呢，比如说常用的一个方案啊，包括我们最近帮一些呃，私有化的一些广电客户所做，那很多情况它的源呢，可能是8K的AS3的一个圆。然后呢，进入我们的一个硬件编码器输出的时候呢，输出包括8K的265啊，4K的265啊，1080P的264啊。甚至720P64等等多不同的码来进行一个不同的分发。对，那这样虽然可以达到目标啊，但是啊其实还有很多痛点的存在，第一个呢，就是说我们8K的呃编码器价格还是普遍昂贵呢，尤其呢是我们呃8KA的编码器那目前更少。能够支持的情况的话，呃，更少，而且它的价格更加的贵。啊，第二部分呢，就是我们硬件的编码器呢，和优化后的软件的编码器相比呢，压缩率还是比较差的，我前面也提到了，对，当然这是由硬件编码器的一些特性决定，因为它要进行更大规模的一个并行，那必然有很多一些。

算法它是不太适用于进行定行的，那如果软编的话就没有这个问题，然第三部分呢，就是说我们的硬件编码器的话，往往它都是定制好的一个结构以及架构和芯片，对吧，但是呢，我们实际的业务场景是非常多的，比如说你有可能是A3的，那过几天可能又有其他形式的源，那过几天可能还有新的新的格式出现。那这对于硬件编码器来说，它整体的一个架构以及硬件都需要一个变更，那如果能够通过软编实现同样的效果，那就没有这个问题啊，第四部分呢，其实也是跟第三部分类似，就是一个扩展能力的支持啊，比如说我们有更多的一些对于下游，下游对于上游的一个编码后的一个，比如说时间戳，或者是C帧，或者是那HDR的一些能力的一些支持，那硬件编码器有可能刚开始，刚开始设置的时候，你是支持了这些功能，那其实随着业务的迭代，那各种各样的需求更越来越多的，那你很难去在硬件器内部来去定制这些需求来重新来实现这些功能。

嗯。对，那为了解决这样的一个问题呢，那其实我们对整体的自己的一个直播系统架构也进行了一定的一个优化，那来看一下我们，呃平时的一个整个直播系统的一个架构，那首先从推流上来到我们W的一个网关。那网关的流后面进行我们一个流处理，也就是我们对于呃整个直播流一个转码的过程，然后转码之后呢，将转码输出的流，那推流到那个CDN，然后最后呢，然后下行进行分发来观看。那么原来是大概一个这样的一个链，那对于我们的超高清4K8K的一个视频来说呢，虽然我们在呃编码器内部其实已经进行了非常多的一个速度啊，包括并行度，包括算法的一个优化。

但是呢，对于比如说8K这种真的是非常大方面的一个视频，那只凭一台机器，一个转码节点，其实还是难以来完成一个实时的一个软变的一个过程，因此呢，我们在这种情况下，对于这种超大分辨率，我们对于我们整个直播系统的一个架构进行了一些呃，新的优化。呃，简单来说呢，那我们在原来的一个流处理，那直播的一个转码处理的一个节点，并不来进行一个真正的一个转码，只是进行一个类似转封装的工作，将他拉过来的一个呢，会切成一个TS的一个小片。那然后呢，将这些TS小便呢，以文件的形式呢，发给我们的一个离线转码处理集群，那离线转码处理集群呢，可以并行处理多个不同的一个TS小便，来实现多台机器的一个并行编码。

这样的话呢，其实呃，就把原来把所有的一个编码任务集结在一台机器转来，转成一个利用一个离线的处理集群来进行一个分布式的一个多台机器的一个转码。那它的好处呢，首先呢，第一个是纯软件控制，所以它的一个可控性是非常高的，包括我们进行一个扩展以及业务升级，那需要更多的一些能力，那整个流程都是非常方便的。啊，第二部分呢，其实也可以更好的一个节省成本，因为我们离线转码处理集群呢，本来就是存在的，那在云上其实有非常多的一个离线转码的任务，那这样呢，可以进行一个更多的集群，以及我们整个处理能力的一个混混用，那把我们的资源利用率提升的更好。那另外呢，毕竟我们整个的呃，离线处理其实它是基于软编的，那软编还是说保留我们原来的一个好处，能够提供相比硬件来说一个更好的一个压缩率，能够在相同的画质上，那更好的一个降低我们所处理的率。

更好的呃，对更好的降低我们所处理的一个码率，呃，同时呢，那我们整个的机器资源呢，以及业务开发模式呢，都可以实现一个嗯，复用的一个效果。当然它也有一定的缺点呢，就是延迟相对来说会高于一般的一个转码，因为呢，你要呃进行一个并行的一个转码，首先呢，你在开始。流处理进行一个转换装的过程中呢，其实要进行一定的等待，那比如说你要等待第一个I帧和第二个I帧出现了，那这两个中间呢，才能作为一个独立的T来进行一个呃分发，所以呢，延迟呢相对来说会相对高一点，但也是在可接受的范围内，尤其是如果是下行使用呃hrs来进行一个直播的话，那其实延迟基本上不会有一个很明显的变化。

对，那在这样的一个处理过程呢，那我们在离线的一个处理集群，将转完的一个文件，那存到对应的位置后呢，那反过来呢，会通知我们的一个流处理，告诉他那文件已经处理完了，那那么流处理这个节点会把对应的文件拉回来，然后呢，再进行下一步的一个转封装，封装成下行播放需要的一个文件格式来供下行来进行一个播放。那前面说的是，其实我们已经把一个呃只实时直播的一个呃4K8K超高清的一个视频，那通过呃我们一个离线处理集群并行编码的一个方式，将它转换为多个并行的一个独立的离线转码的节点任务，那这里呢，再跟大家呃分享一下，那我们对于一个独立的节点，那一个单独的一个点播的节点，点播转码的一个节点，那这个节点的内部的处理可以进行哪些不同的一个优化。

啊，首先我们极速高清的一个能力的话，其实呃是可以用在我们点播的一个转码节点内部的，那我们对一个点播的转码节点的内部来进行转码的过程中呢，可以保证在相同的一个主观评分下，大概可以节省50%以上的一个带宽，这是和其余的一个软件编码器相比，那如果和我们硬件编码器相比，那可以有更高的一个压缩率啊，可能有70%以上的一个压缩率，也就是说那我通过我们前面的那一套方案对吧，直播的一个4K8K超后镜，那他在同样的画质所需要的一个编码的码率，可能只是硬件的一个码率的，呃，30%左右。或者说我们在同样的码率下，那我们来评价我们的一个主观分数的一个提升，大概可以有20%以上。那为了达到一个这样的效果呢，那其实在我们的一个呃，软件的一个呃，离线转码节点编码内部呢，其实也做了很多不同的一个优化，有很多不同的步骤。

首先呢，在前处理阶段，那我们有丰富的一个呃，前处理的一个能力，那包括呢，我们对于视频源画质的一个识别，识别之后呢，可以对视频原发进行一定的降噪啊，以及增强操作，呃，当然这对于一些那我们超高清的视频情况可能不是特别多，那但是对于一些视频语言发质不是特别好的视频，需要增强的时候，那这个效果就会比较明显。那第二部分呢，就是我们的一个编码内核，那我们在编码内核里是完全基于自主研发的一套，包括264 265a以及266的一个编码内核。最后一部分呢，是在后处理方面，在后处理方面呢，其实我们也提供了一些在播放的SDK，来提升播放的一个播放效果。

对，那刚才粗略的说了一下，那其实从整个完整的一个链路来看的话呢，啊，它的整个过程大概是视频源啊上来了以后呢，那我们对视频原先进行一个解码，解码之后呢，我们会对视频源进行一些场景的分类，那对于不同的分类呢，我们会有不同的一个编码的策略，接下来呢，会有对应的一个啊场景的一个检测，包括我们的噪声检测，包括我们的毛刺检测，来分析出视频语言中的一个噪声啊，毛刺啊，毛边的一个情况，来为后续的一个编码优化做准备。那分析到这些结果之后呢，那在编码之前啊，分析之后，那我们会对于检测出来的视频源的一些问题来进行一定的一个修复，包括一些噪能力，包括啊一些去盲刺去毛边的能力，那对于一些啊画质重生以及画质修复的啊，一些比较复杂的场景，那我们也可以支持一些超分呐，插帧呐等等一些老喷修复的一个能力。

那对于视频源的画质来进行一个修复之后呢，在编码之前呢，那我们进行一个编码前的一个改制编码分析，那改制编码分析呢，主要其实就相当于分析出啊视频画面的R区域，比如说视频画面中的一个人脸区域，那比如说视频画面中的一个纹理复杂，纹理简单的区域，那对于一些呃纹理复杂的区域，比如说它会有一些遮盖效应存在，那对于这种情况，我们可以适当的减少一些码率。那对于一些呃纹理简单的区域，往往对于往往对于人类来说是一个呃比较敏感的啊，如果出现块效应会有很大影响的一个区域，那对这种情况下，那我们会进行一些啊感知编码的调控分析，也就GND的能力，然后呢啊这些信息呢，带入到编码器中，那在编码输器的内核进行编码的时候，那可以根据这些ROI以及GND的一个结果来更好的来调配不同的block，不同的呃像素点之间的一个码率控制，码力分配能力。

对，那最后一部分呢，啊，也就是说前面也说了，那我们其实目前播放设备可能达到了4K，但是并不是所有的偏远都达到了一个4K的分辨率来进行一个播放，所以呢。从我们的一个片源的角度来说，尤其是老的片源还有很多，呃，1080P，甚至720P的片源，那我们希望通过技术的能力呢，能够把这些老的来进行一个升级，达到一个更高的一个真的大概4K分辨率的一个清晰度，这样的话呢，对于人员感官来说呢，可以真的享受到一个J4K的一个播放效果。这里有一个啊，我们大概的一个例子，那我们通常来进行一个呃，超高清的一个4K分辨率的一个生成的过程中呢，可能分为几个步骤，那首先呢，对于原进行一个分析啊。

包括说呃，噪声的存在的情况，以及去压缩压缩时所算的情况，然后呢，根据这样的结果进行一个综合的数据退化。啊，包括去噪声啊，文理增强噪声意识等等，当然了，这里有一个特点可能呃。单独说一下吧，也是我们实践中的一个结果，那比如说对于人脸呢，对于字体，这其实都是人脸在观看视频中非常关注的一个区域，如果说你的人脸区域做的非常好，其实啊周围的区域做的不是那么好，其实也能给人一个非常超高清的一个整体的感受和感觉。那对于呃细节进行一个增强啊，噪声啊，纹理啊，进行一个呃意识之后呢，那我们下一步呢，可以进行一个色彩的一个增强，那包括4K8K的一个视频，其实。

已经广泛的使用HDR的一个能力，那在这样的情况下呢，我们远很多都是不具有HDR的一个播效果。那最终可以达到一个高清分啊，高清分辨率同时呢啊，色彩鲜艳的一个大概真4K的一个结果啊，提升，或者说弥补我们偏源不足的一个情况，那这里有一个大概的例子，那我们通过一个这样的处理后，尤其看人脸的区域，其实对于整体的一个话，是有非常高的一个提升的。对，然后前面其实也跟大概跟大家也是呃分享了一下，那我们在做一个这实在的一个视频，来进行一个从原分辨率到4K分辨率的一个超分色彩的一个过程中，呃，其实我们内部看只是通过一个模型，其实很难达到一个非常理想的一个效果，对，那比如说我们可能对于背景，对于整体的画面使用一个通用的一个超分模型，但是对于人脸，对于字体，其实是采用另外的一个超频模型来进行一个单独的一个处理，然后呢，将两个模型相结合，才可以达到一个比较好的效果，尤其是人脸方位，人脸的一个方位向上。

那其实人眼的五官啊等等，其实都是有一些呃，更相对于通用来说有一些更更加细致的一些单独的一些特征，那我们其实在这样的背景下，可以达到一个呃更好的一个增强效果。那比如说我们举一个例子，对于外部的客户来说，那我们呃实际的一个超高模型，可能只能达到一个通用的1080P到四呃到2K的一个，呃大概面对上涨的一个超分效果，但是对于人脸的区域呢，由于它的各个特征都是呃比较固定的，那我们可以进行专门的一个增强，嗯达到在人脸部分区域大约能够达到呃1080P到4K这样一个大分辨率的一个增强效果，然后相两者相结合呢，其实对于大部分我们主观的一个评测来看啊，都认为这个视频跟4K分辨率没有什么太大的差别，因为我们在人脸最关注的就是人脸字体方面，达到一个更高分辨率的一个提升的一个主观效果。

对，那今天跟大家分享的内容就这些啊，谢谢大家。大家晚上好，我是来自于腾讯云视频云音视频平台的研发工程师孙翔学。啊，我一直在做视频处理相关的一个后台研发工作，今天跟大家分享的主题呢，是视频处理AOV框架和AI算调度。

那今天分享的目录呢，主要包括四个部分啊，首先是一个行业现状的一个介绍，第二点是AOV框架的一个描述，第三点是算力词调度啊，最后一点是关于MP接入的一个说明。啊，首先呢，想聊一下现在行业的一个现状。啊，从各大云厂商来看呢，目前从用户反馈看。视频处理的门槛其实一直都很高，对于接入用户来说都不是在很太友友好，我们经常听到一些用户就没有技术背景的用户吐槽说，然后我只是想把视频里面的语音提成文本啊提取出来，然后存档，也愿意付费，但是呢，没有开发能力，API文档也看不懂。啊，有些有技术背景的用户呢，也吐槽，我想快速验证一下不同参数的转码效果，每次都要写脚本去调API，很麻烦啊，处理完呢对比效果也不是很方便。我们也听到有些用户C吐槽啊，他是有技术背景的啊，他说看技术文档的功能特别多，但是没法快速去验证哪个功能能更匹配用户的一个我自己的一个需求场景。

从用户一些出来看呢，就普遍从啊云场上来看，视频处理的门槛都很高，对于接入用户不是非常友好。那我在视频云呃音视频平台中视处理里面，我们引入了一个AOV框架来处理这些问题，从而使降低用户的一个使用门槛。刚才提到的都是用户层面的一个吐槽，那么我们正在内部层面去看这个问题呢，其实确实有这个问题确实也存在，包括我们视频处理啊，这个产品对外开发能力呢，有30多个能力。包括转码，转码就有四五种对吧，截图各种截图啊，雪碧时间点采样动图等，然后包括还有各种AI的相关能力，包括视频识别啊，视频审核，封面分类标签等能力非常多，但是呢，用户可能会发蒙，如何能够快速去匹配需求进行进行验证。

确实我们也发现又有很多用户有视频处理的需求呢，也有付费意愿，但是确实没有开发能力，然后他们如何才能快速完成一款产品的介入呢？就是为了解决这些问题呢，我们对于MP做了一个2.0的一个升级。那么核心想法呢，就是万物皆可编排啊，这里的物呢，是指各种原子视频处理人物。那么首先呢，用户会在保留原有模板的概念，用户在控制台可以创建啊各种任务的一个模板，去描述单个子任务的一个一个相关参数。定要通过模板去编排啊，组成一个任务组。也就是说，通过编排去描述任务组的一个执行的训练。那么对于任务处理的逻辑的被简化成了啊，对于单个视频呢，变成了一个输入加编排ID的一个逻辑。那对于视频批处理呢，就变成了一触发表N加变ID。这样对用户开发来说，我就只需要关心啊，我的输入在哪里。

剩，剩下事情全部在控台可以完成。那2.0的一个目标呢，就是相当于让能让接入用户少写一行代码就少写一行，最好是一行都不写，能够完成零代码接入MPS。那么可以看到右边这个图呢，是一个编排的一个示例。啊，从输入到输出啊，里面有各种原子任务，包括审核转码啊，采啊，采样截图，学位图等。这样的一个序列就是原子任务构成的一个编排序列，就是一个任务的一个执行流。那么最后用户接入的一个流程被简化成从在控制台去创建模板，创建完模板之后呢，继续创建一个编排，然后进行编排的一个开启。通过用户对于视频的一个上传，能够自动触发任务的一个执行逻辑，从而将文件处理后的文件输入到用户指定的目录。从而也就完成了连代码的一个MP接入。这样对于一个没有技术背景的用户来说，他也可以快速的。也有MPS能力。当然，对于有些有有技术背景的用户来说，我需要去感知任务处理的一个实时通知，那么他可能就需要去理解任务消费完、处理完之后的一个任务回调。

啊，这样子呢，其实最多也只需要理解一条啊协议就可以了。这样的很大程度上呢，能够降低用户的一个接入门槛。然而自身这个啊，零门槛代码接入的，零代码接入MPS的一个逻辑的底层是有一个叫啊编排的一个逻辑，那底层的编排的一个实现呢，其实就是基于AV框架。我们采用AOV网去描述这样一个任务，一个任务组。我们把图中每个任务呢定义成一个activity，那么所以呢是从左到右，从上到下一编号，那你可以看到我们这个设零啊，输入我们编的是INDEX0，然后审核是一，因编转码是二啊，从左从左到右同上一是编号。那么这样对于任务这样的一个编排的一个一个描述呢，就转化成右边的一个阶层串。

每一个这个网里面的每一个节点呢，我们就把它定义成一个原子任务，每个原子任务呢，我们给它定义了四个属性，包括任务名称，对吧，我们会区分不同原子任务，包括像转码截图等。那么第二个属性是叫入。也就是有多少个前驱节点指向该任务，例如说input节点它是没有前驱任务的，也就没有前置任务，那么它入入就是零，那对output节点呢，它前然前。所以output的intrate就是就是三包input in就是零。那么第三，第三个属性是它的一个任务参数，就是不同原子任务对应的任务参数。然后最后一个是后期任务的一个索引。也就是说对，也就是说该任务假设我们INPUT0这个任务它的后节点有审核跟音视频转码也是一跟二，所以input的它的后续索引节点是一跟二。

这样子我们就把整个一个编排的一个任务描述转化成了一个AV网，那么任务调度的这些逻辑呢，就是说通过就是转化成了一个AV网的一。第一个入驻为零的节点是输入这个点，对吧，它入驻很零，那么在输入环节我们做一个逻辑，就是做一个输入文件的一个原信息探测，我们去检测这个文件是否存在以及是否。正常啊，是否有音频轨，是否有视频轨，是否能够支撑后面的一些子任务的一个处理逻辑，所以我们把刚才做了一个最短落最最短落地的一个测算，就是保证这个在输入环境去做探测。保证后面任务的一个资金流。然后执行完啊，入度为零的输入节点之后呢，我们会把后续节点的入度全部减少减减减一。

这样子对于审核来说，视频转码来说，这个任来说，它的版本是一，等到input这个节点执行完之后，那么它的就零，那么这样子就变成两个入度为零的节点都可以开始执行，比如说审核跟应用转码是可以同时并行执行的。那么进而开始往后迭代。到音视频转码模板完成以后，那么截图两个截图任务就可以同时执行了。然后等所有的任务执行完之后，然后所将输出的节点的它的入度最开始为三等所有的前置任务处理完之后，它入的也变零，然后最后变离输出啊对吧，最后最后最后一个的节点。然后保证整个任务链路的执行完毕。所以说AOV框架它是采用A网的描述的逻辑去简化的这个这样一个执行流，从而能够说最大程度的减少用户的一个代码开发工作量，整个东西都全部在后台完成，让用户在控台配置的编排之后，整个任务流执行逻辑全部由啊就在页面完成之后，后端直接按这个序列去执行。

所以说对于用户来说就很基本上不用做做什么开发工作量的，能够完成零代码接入，对吧，即使我不懂技术，我也能够把这个任务都配好了之后，我保证我的视频能够按我的预期做一个处理，然后所有的输出呢，我能够存到用户指定的一个目录。这样对于用户来说，他的门槛就非常低了。OK，那么第三部分我们想介绍的一部分就是关于AI算力池调度的一个逻辑。这是针对于转码子任务的一个处理逻辑。那么我们在研发过程中，我们经常发现就是AI算法的效果呢，是越来越显著，效果越来越好啊，但是呢，集成落地啊，是越来越困难。我们现在集成各种AI算法，包括像超分画的增强，然后插针啊，内幕抠图，色彩增强等一些AI算法，那效果确实确实比传统算法要好很多。那么其实带来的问题也存在，就是说它的算力消耗很大，一般都要要跑GPU，而引擎的语言框架不统一，因为各种算法它更更多的是偏啊，更多是他是开发的，对吧，然后转码模块呢，更多是偏CC加语言开发的那两个集成的时候呢。

语言体系不一，不统一。然后性性性能。效率都很低。所以导致说转码其实很困难，然上线的周期也也很长，包括我们新上一个算法对吧，联调测试周期很长。那么我怎么去解决这个问题呢？所以我想举个例子，就是点播场景啊，点播转码的一个场景，去集成超分的和引擎。那么我们自然而然会想到，很容易想到一个办法呢，就是通过啊F运营的方案去实现。也就是说我通过M原的插件使用方式呢，能够对于实时要求比较低，然后数据处理比较复杂场景呢，是非非常非常实用的。然后各种点播场景啊，各种filter，我们的叠加组合拼接，然后测试也很方便，对吧，但是其实带来的问题也很也很也很明显。

如果说通过非集成呢，导致说原来转码可能我只需要CPU机器，现在变成不要GPU机器了，它就会导致说两种资源它利用不均衡。反正一台单机可能跑三四转码对吧，这样提成超分之后可能只能跑一路一路两路对吧，假如说CPU他们跑不上去，那么GPU呢，或者说我们GPU跑满之后啊，CPU出来了，或者CPU跑满之后GPU不够。自然碎片化很严重。容器也没很好解决。然后第二点是引擎跟业务逻辑呢，耦合非常重。迭代升级很不方便，假如我现在超宽算法就是进行迭代更新，那么你要去去更新到转码里面去，那你现在转码模块要重新去练这个filter，对吧。耦合非常重啊，对他身体也非常不方便。

那这两个问题没办法解决呢，也可以解决，我们想一想，在直播场景我们集中超分的时候，我们把它转成了走服务啊，生活引擎的方案。这样子很明显是，呃，引擎跟转码模块呢，也解耦了，各自啊各自不干扰是吧，通过SP协议串起来。然后独立集群呢，自然利用率也很高，对吧。转码还是继续跑CPU，那集群呢，发布集群呢，跑CPU各自是各自集群，然后呢，自然利用率我也能跑的很高。那么带来新的问题是什么？抖S协议有网络IO对吧，通信带宽高，延迟大。在直播场景来说啊，其实是很难容忍的，可能我现在啊走IO之后导致延迟之后它的IPS跟不上。第二点是它的引擎也无法做到热升级，对吧，然后我现在要做超分引擎的一个迭代。

这是一个独立集群嘛，你如果你升级的话，前面真是用旧旧算法处理的，然后到新增的时候。到新进的的时候，可能就应了新的现场，导致说算法效果不不连续，而且就是根本原因还是说引擎的无法做到做升级。那我们总结一下。刚才提到了那个常见算力。自然去。集成调度的一个方案呢，就是无非就是滤镜对吧，然后集群，这是两种很常见的方案。那带来的问题呢，我们刚才提到就是有啊，碎片化，耦合过重，带宽通性带宽高，延迟大，然后就是引进无法升级，除此之外呢，还有两个共性问题，你像同一个算法呢，点播直播场景，它可能需要维护两套。维护起来也很也很麻烦。第二点是说啊，方案可扩展性也非常差，如果我需要扩充其他其他算法，算法包括像插针啊，画增强自条，商业周期非常长，我就要跟转码模块去联调，我要去跟子目转码模块去联调，对吧。

那商业周期很长，然后扩展性也很差，我每次上个新算法都要去多多放链条。那么我们在MPS里面引入的SINGLE1种AI算力池调度方案。能够很好的解决刚才提到六个问题。首先我们把啊统一的一个叫AI去集成这些。算算法到啊转码模块里面去。这个菲呢是一个统一的filter，它能够跟本机同机代一个代理叫an检去做通信。也就是说我们在转码模板里面去。指定不同的啊，算算引擎。通过在初始化，在set初始化的时候呢，通过unf的通信，在的通信传递这个算法的一些模型的一个参参数，叫我来说需要哪种模型。然后呢？A呢，会通过。

啊，请求算力调度中心去请求分配对应的算力资源的IP。然后与对应的实例IP建立一个连接。共。那么转码模块的集成逻辑就变成了我不断的往filter，通过filter里面去写真，那么帧呢，会通通过输入帧队列传递到a an，会通过DV长链接把这个帧传递给对应的超分，然后超分实例对吧？然后处理完之后呢，再写回共享的队列，数帧队列，然后非把这帧传传给转码，对上上的模块再做一个编码。从而完成整个链路的一个一个，一个转码，一个逻辑。那么转码实力啊，跟商业实集群，包括调度中心都是相互之间都是结耦的。我说这套算法，这套框架呢，能够很好解决刚才提到六个问题。首先第一点，因为转码实力跟双列式集群是独立的，对吧，那么导致说我们CPU业务逻辑跟GPU引擎逻辑能够能够很好的分离，那么自然利用率也很高。

对，互不干扰嘛，对吧。那么第二点呢，引擎跟业务逻辑解耦之后呢，那么迭代升级很方便，假设我现在超声服跑了，在直接在处理运动直播流，那么我们在升级的时候。对吧，我们算法设计之后这个实例。我升级完之后，保证原来已在处理中的直播流在停留在就旧有的超分服务上面去去做做一个处理，那么在新处理这新的一个直物流的一个超分，我们能够去调度到新的算法上去，对于转码测来说它是透明的，对吧。比如说在请求的时候，我们算计是调中心发现有新的引擎算法去上报了、注册了，那么我们就会分配新的实例。这样等于说我既不影响原有的直播流处理，我也能够快速的迭代操作服务。而不需要，而不需要像原来一样，我要去跟着菲去啊，把编的转码重编转码对吧，跟转码重编。

这个是很麻烦的。那么第三点是说啊，我们通过啊基术长链接能够走原有的那个IP服务走走短连接的方式，我们能够降低一定的延时。那么第四点，我们刚才提到说支持热升级。也就是说我们通过A的拆出来之后，我们能够跟转码独立的一个做升级，我们不需要跟转码做做做关联，对吧。那么第五点是说我们对于直播点播转码块来说，能够做到一个统一的一个。接口统一了对吧。不同的引擎无非就是参数的不同，通过转码模板息要哪种算法要哪种模板。然后传递到对应的按键的请求，对应的实例即可。对于转播转播，对于直播点播转模块来说，我的集成就非常统一，统一了就后面上新算法，我又不用迭代，我又我又不用变更对吧，模板里面配一下那字符上传下来，直接去申请对应的实例即可。那么第六点就是说。

它的可扩展性非常强的。也是我们后面去上新算法。假设我现在有超分，有插针画增强遮挡增强对吧，各种，然后我现在上抠图。那么上课的之后，我们无非就是把模块服务，模块引擎部署之后呢。多多上报，把调度中心感知这个共同服务的存在。那么在转码模块去配置转码模板的时候。啊，配置一个啊，抠图的一个字符串模板。传定下来之后，超分模传递过来之后，直接去算中心分配，分配这个实例，那么转码模块呢，是完全透明的。不需要做任何变更。从而使效果能够直接生效。所以说。MBS算一次调度方案，能够很好的解决刚才我们提到的一个常见的及时方案的一个存在六个问题。那么这里其实还有一个遗留问题，就是关于延时带宽的一个。我们看可以看到刚才这个方案虽然说通过汽车长连接能够减少它的一定延时，但其实它的传输带宽还是很大。

我们可以看一下。原始最开始方案我们从啊A的。发送一帧YV1080P的啊，420PYV要420P，单帧大概在三兆左右。2K超分之后呢，返回大概是15兆左右，也是方案一，原是开始方案15道数据，比如说。如果是发送YUV到仓服务，那么它的一个IO大概有15兆数据。这15兆数据呢，带来问题就是带宽占用很高，而且延时很大。那么我们结结合超算法的一个特性。发现他对于UV通道是不敏感的。所以我们考虑优化呢，我们就是A只发送外。套餐服务。剩下的UV呢去做在本地做scale操作到2K。然后再跟操作完之后的外通道数据。打包在一起。然后再反馈给。

Beta。也是这样，会导致说我发送的数据量啊，发送外的话，单帧的话只有两帧两兆。梳理完之后呢，23分大概是八兆。这样导致我们的传输量从原来的15兆降到了十兆。那么带宽占用呢，降低33%的一个会减少很多。啊，那两优化方案优化优化之后，它的数据量呢，还有大概在啊十兆左右，其实也很大，那我们在想。能不能进一步的去把数据量压缩？所以我们引入了不同的压缩算法去测试。包括像ZCD。对吧，再内，然后呃，L4。我发现就是通过对外通道数据进行压缩之后，能够使得单帧数据达变成0.69兆到0.995兆左右。要拆分完之后呢。也只有2.77~3.81。那么整个的长输数量一下就降到了3.5兆左右，对吧，3.5兆。

从十兆到3.5兆，那么带宽占用呢，又降低了65.5%，延时呢？也会不是很明显，增加不是很明显，因为这里引入了压缩跟解压，会导致它的一个耗时会有少量增加，然后呢，能够成倍的降低它的内网的一个传输带宽，累计降低呢，有77%左右。所以我们这样做之后呢，能够使得它的延时达到一个平衡。能够保证出生稳定。OK，那第四部分呢，我们想去介绍的就是关于MPS的一个接入。我们刚刚提到这些特性啊，包括像a AV调度对吧？啊，AI3电池调度方案呢，都在MPS2.0里面去打包进去了，202.0呢，我们也即将上线，大概在七月左右，我们目前已经在发发布相关观点模块了。那么这里呢，也附了有四个链接，一个是国内站接入地址，还有就是国际站接入地址。

还有对应的两个体验馆，一个是转码的体验馆，包括像啊转呃技术关系转码重转码对吧，画重生。增超分，色彩增强，各种体验都可以在里面体验，然后包括还有像视频AI相关的功能体验啊，包括识别审核对大家可以都可以试一下。OK，今天分享内容呢，这么多，谢谢大家。