基于 Serverless 的海量音视频处理实践原创

Hello，大家周二晚上好，欢迎来到云原生郑发生直播间，我是今天的主持人露露云原生郑发生与原生技术爱好者共同学习成长。今天是我们节目的第18期，我们邀请到了腾讯S产品架构师李永涛先生担任本期的讲师，我们本期讲师拥有多年云计算从业经验，熟悉电商、教育、社交等音视频解决方案，曾经参与多个从零到一的音视频项目的建设。今天呢给大家带来的分享主题是基于size的海量音视频处理实践。大家都知道在5G商用背景之下，用户对于视频内容质量有了进一步的要求，低延时，高清晰度，并且可以适配各种类型的这个设备，比如手机、平板电脑、浏览器等等，对于视频处理的定制化需求也日益的增强。本期分享主要就是分析如何针对海量音视频数据。

进行文件处理，下面我先介绍一下本期节目的一个分享流程，首先呢，我们讲师会有一个45分钟左右的主题演讲，在讲师分享结束之后，我们会预留出来15分钟左右的时间给大家进行互动答疑。在讲师分享的过程中，大家如果有问题可以扫描直播间右侧的二维码进入互动答疑的专区进行提问，或者直接点击我们发送到微信社群里面的互动答疑链接进行提问，在我们导师分享结束之后，会选取大家的部分问题为大家进行答疑。同时呢，我们也准备了精美的礼品给到这些提问的同学，欢迎大家多多参与。好的，接下来我们就有请我们的导师开始今天的精彩分享。哎，好的，首先。好的，那我们接下来开始今天的分享，各位线上的小伙伴大家晚上好，那今天我主要基于service的海量音视频处理实践给大家做一个简单的分享，关于分享的一些背景，刚才我们的主持人已经做过简单的介绍，这里就不再重复，那我们接下来主要看一下我们今天分享的几个议题，那第一个议题呢，就是在5G商背景下视频市场的一个背景介绍，为什么我们要去做音视频处理这些事情，以及说我们一个真实项目的项目回顾，在项目过程中我们遇到了一些什么样的问题。那第二个是基于海量视频处理方案的详细介绍，该方案中呢，会包含我们对项目问题的一些落地实践。

那第三个部分呢，就是我们对今天分享的一个整体的总结，好的，那接下来我们开始看第一部分的内容。呃，那首先音视频目前已经成为一个主流的互联网内容形式，随着抖音、快手这些短视频平台的崛起，包括说像爱奇艺，腾讯视频这样一些长视频平台的优化，那目前来说我国移动互联网用户八后占比达到了76.7%，那为互联网的主要人群，那可以看下面这个分布图，那为了虽然生活的丰富和对网络的熟悉呢，让此类人群的兴趣爱好比较非化，但是呢，同时它具有一个良好的娱乐内容消费习惯与参与度啊，这给予了市场内容服务商更广阔的一个前景，我们可以看到八五后移动互联网用户日常兴趣分布在视频类的占比去一个日益上升的阶段，那从。

短视频直播到综艺，那已经超过了类似于之前的游戏、社交等占比。那同时呢，在中国移动互联网的内容创作者，他们的兴趣分布呢，也从之前的图文形式向短视频以及说综视频这种形式去过渡，对，那这是基于艾瑞艾瑞咨频的一个调查报告，对便于我们去了解音视频在目前主流的互联网内容形式中的一个占比和分布。

那随着用户需求的一个，就是随着用户需求的一个日益的变化，那目前对于视频的一些要求也发生了变化，特别是在5G商务背景下，那对于质量的要求得到了进一步的提升，随着越来越多视频玩法的涌现，那像一个近视、高清晰度，而且可以适配多种设备类型的视频成为了用户的强需求，比如说我们可以用不同的设备去观看视频，像手机、平板，甚至于外包浏览器等，那视频内容的提供商，他也期望进一步的去达到一个降本增效的目的，来提升整体视频制作产业链的盈利能力。那具体我们可以从以下几个方向来看，首先第一个就是超高清的一个传和实时共享，那它给用户带来的其实是一个沉浸式，互动性强的高清观看企业。

