文章图片
2021年6月9日 ， 「亚太内容分发大会暨CDN峰会」在北京举行 ， 好未来直播中台产品负责人冯权成出席大会的论坛「互动直播论坛」 ， 并发表题为「实时音视频在教育场景下的成熟应用」的主题演讲 ， 向业界介绍了好未来在RTC（Real Time Communication ， 实时通信）领域所取得的的技术成果和在教育场景下的成熟应用 。 本次大会上 ， 好未来荣膺亚太内容分发大会RTC技术创新奖 。
文章图片
此次分享的主要内容包含四个部分：
· 直播中台产品全景介绍
· TalRTC整体架构
· 高可用及弱网对抗策略
· 针对教育场景的特殊优化
全场围绕如何使用技术手段最大限度保障老师和学生上课的音视频质量 ， 可谓干货满满 。
我们一起回顾一下本次分享的过程：
整个直播中台价值定位
文章图片
尽管我们名叫为直播中台 ， 但我们的音视频能力不仅只是直播 ， 也包含了点播 ， 因为有直播需求 ， 就会有支持回放的点播需求 。
直播中台的定位是在集团后台的支撑下 ， 向前台的业务提供音视频的能力 ， 如自研RTC、RTMP直播、点播等音视频能力 。
同时好未来通过适配层封装自研及其他厂商的方式 ， 向前台提供音视频产品能力 ， 这主要是出于灾备、价格、技术之间相互PK、相互学习等的考虑 。
直播中台支持的前台业务有大班、培优小组课、网校1V1等等 ， 覆盖了大班、小班、1V1等课堂形式 。 此外还支持了内部的IM办公软件音视频通话、在线会议等应用场景 。
直播中台的音视频能力整体架构
文章图片
围绕RTC这一核心产品 ， 衍生出了全场景的音视频产品矩阵 ， 比如可以通过RTC的媒体服务做转推 ， 推流到CDN ， 我们搭建了支持标准CDN直播协议的直播云 。
【云控|「好未来」冯权成：实时音视频在教育场景下的成熟应用】RTC的录制会把文件上传到点播云进行处理；CDN直播配有RTMP录制 ， 同样也会把文件上传到点播云上进行处理 ， 点播云对视频进行二次加工 ， 剪辑、裁剪、拼接、截图、水印或者转码等其他相关媒体的处理能力 ， 便于学生课后观看回放复习或者教学内容的二次推广 。
直播中台RTC能力整体架构
文章图片
好未来RTC整体能力是基于自研UDP私有协议和标准WebRTC协议搭建的 ， 从而实现私有RTC与WebRTC相互打通 ， WebRTC作为私有RTC的一个补充 。
整个直播中台RTC的能力架构 ， 是建设在IaaS层计算资源的基础上 ， 目前的策略使用的是云主机加线下IDC机房的组网方式 ， 使用IDC的机房的原因是网网络质量、线路质量有保障 ， 这部分资源作为兜底资源 ， 而云主机主要是为了应对快速弹性伸缩 ， 例如当线上的用量有突发需要快速扩容时可以选择云主机 ， 当线上用量下降时快速缩容云主机 。
为了应对量及突发时达到快速弹性伸缩的目的 ， 我们在此基础上构建了一个可视化管理后台 ， 能够高效的通过可视化页面的方式快速扩容 ， 目前能够实现分钟级扩容/下线上百台机器 ， 针对线上用量做精细化管理 ， 保障线上稳定可用的同时做到精细化成本管理 ， 降低业务成本 。
直播中台产品全景图
文章图片
直播中台的产品全景图从底层的RTC服务端到RTC的客户端 ， 到中间的调度管理、负载均衡、房间管理、后台管理、云控相关以及引擎切换相关的系统 。 最上层是对外提供标准化产品服务的官网和开发者中心 ， 方便前台的业务高效、便捷使用我们的产品和服务 ， 减少内部对接的成本 ， 提高效率 。
右侧是一套服务支撑以及保障系统 ， 比如驾驶舱管理系统 ， 主要负责实现弹性扩容、引擎切换、云控配置下发等功能；其中需要重点谈一下云控配置下发功能 ， 主要实现调度策略及权重的配置下发、以及部分新功能需要云控灰度下发等 。 告警系统是全链路的监控系统 ， 主要监控音视频的质量、五大指标（入会成功率、延时、卡顿、音画同步、端上性能开销）和服务器资源水位监控 ， 通过可视化的管理页面 ， 实现快速的针对异常情况进行提前干预和保障 。
全链路质量监控 ， 技术支持接到前台业务反馈线上有问题后 ， 通过全链路监控系统快速定位问题 。 日志埋点模块基于埋点日志 ， 做日志分析 ， 大数据的处理 ， 给前面这些服务质量保障系统提供数据支撑 。
TalRTC整体架构
冯权成就好未来RTC整体架构进行了介绍 ， 大概分为三层 。
文章图片
第一层 ， SDK终端接入 ， 终端SDK通过DNS解析到负载均衡服务器集群 ， 之后负载均衡服务会给终端SDK分配一台调度服务器（IPLocation） ， 调度服务器会告诉客户端去连接哪台媒体服务器 ， 客户端和媒体服务器建立起连接后 ， 开始信令交互（SignalGW）,然后开始音视频数据的传输 。
媒体服务中SignalGW主要负责包括入会退会或者相关信令的通知 ， Record负责录制服务 ， Audio负责音频的转发 ， AudioMix负责音频混流 ， Video负责视频的转发 ， VideoMix负责视频混流 ，LocalLog负责本地日志落盘 。 Convert负责转推到CDN ， 将RTC转成RTMP推流给CDN进行大规模分发 ， 从而解决需要高并发场景的需求 ， 例如在线大班课 ， 需要千万级并发同时在线观看 。
最右边是分布式缓存系统 ， 缓存业务服务器相关的数据 ， 如业务服务器的资源情况、可用服务器的状态、健康度等 ， 调度服务器根据上述信息进行调度 。 后台管理系统就是我们前面提到的服务质量支撑管理系统 ， 这里不再赘述 。
文章图片
整个SDK终端接入流程如上图 ， 支持域名+IP的调度方式 ， 当域名解析不通时走IP方式分配服务器 。 SLB的服务器会给终端分配调度服务器 ， 调度服务器根据服务器的信息、资源水位情况、健康度情况（实时探测 ， 服务器自身负载 ， 以及链路的丢包、延迟）给终端分配最优媒体服务器 。
文章图片
SDK架构 ， 最上层是API层 ， 将音视频能力通过API的形式暴露给业务层调用；API层之下有房间信息、用户信息以及配置信息 。 最重要的是音频引擎和视频引擎 ， 视频引擎包含了视频设备管理、视频的处理、输入外部视频源（桌面共享、视频自采集等）、编解码器、媒体传输通道的管理、netEQ（JitterBuffer+解码+信号处理） 。 音频引擎与之类似 ， 不再赘述 。
最右是信令模块、日志采集模块 ， 以及本地录制、推流到CDN的模块、拉流器等模块 。 拉流器是RTMP拉流器 ， 因为我们的SDK提供两种模块组合 ， 一种提供方式是纯RTC模块 ， 另外一种方式RTMP模块+RTC模块 。
高可用及弱网对抗策略
1 节点分配策略
文章图片
RTN在跟客户端分配媒体节点时 ， 会根据三个信息做节点的分配 。 第一 ， 是地域；第二 ， 运营商；第三 ， 大数据的分析 。
其中大数据分析会实时探测服务器链路间的丢包、延迟 ， 得出最优链路 。 调度服务器根据上述三类信息找到可用服务器后 ， 以负载均衡的方式 ， 把请求均匀得调度到不同的服务器上 ， 会分配就近接入节点（最优节点）、备用节点、兜底节点 ， 当最优节点异常时 ， 客户端可以自动切换到备用节点 ， 保证用户端无感知 。
这里的就近接入不仅是距离上的就近 ， 更主要是基于延时以及基于丢包来计算 ， 延时最低、丢包最少的就是最近的 。 兜底的节点的设置是出于灾备的考虑 ， 一般情况下不会用到 ， 只有在最优节点和备用节点均不可用时才会用到 。
2 路由策略
文章图片
路由策略会根据3个信息来做路由 ， 第一 ， 路径最短；第二 ， 延迟最低；第三 ， 丢包最少 。
基于上述三个信息 ， 选择出可用路由 ， 经过负载均衡 ， 选出最佳路由节点 ， 同时选一个作为备用路由节点 ， 当最佳路由节点不可用时 ， 客户端可以自动做路由的切换 ， 保障用户无感的情况下 ， 完成切换工作 ， 从而实现高可用地保障用户体验 。
3 单点&同运营商、多点&跨运营商调度
RTN的调度系统目前有多种调度方式 ， 支持单点、多点、同运营商、跨运营商等调度方式 。
文章图片
单点和同运营商调度比较简单 ， 客户端向调度服务器请求媒体节点 ， 调度服务器向客户端分配同地区、同运营商的媒体节点 。
文章图片
跨地区、跨运营商的调度相对复杂一点 ， 如北京移动的学生要跟上海电信的老师进行1V1通话 ， 调度服务器会分别给北京移动的学生分配北京移动的媒体节点、给上海电信的老师分配上海电信的媒体节点 ， 北京移动媒体节点和上海电信媒体节点之间通过上海多线媒体节点进行转发 。
跨运营商及地区的情况下 ， 首先根据客户端所属的运营商来给他分配最近区域同运营商的媒体节点 ， 再通过多线节点做级联转发 。
4 业务异常恢复
文章图片
客户端首先向调度服务器请求最优媒体节点 ， 业务服务器的心跳服务 ， 会定期上报媒体服务器的心跳 ， 如：服务器可用资源、水位、服务器健康度、负载情况、丢包、延迟等信息 ， 调度服务器根据这些信息来做调度 。
高可用的手段大致分为三种 ， 第一种是支持断网重联的机制 ， 客户端断网 ， 网络恢复以后自动重联 。 第二种是SDK支持切换服务器 ， SDK通过调度服务器获取主节点和备用节点 ， 当主节点不可用时可自动切换到备用节点 ， 从而保障终端用户无感知 ， 不会影响老师和学生的上课体验 。 第三种是兼容TCP和UDP ， 就TCP而言 ， 弱网的情况下连接的成功率、连接的到达率会受到影响 ， 有些服务会通过UDP的方式去做通知或广播 ， 提高弱网下抗丢包的能力 。
5 媒体节点异常恢复
媒体服务支持功能模块的进程守护机制 ， 保障功能模块不会假死或发生其他问题 ， 支持故障自愈逻辑 。 之前提到的节点之间的切换 ， 其实就是一种故障自愈的逻辑 。
文章图片
接下来我们针对不同场景分析一下异常恢复逻辑：
首先 ， 先看一下单线媒体节点异常恢复逻辑 。 电信用户A和用户B进行1V1的音视频通话 ， 开始时电信用户A连接电信节点1 ， 电信用户B连接电信节点2 ， 电信节点1和电信节点2建立起级联连接 ， 在双方通话过程中电信节点1机房突然出现网络故障 ， 此时会自动启动节点切换逻辑 ， 电信用户A 的客户端会自动切换到备用节点电信节点3并与其建立连接 ， 电信节点2和电信节点3之间建立级联连接 ， 保障平滑切换链路 ， 整个切换过程终端用户无感知 。
文章图片
接下来再看一下多线媒体节点异常恢复逻辑 ， 多线的逻辑也是类似的 ， 假设电信用户A和联通用户B进行1V1的音视频通话 ， 由于跨运营商 ， 所以需要三线节点3做转发或中转 。 假设三线节点3所在的机房网络故障 ， 电信节点1和联通节点2会自动切换到备用的三线节点4 ， 与三线节点4重新建立连接 ， 从而保证双方音视频通话不受影响 。
6 SDK弱网对抗策略
文章图片
SDK目前支持SVC分层编码 ， 支持两种分层逻辑 。
第一种逻辑是传统意义上的SVC ， 支持时域分层 ， 共分为3层 ， 其中基础层帧率最低（5-6fps） ， 中间层帧率居中（10fps）,最上层帧率最高（15fps）；每一层均能被独立解码播放 ， 因此即使上层丢失了 ， 之下的层级还能够被正常解码播放 ， 媒体服务器的「下行状态统计决策控制器」可以根据接收端的网络评估情况做相关决策 ， 通知SVC过滤器给接收端转发与之网络情况匹配的媒体流 ， 从而降低卡顿率 。
另外一种分层编码逻辑是大小流的逻辑 ， 大流和小流通过一路流 ， 在编码时一次性编码了两种分辨率 。 同样的 ， 媒体服务器根据接收端的网络评估情况做决策 ， 决定给接收端转发大流还是小流 ， 通过媒体服务器的SVC过滤器进行转发；当网络质量正常时转发大流 ， 比较差的时候转发小流 。 这两种分层编码逻辑由「SVC Controller」控制采用哪种逻辑 ， 下边分程编码及RTP/RTCP协议的打包 ， 接下来经过NACK重传和FEC前向纠错 ， 最后经过「Pacer Sender」平滑发送 ， 保证在网络抖动比较厉害的时候 ， 能够匀速地发送数据 。
如果横坐标表示时间 ， 纵坐标表示发送的码率 ， 画出来一条线应该是趋近于水平线 ， 保证发送码率是恒定的 ， 接收端才能流畅拉流播放 。媒体服务器中有一个比较重要的模块就是「下行状态统计决策控制器」 ， 该模块会根据接收端REMB模块评估的带宽情况来决策 ， 通知SVC过滤器给接收端转发适合接收端网络条件的媒体流 。 当接收端带宽资源过剩时 ， 向其转发高帧率、高分辨率的流；反之则会向其转发低帧率、低分辨率的流 。
此外 ， 接收端还有一个弱网对抗模块JitterBuffer,该模块为接收端缓冲区 ， 负责对数据包的丢失、延迟、乱序等情况进行处理 ， 配合NACK重传 ， 从而实现抗丢包 ， 降低弱网环境下的卡顿率 。
AVsync模块主要负责音画同步 ， 保证音视频通话的体验 。
针对教育场景的特殊优化
第一 ， 优先拉“老师流”策略
教育场景下无论大班课还是小班课 ， 学生上课的时候最关心的肯定是老师的流 ， 其他学生的动作 ， 学生本人不关心或者关心程度很低 ， 所以 ， 老师的那路流需要重点保障 。
文章图片
优先拉老师流的架构如上图所示 ， 为了作为对比 ， 我们先说一下之前没有优先拉老师流策略的架构 ， 右侧这个多路媒体资源控制器是没有的 ， 因此每一路流都是独立的 ， N路流的带宽评估是独立评估 ， 当学生端的带宽资源有瓶颈时很难保障学生拉所有流都不卡 。
有了统一带宽评估策略 ， 把多路流消化的带宽做统一评估 ， 从流1到流N所有消耗的带宽 ， 由右侧这个多路媒体资源控制器去做统一评估 ， 得出接收端带宽资源最大能够拉多大码率的流 ， 如果带宽不足以拉所有流的话 ， 就优先保障老师的流 ， 最大限度保障学生的上课体验 。
文章图片
第二 ， 推拉流的回退策略
在一些弱网的场景下 ， 学生要拉多方的流 ， 或者说即便只拉一方的流 ， 音频和视频两路流都要拉的话 ， 在极端弱网情况下是很难保障流畅性的 。 TalRTC的回退策略是当网络比较差的时候 ， 接收端的REMB负责带宽评估以后 ， 会将评估数据发送给流媒体服务器 ， 如果认为当前学生端的网络情况不能满足拉视频大流时 ， 会通知回退控制器 ， 回退控制器又通知转发过滤器 ， 先回退到只转发小流 ， 如果接收端的网络条件还是不满足拉视频小流 ， 再回退到纯音频 。
这样能够保障在极端弱网情况下 ， 学生即使不能流畅看老师的视频 ， 至少还能够听到老师的声音 ， 不会错过重要的知识点 ， 最大限度地保障了学生的上课质量 。
文章图片
第三 ， 基于AI的音频3A算法—AI_AEC 。
大家都知道 ， 音频前处理的3A算法是实时通信里很重要的一种技术 ， 音频3A算法保证了实时互动时的音频质量：语音清晰、没有噪音、没有回声、声音大小合适 。
然而 ， 传统的3A算法存在一些问题 ， 比如对对非线性回声消除不干净、对非平稳突发噪声抑制能力差 。 针对当前的业务痛点 ， 直播中台与集团AI研究院合作 ， 将AI算法与实时音视频的技术结合起来 ， 创新性的将AI算法用于音频3A优化中 ， 显著改善了传统音频3A算法的不足 。
文章图片
基于AI算法实现的噪声抑制 ， 目前主要支持一些特定场景的噪声抑制 ， 例如老师或者学生在家上课的时候 ， 环境中其他人发出的咳嗽声、开关门声、敲键盘声、或者临街环境有汽车鸣笛声等 ， 对于这类非平稳的突发的噪声用传统的降躁算法是很难消除干净的 ， 而基于特定场景训练的AI模型就能够彻底将噪声消除干净 。
好的 ， 今天的分享到此结束 ， 感谢大家的聆听；
推荐阅读
- 原神|《原神》「飞彩镌流年」2.4 版本预下载已开启
- 年轻人|呼叫全城玩家，魔都首发「表情包地铁」启程，2022蓝不倒！
- 外置|好消息！巨好用的国球汇限定·汇星3耀眼登场，限时送福利！
- 雷军|和雷军一起开箱，领取小米12「专属指南」
- 认识论|管理好时间，是最有价值的投资
- 曹志兴|90后教授曹志兴：最一流的基础科学来源于好奇心
- 处理器|AYANEO NEXT 掌机预热：拥有更好手感，探索掌机形体之美
- 趋势|2021生活家电好物盘点：舒适、智能、健康成趋势
- 细节|小米发布会上 15 分钟就讲完的 MIUI 13，好用么？
- 耳机|「以乐之名耀市而生」飞利浦Fidelio 降噪真无线耳机T1新品直播发布会圆满召开