视频会议场景始终被认为是 RTC 最具挑战性的场景，一方面，它反抗弱网、低端机适配、降噪、多人上麦等都有极高的要求，对 Web 端的要求也远高于其余场景；另一方面，有很多孵化自会议场景的技术能力最终都被复制到了其余场景。
RTC 在会议场景的独特挑战
为什么说“视频会议”场景对于 RTC 的技术挑战最大？相比于其余行业和场景，“视频会议”中的 RTC 到底独特在哪？
首先，会议场景的需要是更为简单的，这里举 4 个例子。
「自在开麦」
在视频会议中，每一个参会方都能够自由选择是否关上本人的麦克风和摄像头，这是视频会议十分根底的性能，但随着参会人数的减少，技术实现会越发简单。行业内 RTC 个别能够实现五十到上百人的自在开麦，超过了这个人数之后就须要主持人来管制麦位。飞书会议要求咱们反对 1000 个参会方，如果 RTC 反对自在上麦的人数低于 1000，飞书会议的用户应用起来就会十分不不便（尽管所有参会人同时开麦的极其状况比拟少见，然而业务的需要是心愿主持人不要过多“干涉”会议——一直地管制参会人上麦、下麦，把发言能力调配给想发言的人）。假如一场会议里有 1000 个参会方，但只有 50 个麦位能够发言，主持人就要把想谈话的参会人不停地“挪”到这 50 个麦位之中。为了让主持人晓得谁想发言，还须要引入一些沟通机制，整体操作老本十分高。RTC 为什么会限度领有上麦能力的用户数量？如果不限度能够上麦用户的数量，公布 / 订阅流模型的算法复杂度就是 O（n^2），即，如果有 1000 人参会，就会产生 100 万 音视频流公布 / 订阅关系。短时间高频的高低麦操作会造成服务端信令风暴，所以上麦人数才须要加以限度。可是事实中，一些大型会议的规模往往会超过 1000 人，甚至达到几千、上万，咱们不该因为技术的限度而就义用户的体验。
「自在布局」
视频会议个别会提供多种视图布局类型供参会方抉择，从 11 全屏，到 22 四宫格，33 九宫格，到 77 四十九宫格……这还只是一般的宫格，还会有一些其余布局，比方演讲者模式、侧边栏模式等。画面布局类型的丰盛让每个参会者都能够本人抉择本人喜爱的布局，但这样一来，同一个会上，有开四宫格的，有开九宫格的，有开演讲者模式的，视频发布者就须要决策到底公布什么样的分辨率。如果公布的分辨率过大，对于抉择多宫格的订阅方来说，分辨率就过剩了，同时还造成了极大的上行带宽和设施性能压力——试想一下，一个订阅方同时拉了 49 路 1080P 的视频，什么样的神仙设施和带宽都扛不住；如果公布的分辨率过小，对于全屏或者演讲者模式这样的大窗口来说，清晰度就会有余，用户体验会受到影响。严格来说，每一种布局都应该有一个最合适的分辨率。在多人会议中，如何在无限的带宽与设施性能下，尽量提供灵活多样的画面布局，是一个很大的挑战。
「屏幕共享」
这个性能大家比拟容易了解，它的挑战在于，屏幕共享尽管也是视频流，然而它的视频画面特点和咱们摄像头拍摄的视频画面特点是不一样的。简略来说，屏幕共享对画面的要求更清晰，要能看清楚很小的文字，然而对于帧率的要求并不高。对于编码器来说，须要决策什么时候编高帧率的视频，什么时候编低帧率的视频，这是要害。
「Web 入会」
很多时候，视频会议软件的用户是“长期用户”，比方用视频会议去加入一场面试，或者是合作伙伴用你们公司的会议软件来加入一场会议…这些“长期用户”可能并不心愿去装置一个会议 App，用 Web 入会就是一个十分好的抉择。然而 Web 对音视频有很多限度，而对视频会议的需要和体验的要求一点都没少，怎么能力把 Web 入会的体验尽量追上 Native 的体验？
除了业务需要更加简单以外，视频会议场景所面临的环境也更为极其。
过来，开视频会议都是在业余的会议室里开，有很多业余的会议硬件设施来撑持会议体验，环境是绝对比拟好的。但当初，散会环境早已不限于会议室了，会议环境的多样性让 RTC 面临了很多新的挑战。这几年，疫情让咱们居家办公的工夫更多了，在家里开视频会议成为了很广泛的场景；一些常常出差的人——他们往往也是会比拟多的人——在路上、车上、高铁上甚至飞机上通过手机加入视频会议也十分广泛。
会议环境多样性为 RTC 带来的挑战次要能够分为以下四大类：
首先是极其弱网，俗称“用户网络差”。这种状况十分常见，尤其是不在公司会议室里散会，弱网状况更常见；
其次是弱设施，也就是“设施性能有余”。如果参会设施不是业余视频会议硬件，就会承当更多的性能压力，尤其当参会人开启美颜或者虚构背景这样高耗费的性能之后，本来能够散会的设施也会呈现性能有余。当初在视频会议中应用虚构背景是一个十分高频的性能，大家看我当初视频的背景就是一个虚构背景。
再者就是会议场景的噪声类型会更多，除了会议场景常见的键盘声之外，如果你不是在会议室散会，就会随同各种各样的噪声：空调的声音、开关门的声音、隔壁装修的声音、左近人谈话的声音、小孩的哭闹声，室外的喧嚣声……
最初一个挑战是光线差。来到业余会议室的环境之后，可能会面临重大的光线有余、背光等问题——原本家里的光线布局就不是为了居家散会所设计的，更不要说在户外或者交通工具上散会了。
从技术角度看，RTC 技术最后就是从视频会议中形象剥离进去的，起初逐步利用到会议以外的畛域，所以很多 RTC 的新场景其实就是从视频会议中迁徙进去的。换句话说，RTC 在视频会议场景的「独特性」，其实也能够认为是一种「当先性」。
从最近几年的行业倒退来看，一直有从会议场景技术溢出到其余行业的案例。之前特地热门的「大班小组课」，其实就是会议中的「分组会议 Breakout Room」。再比方当初很火的「3D 空间音效」，其实最后的利用是高级视频会议产品中的「听声辨位」，HP 2005 年公布的 Halo 就反对这个性能。
最初说说「千方会议」。咱们在去年 6 月曾经对外介绍了咱们做的“千人上麦”能力，在往年 2 月份正式对外公布了这个性能。过后很多敌人不了解咱们为什么要做那么大的上麦并发，实际上是因为，咱们看到不仅视频会议有这个需要，其余场景也陆续呈现了这个需要，像在线教育大班课中的齐声朗诵或者抢答，大型吃鸡游戏中的世界语音，还有当初正在产生的大型 VR 社交，这些场景须要自在上麦的人数很容易冲破几百甚至上千。既然「千方会议」能够反对大型视频会议，何不做成 RTC 的规范能力，来解锁各行各业中“自在上麦”人数的瓶颈，施展更大的价值呢？顺便提一句，目前咱们还在进一步冲破上麦人数下限，实现「万方会议」甚至更多。
「千方会议」过来曾经和大家介绍过了，明天不再重点开展。接下来和大家分享视频会议对 RTC 的几个新的挑战和咱们的思考实际。
简单光线下的视频体验
后面提到，很多用户入会时所处的地位可能并没有很好的光照条件，比方晚间的户外，光线会严重不足；比方在室内，如果光源的地位不佳，会造成逆光或者侧光。顽劣的光照条件会重大影响视频体验，但咱们个别人散会也不会像业余主播一样筹备专用的打光设施，因而，一旦光线不好，拍摄成果就会差，而一旦拍摄根底成果差，仅仅靠视频后处理技术是没有方法很好地解决视频体验问题的。
为了解决这些问题，咱们引入了一系列的相机技术，包含主动对焦、主动曝光这些比拟根本的相机技术。RTC 场景和其余场景有个不一样的中央，画面中个别都是人像占据主体，而当画面中人像占据主体时，如果不做特地解决，因为摄像头自身是“均匀测光”的，当人像处于逆光环境时，因为背景很亮，会导致曝光有余，人脸会显得过暗。因而，咱们在 AE 的根底上又减少了人脸检测算法，即 FaceAE，当检测到人脸时，把“均匀测光”优化为“依据人脸检测后果”来做曝光解决，解决画面过曝、欠曝的问题。为了实现最佳成果，咱们与国内外很多手机和芯片厂商保持良好的单干，把硬件的相机性能和咱们自研的算法进行深度联合，让每一款设施都达到最佳性能。目前咱们曾经对线上 18000+ 款机型进行了适配，笼罩低中端各类机型。
咱们应用了一些出名会议或社交 App 来和咱们的拍摄成果做比照，大家能够感受一下基于 FaceAE 算法优化过的相机成果。第一组比照图是一个户外黄昏背景，画面中有一盏路灯，能够看到左边应用 FaceAE 算法优化过的采集成果，人脸更亮，天也更蓝，画面整体感觉更难受。第二组是室内暗光场景，右边是个黑脸，左边人脸的亮度就比拟失常；第三组是白天逆光场景，这种场景的背景很亮，一般 AE 给的曝光就会有余，人脸会显得十分黑，而应用 FaceAE 优化过的相机成果就会比拟亮，五官也能看清晰；第四组是室内侧光场景，这种场景照出来很容易阴阳脸，能够看到右边图上一半的脸都是黑的，眼睛都看不见在哪儿，而左边尽管不可避免还是存在阴阳脸，但画面更亮，五官都能看清了。
以上是咱们仅仅靠相机采集优化的成果，在没有开启任何美颜算法的状况下，就能达到比拟现实的画质成果。而且，因为 FaceAE 调用的都是零碎底层的能力，没有应用算法，不会引入额定的性能开销。当然，开启美颜之后，还能再精益求精。
后面提到会议场景的技术溢出，「相机采集优化」也是如此，它对于其余非会议场景也有十分宽泛的利用。在视频社交场景中，参加平权聊天的大部分用户都是非专业主播，大家就是长期上线聊天，不会特地筹备好的光源或打光设施；在直播连麦场景，主播是业余武装的，但连麦的观众或场外嘉宾往往是非专业主播，也不大会思考光线的问题；在互动课堂场景，老师端个别有较好的开播条件，但学生端的条件就会差一些；还有一个是咱们最近发现的很乏味的场景，也是咱们遇到的一个实在场景——健身小班课，它和一般的“互动课堂”场景有点像又有些不一样，尽管健身老师能够算得上是“业余主播”，但传统主播用的打光设施没方法关照到整体授课的场景，图上的瑜伽老师在客厅开播，客厅连着阳台，造成了一个大逆光场景，导致瑜伽老师的脸齐全是黑的，影响与学员的互动成果。
屏幕共享的优化
屏幕共享是视频会议场景最罕用的性能之一，用户对于共享文字 /PPT 的要求个别是高清晰度，对于共享视频内容的要求个别是高晦涩。咱们比拟容易做到依据共享内容的文件属性来决定是“清晰度优先”还是“晦涩度优先”的编码策略，比方共享 PPT 时主动切换为“清晰模式”，共享视频时主动切换为“晦涩模式”，但这样设计会遇到一些问题：如果用户的 PPT 里嵌入了一段视频，在播放这段视频时理当谋求“晦涩模式”；如果用户视频其实是一段 PPT 的教学录屏，外面有大量的工夫在播放静止的文字和画面，这时候理当是“清晰模式”。也就是说，咱们共享的内容，它是是静止的还是静止的，是由用户决定的，而不是程序能够决定的；咱们也不可能要求用户在共享的过程中手动地去不停抉择切换以后的编码模式，这样会重大影响用户体验，而且用户很可能会遗记切换。
业务层面不能通过用户的输出来解决问题，这个挑战就落到了 RTC 上，RTC 要如何帮忙用户及时调整最佳模式呢？
咱们钻研出了一个“智能编码模式”，在屏幕共享的过程中，让 RTC 自动识别用户传入的视频内容类型，并且一直主动调整最佳的策略。
咱们来看一段视频。视频里的一个参会人在共享屏幕，一开始，他在浏览网页，共享画面是静止的图片和文字，所以分辨率十分高，帧率和码率非常低；而后参会人关上了一个视频网站，共享内容变成了一段视频，对应的帧率和码率缓缓地俯冲，为了均衡性能，对应的分辨率也在缓缓地降落，帧率最初俯冲到了 30 帧；而后他又换了一段视频播放，这段视频只有两头局部在动，静止局部占据画面比拟小，所以帧率没降，但码率缓缓升高了；最初，他又回到了最后的网页，帧率和码率逐步降落，而分辨率又缓缓地回升到了高清模式。这段视频演示了在共享内容类型切换时“智能编码模式”的主动调整策略。
“智能编码模式”带来的一个重要收益就是线上均匀分辨率的晋升。一些共享内容原来被零碎认为是“视频”而采纳了“晦涩模式”，当初被算法纠正成了“高清模式”（实际上视频会议场景共享动态内容的概率更大），线上均匀分辨率有了翻倍的晋升。同时，因为零碎永远抉择最合适的编码策略，因而线上屏幕共享场景下的整体 CPU 耗费升高了 20%。
咱们来看看「屏幕共享」在非会议场景的利用。过来咱们认为「屏幕共享」只利用在会议场景，随着着“线下流动线上化”的趋势，「屏幕共享」在会议以外的利用也越来越多了。在线教育就不多说了，它原本就是视频会议场景的一个子类，除了一般的“屏幕共享”以外，在线教育还有一个“云端录屏”的需要——把软件的 UI 一起录下来回看或作为直播对外分享，实质上这也是一种非凡的“屏幕共享”——通过在云端模仿一个虚构学生上课，在云端关上应用软件的界面来进行「屏幕共享」。在近程帮助场景，通过「屏幕共享」，子女能够通知不会应用手机或智能电视的父母如何操作，甚至间接近程操作；在 VR 直播教学场景中，老师通过 VR 设施在虚拟空间进行操作，学生通过 VR 设施追随老师的视角观看和学习，沉迷式、实时互动式的屏幕共享能够极大地晋升教学效果。
多宫格视图体验的晋升
多宫格视图也是视频会议中的根本需要，它让尽可能多参会者的视频被播放进去，能够晋升参会互动性，但也非常容易引起客户端性能和带宽的有余，因为你要订阅的视频流变多了。对此，RTC 个别会提供动静“弱网降级“和“性能降级”，但在视频会议中，个别的弱网降级和性能降级是不够的。
这个场景次要有三个特点：一是每个用户都能够自由选择本人喜爱的视图布局；二是不同布局对应不同阶梯的分辨率；三是任何一路流都可能会面临从高到低各种档位的分辨率的订阅申请。目前行业里 RTC 广泛反对「大小流」，也就是两档分辨率，但两档分辨率在视频会议中远不够用，而减少档位又会大大增加性能开销，如何既能灵便撑持用户自定义会议视图布局，又能兼顾设施和带宽性能？
针对这个场景，咱们设计了「10 级档位的 Simulcast」。既然两档分辨率不够，咱们就来减少档位嘛。这里的次要难点在于，对于发布者来说，他相当于要做 10 路视频流的编码，这对于发布者的性能耗费是微小的，绝大部分设施的性能是不够的。所以在实现的时候，咱们会对档位进行聚合分组，最初分成四档，分组的准则是“按分辨率订阅人数的权重排序，尽量关照更多人的体验需要”。也就是说，咱们优先选择订阅人数多的分辨率进行编码，订阅人数少的排在前面。如果设施性能跑满了，档位不够分，就归并到最靠近的已编码的分辨率档位。除此以外，动静弱网降级和动静性能降级也会与 Simulcast 联合，如果订阅端订阅太多流或者性能有余了，那么就主动降到下一个档位。相比大小流两个档位，多档位的 Simulcast 降级会比拟平滑，即不是间接从 1080P 降到 90P 这样的低分辨率，而是一档一档地逐档降级，直到降到一个最合适的档位。
咱们来看「Simulcast」的线上数据体现。「Simulcast」的次要作用是晋升实时画面的清晰度，尤其是多宫格视图的清晰度。咱们看到，22 宫格的清晰度从 360P 晋升到了 540P，33 宫格的清晰度从 180P 晋升到了 270P，一些中高端手机全屏模式下的清晰度从 360P 晋升到了 720P，线上均匀分辨率晋升了 16%。在晋升清晰度的同时，咱们也要均衡一些其余的指标。在实时性方面，端到端延时与原先程度放弃持平；在流畅性方面，视频百秒卡顿率也没有降落。「Simulcast」的最大挑战是给公布端带来的性能开销，但咱们看到性能开销的上涨是十分轻微的，根本不影响公布端的性能。
咱们再看一下「Simulcast」在会议以外场景的利用。比方连麦场景，随着连麦的人数越来越多，“多视图布局”的需要也应运而生，在社交场景，咱们叫它“动静麦位”。在“万物互联”的物联网生态中，各种类型的设施都在应用 RTC，小到手表，大到智慧电视，两头还有手机、Pad、电脑，电视机也有各种尺寸，设想一下，如果咱们用手机和父母、小孩通话，父母应用电视，小孩应用手表，如果让电视和手表订阅雷同分辨率的同一路视频是极不适合的，这个场景也适宜「Simulcast」计划。
实现会控的关键技术
第四个话题是对于「如何做好会控」，对于 RTC 来说，做好会控的要害是什么？
在会控中，和 RTC 相干的一个难点是“音视频状态和用户状态的一致性”的问题。比方一个用户在零碎上显示是麦克风开启的状态，如果状态是谬误的，实际上他是无奈上麦的。反过来，零碎上显示他曾经闭麦了，但实际上他还在上麦，如果他说了一些不心愿被会上其余参会者听到的话或者声音，就会波及到重大的隐衷透露问题。还有一个难点是“用户状态变动的及时性”，比方主持人要让某个人闭麦，当他操作闭麦该人的动作之后，须要可能马上、真正地把麦闭掉，一旦及时性做得不好，不仅让参会人的体验不好，还可能造成主持人无奈及时控场的问题。
这两个问题的关键在于“信令的可靠性”，咱们如何保障信令必达的同时，还领有极低的延时，并且与音视频状态同步？
咱们的解决方案是，让信令复用 RTC 音视频流的传输链路与弱网反抗策略，确保音视频和信令的达到率雷同，保障音视频状态的统一。
咱们为信令定义了几个指标，一个是 200ms 达到率，一个是总达到率。总达到率咱们做到了 100%——要确保“音讯必达”，这也是信令的根本要求。而且，咱们还要做到“低提早”的“音讯必达”，这就要求信令是在肯定的工夫范畴内达到的，否则即便信令达到了，也会失去一部分的意义。咱们抉择了「200ms 达到率」这个指标，目前这个指标的线上数据体现是 98.6%，也就是说，在 98.6% 的状况下，信令能够在 200ms 之内达到目的地。
咱们再看一下延时方面的指标。目前，「端到端均匀延时」指标体现是 51 ms，但「均匀延时」这个这个指标其实比拟宽松，咱们会看一个更严格的指标，就是「端到端延时九非常位值」，简称「PCT 90」，咱们线上 PCT 90 的指标体现是 117ms，也就是说，线上 90% 的用户的端到端音讯可能在 117ms 以内达到。可能做到这样的达到率和延时，次要就是因为咱们的信令复用了 RTC 的传输链路。复用 RTC 传输链路还有一个很重要的益处，就是保障音视频数据和信令数据的延时和达到率是统一的，这样，用 RTC 信令来实现会控就不会呈现状态不统一的问题，因为极其弱网是不可避免的，最极其的弱网就是断网，咱们当初说达到率是 100%，前提是网络还是通的，如果断网了，任何信令都不可能传输了，而且数据上还无奈统计到。然而，如果音视频和信令采纳同一条链路，假如真的断网了，音视频传输和信令传输都无奈达到，要断一起断。这样的话，不论是什么样的网络状况，音视频状态和用户状态永远都是统一的，咱们做会控的目标也就达到了。
咱们打磨的「实时信令」在其余畛域也有宽泛的利用。咱们刚刚说到会控，其实在很多 RTC 畛域中，多多少少都存在一些会控的逻辑，像互娱社交场景中也会存在房间治理，如果一些主播、连麦嘉宾、上麦观众说了一些不适合的话，或者做了一些不适合的行为，管理员就须要禁止，简略点就是禁言或踢人，如果禁止不胜利或不够及时，可能会引起更重大的问题。除了会控以外，「实时信令」也能够用到一些新的玩法中。这里举一个「一起看抖音」的场景，抖音上就有这个性能，两个敌人之间能够连麦一起刷视频，“主态”刷到哪儿“客态”的视频进度就跟到哪儿，两边的视频延时低于 100ms，而实现视频滑动状态主客态同步业务逻辑的技术就是「实时信令」。
Web 端实现简单算法的新解
最初一个话题是对于「Web 端实现简单算法的新解」。咱们先看一下 Web 端有哪些性能耗费的“杀手”。咱们晓得，RTC 的编码是很耗性能的，但和美颜、特效、虚构背景比起来还是小巫见大巫。这些性能在视频会议场景中曾经成为“刚需”，简直每个居家办公的参会人都会应用，咱们要如何既保证客户端设施性能，又达到媲美 Native 的成果呢？
咱们做了一系列的思考和尝试。
第一种是业内的广泛做法——在 Web 本地加载这些算法。Web 本地运行算法对于设施 CPU 的耗费都十分大，而且因为 Web 浏览器自身存在性能瓶颈，哪怕设施再好，在 Web 端做特效的成果都可能打折扣，一些简单的特效甚至可能无奈运行。浏览器的兼容性也是一个问题。还有一个问题是比拟容易被疏忽的，因为 Web 会把代码和模块下载到本地运行，如果在本地加载特效算法就会减少包体，反对的算法越多，包体就越大，它会影响页面加载速度，算法的丰富性也会受到限制。
咱们也钻研了业务端是如何解决这个问题的。行业里，业务端会应用虚构摄像头的计划。虚构摄像头自带美颜性能，Web 通过虚构摄像头来采集视频，这个采集的视频曾经通过了特效解决，因而浏览器不再须要有额定的性能耗费。但这种操作有个问题——用户必须装置虚构摄像头，这和 Web 端谋求“免装置即用”的便捷性理念是违反的。个别会采取这种计划的用户是业余主播，他们原本就在电脑中装置了很多美颜、虚构摄像头的软件，可能是因为长期换一个网页开播的平台做直播所以应用虚构摄像头，像加入面试、长期会议这种场景，普通人可能都不晓得有“虚构摄像头”，因而这种计划的适用性是比拟局限的。
通过联合 RTC 的劣势，咱们摸索出一种新的解法——边缘渲染。边缘渲染的原理是，当发布者在本地采集了视频之后，不是间接向订阅端发送流，而是先发送到 RTC 边缘，在边缘进行云端美颜和渲染，再发送给对端，同时也发回给公布端用于本地预览。这对“边缘”的要求很高，边缘要尽可能多，能力在边缘就疾速把特效解决了。「边缘渲染」的益处是对本端简直没有额定的性能耗费，齐全不依赖本地设施算力，能够运行更酷炫、更简单的算法。大家可能会放心「边缘渲染」会减少发布者本地预览以及发送到对端的延时，咱们统计了一下线上数据，开启边缘渲染只比一般音视频通话减少了 30ms 的延时，本地预览提早低于 200 ms，实时帧率能够达到 30+ fps。
咱们来看一下实际效果。视频右边是未渲染的预览画面，左边是经边缘渲染之后再返回本地的预览成果，提早管制在了 200ms 以内，轻微的提早根本不会影响失常的发言和交换。同时，像这样的虚构头套是一个比拟耗费性能的算法，「边缘渲染」的计划冲破了 Web 运行精密特效算法的性能瓶颈。
从视频会议场景孵化出的「边缘渲染」能力也能够用到其余利用场景。比方在一些美妆、电商场景，能够反对用户免下载软件，通过云渲染的形式即可体验试妆、试戴成果。像图上的一些万圣节特效、魔法变身特效、老年特效都是一些比拟耗算力的特效算法，通过云端渲染，在低端机上也能够不便地实现。
作者：杨若扬，火山引擎 RTC 产品负责人