那如何用更低的流量去负担带宽，给用户带来更好的企业，以及说丰富的这种付费场景，比如说不同清晰度的一个划分，包括会员等级的划分，那这种模式它所带来的商业成效是比较可观的。那第二个是说如何去和观众的场景互联互通，比如说像自由的视角，自由的缩放，观众与场景互联互通。第三个类似于一些实拍实传，云端制作渲染这一块呢，在整体的短视频制作层面会有一个更高的需求，比如说我实时拍了一段视频，然后实时在线制作，实时上传，这目是目前大多数短视频平台的玩法。第四个的是强交互的新内容形式，就是呃，大概在一八年前后，就是直播起来之后，带来了一波强交互的内容形式，但随着直播诞生了这么多年以来。

它的玩法些固定，那短视频兴起之后，可能说想点赞评论，然后多方传输，成了一个新的交互形式，那这些用户诉求，它所带来的一个对于平台的诉求，比如说我怎么样商业上去体现这些能力，那针对于不同清晰度及终端的付费用户进行一个接信的划分，来制定自己的一个商业模式，那第二个。呃，第三个呢，是推进视频内容的包括制作、编码、传输惨的一体化，来降低内容供方的一个制作成本，提高效率，那这是在视频成为互联网内容的一个主要企业形式，并且用户需求发生变化的情况下，我们所能看到转码这一项技术能力为大家带来的一个商业成效。

那这是目前基于音视频市场的一个整体分析，接下来我们来看一下，就是我们在一个实际的项目中，我们会有哪些问题，呃，首先这是一组数字，大家可能不太理解，我这里简单介绍一下，一个是40，这个40呢是指说我的视频格式会非常的多样化，特别是在UGC的场景下，用户的拍摄设备呢，不是那么固定，或者说用户本地上传文件。可选的随机性比较强，编码格式、封装格式都会有多样化。第二个呢是320~4K，这这一组数字其实指的是清晰度，那随着说用户不同网络带宽的需求，我们需要有一个大的视频码率空间，比如说从320，就320KBPS到4K这样的一个高清的视频都可以去支持。第三个数字是十，其实指的是一个视频处理速度，像短视频，比如说15秒的短视频，或者一分钟的短视频，大多数客户希望能够在十十秒钟之内完成一个视频的处理，那这样在高并发的情况下，对底层算力的一个资源消耗挑战其实是非常大的。

那第四个呢是1000万，这个1000万呢，指的是平台的日活，在高并发的情况下，如何快速的去对不同规格的文件进行多规格的处理，对于几层算力的调度能力和算法的编码能力都是一个非常大的挑战，那接下来看我们在这个项目中我们遇到了哪些挑战。呃，首先第一个就是说音视频内容生产和消费面临的四大挑战之一，第一个就是带宽的成本，因为当视频数量或者用户数量快速增长的时候，你的视频码率每增加1KBPS，那所带来的带宽成本其实增加的是非常多的，所以迫切的需要去进一步的降低码率，降低企业的一个运营成本。那如何去降低码率呢？其实目前市面上用的就是转码的技术，下面会做详细的介绍。那第二个的话是服务器的成本高，这里的服务器成本是指自建转码服务器的开销和运维的成本比较高，你需要去考虑可用性、扩展性、监控、升级、容灾等等一系列情况，那带来一个比较高昂的服务器维护成本。

那第三个就是内容质量不齐，这个内容量不齐主要是在内容生产的流程其实不是特别规范。因为目前各大平台在内容的处理层面呢，有一定的流程规范，比如说用户上传上来一个视频之后，我经过什么样的一些处理，达到平台的统一标准，但我们没有办法去限制用户上传的一些逻辑，那并不是完全规范，环节是剥离的，就是上传，就是拍摄上传，并没有完全的耦合在一起，那成绩感比较差，非常依赖于各个环节的人员经验，比如说我拍一个视频，我的构图，我的视角，其实和个人的拍摄能力有很大的关系，这也是说高质量的视频内容生产如何去降低它的门槛。

第四个呢，就是定制化不足，呃，每一个视频或者说每一个大类，它都会有自己的一些特殊化的需求，那短码算法的灵活度，精制化能力不足的情况下，无法满足用户或者企业对于个性化的需求，因为目前市面上的转码技术大多数是采采取这种标准API的形式去起一些转码参数，都是直接封装在API内部，用户无感知，呃，只能去设置一些基本的参数，比如说码率、帧率、分辨率等等，那定制化的使用需求呢，没有得到很好的解决啊，这是目前音视频内容生产和消费的过程中面临的几大挑战。

那基于这几大挑战呢？我们选择了S的音视频处理方案，那接下来我们就看一下S的音视频处理方案是怎么样解决我们在项目中遇到的这些挑战。呃，首先第一点就是我们刚才起到的服务器成本高昂，因为它是一个托管，托管资源管理，降低了运维的成本，那首先是从运维这一块去讲，那大家可以看到这里有一个呃，比较鲜明的对比，如果说之前采取虚机的这种形式是类似于汽车租赁，去使用算力来进行转码的话，那塞类的这种形态就类似于网约车，那它们两者最大的区别就是说你多了一辆汽车之后，可能你需要对它的安全性，呃。

对它安全性，以及说对它的稳定性，包括说你要自己去操作这辆车，那类比这里可能你需要去做网络操作系统，包括软件安装，系统运维等等，而S呢，它是一个开箱急用的运行环境，类似于网约车，你上车之后呢，你只管你的目的距离在哪里，然后剩下的都可以由平台来帮你完成，也就是说类比转码，你只需要去看你的转码算法或者转码参数的调整，那几层的扩能力，包括几层的计算资源，平台的运维能力都是由平台帮你去提供的，这是从资源管理的层面来说，降低服务器的整体成本。那第二个的话是说service的这种计费模型，目前service呢，它是采取这种弹性计费的，那可以在上一页PPT也可以看到，就是网约车的概念呢，就是说我只为我的行程来付费，那类比于service呢，你只为你单次处理任务来付费，比如说你一次处理任务花了十分钟，那你只需要付这十分钟的计算资源，那剩下的这些闲置资源的成本是由平台来承担，我们可以看下面这张曲线。

那首先可以看到绿色的这条虚线呢，是你的需求预测量，就是你大概你的业务会有这样的一条进步，线性的曲线在增长，但实际的流量呢，是这条灰色的线，就是你实际的流量，是在你预测线的上下前后波动形成一条不规则的曲线，这也负责以目前大多数客户业务形态的一个分布。那我们在做资源规划的时候，是按照我们的预测量来的，采取虚机或者或者物理机的这种形式，那你肯定是在某一段时间内，以你的峰值为间限，形成一个阶梯状的，呃，资源储备情况，那在这种情况下呢，其实你。

灰色的这条线和黄色这条线之间的这部分资源成本，其实是属于你的闲置成本。那无服务架构可以看到十条蓝色的线，因为它更细颗粒度的计费模型和更高的弹性扩容的能力，它可以和你的业务曲线进行一个近乎完整的匹配。那也就是说你实际消耗的it成本就是你业务需要的成本，这是它的第一个优势，按需付费的。按需付费的能力来降低资源闲置的成本。第二个能力呢，就是说在流量发的情况下，因为你的预测值总归是有限的，哪怕你根据你预测值的最高范围去做你的资源容量，也会遇到这种流量发的情况，在流量发的情况下呢，传统资源的扩容速度可能跟不上你业务的增长，就会导致流量溢出，从而形成业务故障。

那这种高弹性扩容的能力呢，可以快速的去拉起实力支撑你的业务来避免流量溢出。那整体来说呢，帮助企业降本增增效，可以从几个方面，一个是说提升你资源的利用率。呃，在同样的业务情况下呢，实际按照你的业务使用量，使用量来去付出你的it资源的成本，第二个呢，是说可以去有一个高强度的弹性伸缩的能力，来避免你业务快速增长的过程中因资源不足导致的流量溢出。那第三个呢，是说降运维成它层其实是一个分装的算运行环境，不需要关注层的运维和扩的一些机制，从而降低平台的人力成本。

啊，这是在计算层面能够给大家带来的一些价值，相比于传统虚机和VM的传统蓄积和物理机的这种形态。那另外一个呢，就是说接下来呢，是讲我们在it资源之上，就是传统的基础算力之上，我们的音视频转码方案还有哪些优势？可以看到这张片子，首先呢，我们是采取了腾讯云函数整的一个转码方案，那用户上传视频之后呢，它可以自动的去触发云函数执行，在这里呢，用到的一个及时是说云函数的世界监听能力，它可以去轻存储的一些事件，当检测到用户有新文件上传之后，可以自动去匹配到对应的云函数来实现不同的转码，可以实现业务流的快速打通。那第二个呢，是说用户他不需要自建转码服务器，可以采取函数的弹性扩的能力，包括快速去支撑的实实力的能力，来降低一个服务器开销和运维成本。

那可以直接叫用已封装好的云函数进行一视频转码，那在这个过程中呢，其实你的算法和云函数的算经装标A网A异个个可接减轻这个存储的事件来进行自动触发转码，而不需要。进行业务调用，第二个呢是说可以有不同的函数规格实例来去处理不同的转码类型，达到一个资源利用率的提升。第三个呢，是他科粒度的计费，计费时长根据你实际的资源处理时长来计费，降低资源的显示费用。呃，第四个的话就是它超高并发的一个能力，可以拉起超轻的并发实力来支撑你的业务高峰，对那整体来说的话，刚才是流程层面的一些优化。

那除了流程面的优化之外呢，我们还有算法层面的，那目前我们采取的这个算法是多媒体实验室的一个转码算法，那从转码效率上来说，它可以得到一定的升，主要体现在几个方面，一个是呃速高清这样的一个能力A。转码之后文件的后运营成本，这个后运营成本呢，主要是指CDN和存储的成本，呃，第二个呢，是说在同样码率的情况下，可以提高一个更高的清晰度来增加用户的观看企业。那第二个呢是说可灵活定制化，这个灵活定制化呢体现在两个方面，一个方面是说功能的扩展性，那虽然说我们提供了标自义源，也可以快速部署在service的算力平台上，那实现定制化的转码或者业务诉求，那第二个呢是说资源的定制化，我们可以根据你传码的时间的要求和压缩力的要求来匹配不同的算规格，并且在请求的过程中可以快速修改。

来实现不同的业务场景。那第三个呢，就是刚才提到的成本和效率，这里就不再做呃意义的介绍，对，这是我们转码的一个方案。那接下来这个接下来我们介绍一下，就是除了转码之外，在一个项目中呢，我们可能会涉及到几个场景，转码呢，主要是解决。

已录制好的文件，它的一个后处理的需求。那其实它是一个非常大的范畴，就是视频处理，包括了对播文件的处理，同时也包括了对直播文件的处理，那对直播文件的处理呢，我们第一步需要考虑的就是如何将直播的内容实时的保存下来。那基于这个需求呢，我们推出了全景录制的方案，那根据字面意思大家其实比较好理解，全景录制呢，就是一个所见所得的录制方案，那你需要就是一个幼接。比如说你的直播地址，比如说你的外观页面，那你供给这个录接之后呢，我们在云里面可以采取无头浏览器的这种形式，将你的页面实时渲染加载出来。

类似于起了一个本地的客户端，来帮你把这个页面实时采集并保存下来。那它相比于你这种本地录制或者说云端录制的方案呢，它有几个优势。第一个优势呢，就是说它可以采取云函数这种形式去封装标准的API，来进行这种一键触发，实时的弹性启动，那服务端去执行快速的录制，避免你在本地录制完成之后上传的这个过程，同时呢也降低了你本地老师端的一个操作复杂度。那第二个呢，是它可以实现多路解码，遗漏编码，降低算力的消耗。因为是采取无头浏览器的这种形式呢，快速渲染免后期合成的这种方案，所以对于算力的消耗整体是比较低的，而算力消耗的一个多少直接影响到你整体的一个成本。

那第三个呢，是说浏览器实现多录直播流C，令百分百的同步集成，这个也是我们所见及所得的录制方案的一个优势，在直播过程中的所有的直播流C0白板，包括说主播切换视角，弹幕以及I以及。I'的一些消息都可以快速的去在这个方案里进行一键录制，不需要做后期合成。那也是所见即所得录制的一个核心，对，这个是全景录制的一个方法。啊，我看聊签里面有一些小伙伴，有一些位稍后的话呢，我会统一去解答。然后第二个，第三个呢，就是说我们刚才其实介绍了两种方案，一种是对于解文件的转码方案，那一种是对于直播文件的实时转存，相当于实时录制的方案，那有很多小伙伴其实比较关心的是说我直播和解播之间有没有一些转换逻辑，其实我们考虑到这种需求呢，也推出了一些直播和点播之间的。

点接，那什么意思呢？相当于说我们会把一个点播文件作为直播的输入源，来达到这种直播的效果。那我们称之为在线输入媒体流方案。对呃，可以看到呢，云函授支持定时任务，那假如说我们现在有一个比较优秀的老师需要去直播，但他的直播时间和他的就直播的时间和他自己的时间有冲突，这个时候不好协调的情况下呢，我们可以邀请这个名师去录制一段他已经讲好的视频。那这个视频呢，可以在指定的时间，通过云函数的形式去把它推出去，让学生达到一个。

这个观看直播的效果，那一定会有小伙伴去问，那这个时候互动怎么去解决呢？我们会有一个类似于助教的身份，可以加入到这个房间里面去，然后和学员进行互动，这样的话可以将一些名师的资源进行快速的复制，来解决这种教育资源不平衡，或者说时间无法协调的问题。对，从而去降低整个平台的一个运营成本。那。基于service这个方案，它有以下几个特性，第一个特性呢，就是性能的提升，它一秒钟可谈1000加以上的实例，这是我们支持的一个快速扩容的能力，当然这是一个高级能力，我们可能需要做一定的设置。第二个呢是稳定性的提升，目前呢，我们对外可承诺的SLA是四个九。第三个呢是网络质量的提升，全网组件内互访延迟小于五毫秒。

那第四，呃，第四个呢，其实是基于实时互动这样的一个处理方案，在前面呢，我们介绍了解播的转码，介绍了直播的录制，并且介绍了直播和解播之间的一个互相转换，那接下来第四个场景，我们看一下针对于实时互动的这种情况，我们有一些什么样的方案，呃，那随着直播的发展，实时互动其实已经为大家所熟悉，那类似于这种主播PK，那类似于这种狼人杀的游戏玩法。对，都是实时互动的最佳的企业，包括说现在比较火的空中课堂，对，那在实时互动里面呢，其实它有几个需求，第一个需求呢，就是说我如何去录指定的用户，因为刚才全景录制呢，我们介绍的是全局所见即所得，但我们还有一些需求呢，比如说我只希望录房间里的某一个用户，或者某一组用户来进行一个后期的处理，那我们支持旁录录制，在旁录制的过程中呢，我们可以选择单用户或者多用户去混合录制。

那第二个呢，是说旁监测，这个和旁录制的逻辑类似，就是我们从TRTC房间静阅遗漏流出来之后，我们需要做什么处理，比如说我是把它漏下来，还是对它进行一定的，呃。内容的分析，比如说他是否违规，然后是否涉及平台的安全规则，那第三个呢，我们可以对这些视频进行后处理，比如说自然语言的处理，呃，比说像实时字幕，实时翻译这样的一些方案，我们都是可以支持的。那它的特性呢，是说第一个我可以满足个性化场景的一些业务诉求，第二个呢，是说我可以和目前原生的一些组件深度集成，这些原原生的组件呢，包括了其RTC的一些组件，也包括了我们签约安全实验室的一些组件，以及说AR的一些组件，都可以去进行快速的进程。

那第三个呢，就是快速接待，敏捷高效，这个是seven开发方案本身就具备的一个能力，这里就不做详细的介绍。那基于上面的四个能力呢，其实我们都是类似于一个单原子能力，那基于这些单原子能力呢，我们也提供类似于这种智能化处理的编排方案，比如说你有一个原始的视频，第一步想先做一个切片，就是类似于也是转码的一种，就是实现形态，先做切片，切片完之后呢，对每个切片去做不同的处理，比如说加字幕，比如说加背景音乐，加完之后呢，再进行合成，这个其实是一个视频编辑的过程。

那这个目前我们提供类似于这种编排的能力。将每一个单元呢，都作为一个节节，比如说裁剪是一个节节，加字幕是一个，转码是一个，压缩是一个对，那这样子的话就可以进行一个原子能力的复用。去形成比较复杂的一个业务处理逻辑啊，在这个过程中呢，我们有几个核心优势。第一个呢是提供可视化的编排，那定制化编排视频处理的原子能力，像搭建乐高积木一样去构建自己一个定制化的视频处理流程。第二个呢是说能力的服用，无需自己构建，可以直接复用腾讯与智能媒体的能力，那让企业聚焦于视频内容等核心竞争力的提升，也就是我们现在会有一些现成的标准原子能力可以直接去使用。第三个呢，是可以标准化处理流程，比如说内容处理流程自动化，以实现项目标准化生产一体化管理的一个效果。第四个呢，就是增强用户的企业，比如说结合用户的标签画像，生成定制化的视频内容，给用户提供一无二的定制化企业，增加用户粘性，提高转化率，那这个在教育、社交等一些领域都用的比较多，特别是在教育，比如说一个班级有30个学生在。

看直播，如果直播结束之后，能够根据每一个学生来生成一段精彩视频，在这段视频内有学生的名字，学生的声音等等，那会增加家长对直播课的一些感官，从而去增加续费率。那这是我们智能化编排方案对于一些个性化定制的批量化处理的能力。

那上面呢，五个方案呢，基本上就是我们针对音视频处理的五个方案，涵盖了直播点播。其二就是呃，互动互动直播这样子的一些场景，那大家可以去进行详细的了解，如果有问题的话，可以在我们屏幕左侧的二维码扫码去企微，等直播结束之后呢，我会进行统一的解答。好的，那我们接下来看我们整体的音视频方案和传统的SS平台对比的一些优势，对。可以看到就是说呃，采取service的方案呢，去完成我们的项目，我们和传统的SS平台相比的一些优势呢，主要有以下几点，第一个呢，是说多规格资源配置，那可显示的去支持多核大内高A的一些定制化需求。

因为普通的SAS化平台呢，它其实是以标准API接口去供服务，那对于后台的资源配置并发情况，用户其实是一个黑盒子，那没有办法根据单个用户来做呃资源的配置。那这是service转码方案和传统SAS平台的第一个差异化，算力可配置，那同时第二个的话，用户可以针对自己的大媒介做切片，然后利用函数弹性伸缩的一个特性来进行并行处理，从而去降级处理的一个时间，增加效率，对这是和传统SaaS SaaS平台相比的第一个优势，算力可配置。那第二个优势是灵活可定制化，这个刚才应该也有过一定的介绍，第一个呢，就是我们会有一些开放工具库的能力，像fphmpa以及编码器，我们可以支持用户自定义去上传。那第二个我们可以开放参数配置，比如说结合定制化编译库，灵活的去调整一些调用参数，来根据用户的需求实现不同的转码效果。

那第三个是开放加密配置，那用户可以自定义实现为界内容的加解密啊，可以自定义去选择加解密的算法。呃，第三个大的区别是说编排可配置，那首先组建建营编排，这个在前面刚刚讲过，就是对固定的功能可以和云平台的产品进行封装和组合，那集成为service类应用组件来提升一个原子能力的复用性。第二个呢，是说处理流程的定制化，那结合工作流，那提供对音视频处理及上下游处理的复杂的编排流程及集成，以及说多分支灵活教用，以及已有的流流程可侵他服用。

那这些呢，就是我们和传统SaaS平台相比的一些优势，主要的优势可能集中在前两节，就是算力可配置，以及说灵活可定制化，从而去提升整体数据处理的使用企业。那第二个呢，就是算法优势，那大多数客户呢，在转码的过程中呢，其实关注的是说转码的效果，资源的利用率的提升，主要是为了降低成本，而算法的优势呢，主要是为了提升在视频处理过程中的效果提升。那我们是和。我们有腾讯云内部多媒体实验室提供的一个编解码算法，那它有以下几个优势，第一个优势呢，就是说目前在整个行业内具有一定的领先性，比如说在2020年世界视频编码大赛里面获取了比较好的成绩，基本上相比于同类型的厂商有一定的优势提升。第二个呢，就是兼容性，可。

呃，目前针对于市面上开源的一些方案进行了快速的一个适配和兼容，就比如说像264AVC265，包括VP8VP9A，以及说A先进的视压缩技术，其实都对品形成了一个比较有的支撑。第三个呢，就是目前我们的算法是经过了一个广泛的证泛应用，腾讯全民K歌、Q讯与戏视频等等腾讯云重量级的互联网产品，服务了超一级的用户，那整体的兼容性得到了用户一个比较好的认可。那这是我们在算法层面具有的一些特性优势。

那结合我们之前讲的那些特性优势，比如说像资源层面的一个细颗粒的计费模型，降低用户的使用成本，像算法层面的一些优势，提高在同样的背景下提升用户的资源使用量。那我们可以看一下这样的一组数据。那第一个呢，就是说我们从。转码的价格层面来比，相比于市面上同样的方案呢，价格可以降低80%以上，那主要的原因就在于我们提供的一个更细颗粒的计费模型，按照使用时长来计算基层资源的成本费用。对，第二个呢，是在同等背景下，我们的码率的一个压缩比的一个提升，那大家可以看到在输入参数相同的情况下，那相比于其他转码方案，我们的转码压缩率可以提升60%~70%左右。

那第三个呢，是说文件大小的一个提升，那在同样的压缩算法下，保证同样清晰度的情况下，我们的稳健企业会比其他的方案小30%~50%之间，那这个数据在业务里面带来最直观的效果就是类似于一个载带高清的技术，比如说。我同样的码率，那通过我们的转码技术带来的清晰度是更好的，可以提升用户的体验，那同样的清晰度呢，我们的体积是最小的，可以降低视频和运营的成本和提升用户观察看的流畅度这样的一些优势。

那我们接下来重点看一下service转码方案的一些应用场景。对，像第一个教育录播课，这个也是目前我们。冻结客户使用比较多的场景，例如说基于屏幕内容的转码压缩服务，提供多种分辨率码率的压缩方式，为存储、播放等环节节省资源和带宽。那其实就是刚才介绍的全景录制的方案，第二个是说美资管理审核。在保障画质的同时，用机码率进行一个预览审核，提升传输的速度，去节省成本，那这个呢，可以和我们刚才提到的呃，窄带高清以及视频编辑去结合起来去使用。那第三个呢，是短视频的编辑分发，在转码压缩的同时呢，可以对极端设备拍摄的画面进行修复提升，这个就是目前整个行业内比较通用的超分或者说画质增强。

那为内容编辑增加素材，刺激长尾内容的一个分发，那这一部这一部分呢，其实是我们算法能力的一个优势体现。那在前面已经做过介绍，第四个呢是直播拆桥混放，那配合融合内容编创解决方案，在进行视频转码的时候同时完成拆桥，拆桥这个概念呢，可能有些人比较陌生，这里做一个说明，拆桥呢是指说在一个视频里面，我将直径画面猜出来，形成多个文件，比如说类似于你看视频的过程中，选择只看某人这样子的一些功能啊，实际的应用场景啊，快速发布直播回放。

那这是我们的几个场景。那目前来说的话，在整个教育传媒，泛娱乐，包括电商，其实我们都是有一些逻辑case。那我们接下来进行一个整体的总结和回顾，那呃，首先的话，我们今天其实主要介绍了几个方案，一个是转码，那转码的话是我们基于多清晰多码率清晰度的一个处理，满足客户的不同的业务诉求。第二个呢是全景录制的方案，那也就是一个所见及所得的录制方案，可以实时的将用户看到的内容录制下来。呃，第三个呢，是在线输入媒体流的方案，采取函数将提前录制好的媒介输入到直播间，那实现点播直播这样的一个场景。第四个呢，其实是内容审核，或者说叫其RTC视频的后处理，那函数获取用户数据之后呢，可以调用多家审核接口来进行审核，包括说SR的一些能力，那打造一站式的方案。

那除了这样几个具体的方案之案呢？今天我们还聊到在海量的音视频处理背景下，我们为什么选择S的方案？其实主要有以下几个点。第一点是S的。高弹性的一个扩缩容的能力，支持大规格大规模并发的一个快速扩缩容，来提升业务的一个稳定性，那第二个呢，是云函数按量计费的一个计费模型，那只是。其原函数按量计费的一个规格模型，在大并发的情况下呢，也不会过多的去增加业务的成本，还是根据实际的资源计算量来进行业务付费。第三个呢，就是我们集成了多媒体实验室的先进的算法，可以实现一些高阶转码能力的输出，来解决不同的业务场景。

好的，那今天我们分享的内容呢，大概就这么多，接下来呢，我们看一下具体的刚才线上的一些提问。嗯，好的，感谢老师的精彩分享，欢迎大家扫描屏幕左侧的这个二维码，进入到今晚的互动答疑区进行提问。友情提示一下大家啊，写下问题的时候，记得同时留下你的姓名和微信号码，并且添加滕小云助手的这个微信号，联系小助手领取奖品。然后我们给大家一点时间，然后让大家这个尽快写一下问题，我们嘉宾老师会稍后给大家解答问题。

好的，我稍等一两分钟，然后我来看一下大家的问题，大家如果有问题的话，现在也可以扫描屏幕上的二维码进行快速提问。嗯。嗯，好的，我现在已经看到了部分小伙伴的问题，然后我现在开始解答小伙伴的问题，那么首先第一个问题有小伙伴提到，请问我们的转码是使用CPU转码还是说是转码卡来进行转码，那这个涉及到转码层的计算资源，目前我们是提供两种形式，一种形式是C的转码，还有一种形式我们使用PU的这种转码能力，也就是我们常说的转码卡，或者说显卡之类的一些高级能力。

呃，然后第二个，呃，第一个问题，看看还有什么，就是不理解的地方，或者说需要补充的地方，也可以实时的在文档里进行更新，我稍后会做一定的补充。那第二个问题是起到冷启动问题是怎么解决的？那这位小伙伴一看就是对于service类的运行原理比较熟悉的小伙伴提的问题，非常的专业啊，我这里来做一个简单的解释，呃，首先是向一些小伙伴解释一下什么叫做云函数的冷启动，那因为云函数呢，它是一个按照实际调用时长来进行付费的资源，那平台为了保证资源的可靠性和整体的稳定性，会有资源回收的这个逻辑，当资源被回收之后，下一次访问会重新拉起实力来支撑你的请求，这个过程呢称之为云函数的冷启动，那冷启动主要包含几个步骤，一个是说起支撑实力的过程，一般来说就是起容器或者说去起虚机的这个过程，第二个呢是拉取你的代码镜像。

去进行一个代码加载的过程。那冷启动是怎么解决的呢？我们目前有几个方案，呃，一个方案呢，就是说预制的方案，那预制相当于提前拉起一个空实力来等待你的请求过来访问，那这个方案呢，我们支持两种模式。一种模，第一种模式呢，是近视阈值。

呃，根据你的业务峰值峰谷比较明确的情况下，来选择一个不同的预制时间段，在指定时间拉起实例进行请求。那第二个呢是弹性阈值，你可以设定一个预置资源池，当预制资源池消耗到一定比例之后，我们会去自动扩容来实现你业务的稳定性，这是采取预计的方案去解决冷启动。那第二个呢，是说我们流程层面的优化，比如说我们的代码分段缓存加载，镜像分段缓存加载等一些缓存技术来降低在代码加载环节的。一个耗时，降级能启动。第二个就是在几层资源层面启动实例的过程中，我们做了一定的启动优化，比如说类似于这种轻量蓄积，对启动镜像做了一定的阉割，来提升启动的时间。

那这是对于线上小伙伴第二个问题的解答。那接下来我们看一下第三个问题，线上有小伙伴提到测试发现FM转码长时间没有结果超时是怎么回事？那我们来看一下这个，呃，首先超时有几种情况，一种是你的云函数执行时间不够，就是云函数本身它是有一个执行超时时间的设置，目前我们支持三到24个，就是三秒到24个小时，如果说在函数的超时时间内，你的转码还没有完成，那么云函数就会执行超时，这个时候的解决思路是说你增加云函数的超时时间，因为转码一般是一个比较常时的耗时任务。我们建议选取异步函数，并且设置一个比较长的超时时间。

那第二个超时时间呢，是说你的API接口超时，就函数在运行，但是你选择了同步函数，然后API网关这边的等待超时时间设置的不够，就会产生接口超时，这个呢，一般来说在接口层是可配置的去进行优化。然后第四个问题，呃，我看小伙伴正在输入的过程中，我来复述一下问题，那对于视频转码参数的多样化是怎么管理的？有没有类似于云解播那样的模板方案或者更好的？那首先我们目前对于转码的参数是通过入参的形式去提供的。那当转码服务创建好之后呢，它是一个标准的API，那你可以通过POS请求去访问这个API，在访问的过程中呢，我们支持一些入餐，这些入餐呢，我们会有标准的入参结构和入餐模板提供，你可以直接去调用。

对，那相比于就是云解播直接的模板形式呢，它可以和你的代码业务链快速的结合起来。对。那首先是第五个问题，就是容器化启动，目前先是最大一计不够用了，这是今天的最后一个问题，也是第五个问题，剩下的问题呢，稍后我们会在与原生技术交流群里进行统一的回复，因为时间的问题对，那我回答一下第五个问题，容器化启动目前的限制最大以及不够用了，这个应该是指容器镜像大小的限制，目前我们是可以开白的，就是呃，因为资源隔离的问题呢，我们默认是一个机，如果说有特殊需求可以联系我们，比如说提供单，或者在客户群里沟通，我们来进行开白，目前呢，最大可以支持十个G，后面呢，我们也会逐步的去开放这个限制。

行，好的，那今天的答疑环节，我们线上的答疑环节就到这里，那如果线上的小伙伴还有其他的问题呢，可以在文档里继续书写，我们会在原生技术交流群里进行一一的回复。好的，感谢大家。好的，感谢老师今晚的分享，感谢观众朋友们的观看，来不及观看或者错过观看的这个观众朋友也不用遗憾，我们每一期的直播呢，在第二天开始都是可以查看回放链接的，同样的链接点进去就可以查看了。那今天大家辛苦了，现我们下期言生花生直播，再见，感谢大家。