RTC是延时非常低的CDN服务,RTC在一对一或者一对几的通话已经是非常成熟的服务了,现在很多应用都已经这么做了。大家如果有这种场景的可以直接往上走,已经没有什么技术障碍了。

我们今天聊的场景是一个对几千、一个对几万,RTC到底靠谱不靠谱?简单的回答是“靠谱的”,虽然会有一些问题,但不会有特别大的障碍。

刚才的应用场景主要出现在大课上,CCtalk的应用场景支持成千上万人一起学习,比较典型的项目是“互加”,那是非常让人感动的项目,线上支持由最好的老师对边远山区的老师们培训。万人级别是几万人一起上课,延时都不会超过600-800毫秒。

为什么我们会有这个需求?CC是为了给知识传授 者搭建的平台和社区,我们支持的环节是比较多的:第一,网师服务,老师可以签入驻,得到最多的是教学工具,因为我们不只要支持音视频,这只是我们服务里最基础的一块,还有其他的课件、白板、激光笔等。为什么需要RTC技术去做万人的课?因为需要把音视频拿起来,跟数据匹配 ,这样上课体验是最好的。

回过头来 看下RTC的定义,我们聊的RTC是一种广义的RTC,WebRTC只是它的一种封装,并不限定 于WebRTC的模式。我们对时间的要求是400-800毫秒要求,才能达到实时通讯的规范。我们不限定这个应用在web上做,在客户端上同样要达到这个要求。

今天很多人聊WebRTC,但是我觉得WebRTC没有到完全可以商用的阶段,第一,浏览器兼容,第二,纯点对点的服务很难解决很多问题。绕过这些场景,大家自己建的服务有很多,包括声网是这个行业做得比较好的一家,腾讯云现在有类似的服务,网易云也有类似的服务。CCtalk有自己的一套实时音视频服务,但不对外,其他三家是对外的,让大家以SDK接入的形式来使用。

直播架构是怎么演进的?传统的直播架构大家都很清楚,通过RTMP或RTSP下发到观众这边,观众是纯单向在看,观众端没有办法反馈数据回来。后面有HLS跟MPEGDASH,它的问题在于切片掉了,有预切片,延时会更大, 3秒-6秒甚至更高。直播兴起有一块新东西在慢慢出来,就是HTTP FLV,很多网站直播时都在用它。

传统的RTC最简单的是这个模型,它只需要搭一个信令服务,可以传输信令通道,浏览器兼容的情况下就可以做最简单的P2P通讯,这是最基础的模型。逐渐往下走会发现问题,比如刚才雨润提到两边网络有不通的情况,传输性能不好,我们要提供99.9%甚至更高质量的服务,穿透防火墙,这套模型就做不好。只能在中间加一个STUN/TURN一个sever做中转。但是里面的问题是当参与人数变多时,输入跟输出的流数变多,上行和下行压力非常大。

Outgoing Bitrate = (N-1) * bitrate

Incoming Bitrate = (N-1) * bitrate

Computation Load : Low

如果加入一个人的话,发两条流出来,两个用户就基本不可维护了。再把人数加多一点,现在是5位,最大的问题是Alice没有办法给这5个人同时发消息,我们中间就要加一台SFU(路由),一般不会是一台,而是一组。Alice把数据丢给SFU,SFU帮Alice把数据丢给这5个人。它可以解决出口的问题,Alice只需要发一路流出来,但是进的流还是多路的,所以仍然有可能把服务压垮,导致服务质量不高。

Outgoing Bitrate = bitrate

Incoming Bitrate = (N-1) * bitrate

Computation Load : Low

技术再往后演进,一个SFU不行了,就开始加MCU。MCU是个重计算单元,把所有经流的流全部合并掉,音频全部到合到一起、视频全部合到一起。这时解决上行下行,所有人只要一条进一条出,这个会议就可以开了。会有一点多余延时,因为MCU中间要做转码,无法避免。MCU的方案还会引入第二个问题:计算量变大了。如果同时开的课程、频道多了之后,服务器就不太够用。

Outgoing Bitrate = bitrate

Incoming Bitrate = bitrate

Computation Load : High

还有一些特别非典型的用法,有些军方或者政府项目这么做,商用很好。把特定的人当作虚的SFU和MCU节点,通过它去做数据合成和转发 。好处是服务器就不需要了,相当于中心计算节点慢慢被虚拟的计算节点替代掉。出入只有一条流,计算压力仍然很高,但不在服务端,是在某些我们知道的能力比较强的客户端,这样也可以降低风险。

到当前,画的简单一点就是这样一个RTC的直播场景。中间有一层服务,比如声网把中间服务变成RTC cloud。它能解决的场景并不是1万个人都要贡献数据,而是这1万个人中有5-10个是在贡献、在上麦互动的,剩下大量的人在听这个课。输出对每个人来讲都是1路,输入的流就等于上麦的人数。如果用MCU,计算量就高一些,如果不用计算量其实就不高。这种方案的难度就集中在RTC Cloud上。接下来会重点说。

直播评估有一定的难度,因为它没有办法全部满足这三角,一个是latency延时,第二个是Scale,就是同时上课的人数,第三个是质量。这三个几乎没有办法平衡的。

传统的直播解决了Scale跟quality的问题,但牺牲了latency。延时可能要调到5秒、10秒甚至更长,没有办法做到实时交互。

传统的RTC可以做到这样,latency很低,但是做不了Scale和quality。Quality是与传输信道相关,信道好的话Quality可能会好一点。

在RTC大规模直播场景下,我们的目标还是为了解决Latency和Scale的问题。

RTC大规模所面临的问题有:1.大规模的人同时互动的问题,无法解决,其实也没有意义去解决。所有人同时说话,也听不清。的需求,只满足个别人互动,其他人实时收听。2。架构复杂度会高一点。3.对上行、下行稳定性要求高。4.协议可选择范围小,公有的就只有WebRTC,私有的就谈不上什么公有协议了。5.开发成本高、运维成本高、运营成本高。

下面说说RTC cloud技术里面临的问题,怎样让RTC适应这样大规模的实时交互场景。

第一种方法,优化反馈渠道,通过反馈驱动自适应。模型我们做的简单一些,有三个人Alice、Carol和Bob,中间有一个signaling渠道。听众的下行质量不一样,Bob的稍微好一点,Carol的差一些。此时,我们可以做的事就是这两个人的下行质量可以通过Signaling反馈给Alice,Alice这端调整自己的编码策略,通过自适应码率的策略,经过SFU/MCU发给听众。整个过程是观众里如果有一个下行质量差,可以反向干预输出者,从而让结果变得更可控。

这样做有有好处,也有坏处。好处是:多方协调可以降低系统风险,比如有些关键的人听不了这些课,他的信道又无法做调整。第二,计算分布化,云端计算复杂度低、压力小。但问题在于:如果特别考虑反馈因素,某个人的信道不好,整体的视频质量就会压得非常低,整体的会议体验不会特别好。第二个是,如果1万个人都在做数据贡献,此时你很难做决策,不大可能因为一个人的质量调整所有人的质量,此时这个策略是失效的。另外,它对编码器要求稍微高点,对码率精度要求很高。

第二种方法,做多条数据流。信道就是不好怎么办?我们在SFU或MCU加一个 transcoding module。流从Alice传过来之后,通过transcoding module变成多条不同清晰度的流,但实时这块这么会引入一个风险,在SFU这块会加大延时,计算压力会多一点。

它的好处是解决了用户下行速率不均等的问题,如果不同用户信道的质量不一样,这个方法是可以解决这样的问题的。同时也能降低卡顿率。但问题在于transcoding会消耗服务端性能,会大幅度拉高整体成本。

第三种方法,SVC。SVC的原理是在压缩码流时就创建了多个layer。观众Bob和Caro的信道质量不一样,可以让Alice去输出不同的layer,中间服务器有SVC stream extractor ,观众可以按层的不同信息取不同码率的流。Alice那边的编码压力不会增加特别大,但是在SVC之后层的选择上有一定的复杂度和计算压力。

大家对SVC不了解,我稍微介绍下这个标准的背景,这是2007-2010年那段时间定出来的。SVC的标准是编一路流,但是可以把这一路流拆成不同质量、时域、空域的流。比如编一路流,可以拆成128kbps帧率很低的流,也可以拆出1024kbps帧率60的流。但它的编码复杂度和带宽消耗不一定会有两个流加起来那么大。

这个方案的好处是转码环节省掉了,性能消耗没有那么高,RTC成本提升不是很大。坏处是SVC作为标准一直没有被电子级、消费级广泛接受,在Native端都没有SVC解码器,所以所有东西都要靠软件实现,手机功耗高、耗电快。

前面都是解决全实时场景的,如果不考虑全实时,把前面这些方案拆掉能不能解决问题?把进场和远场分开。有没有办法让上麦的人延时变低,但听的人延时变高?上麦的人通过SFU这一套方案解决延时,其他人通过SFU的RTMP转发到传统CDN上就好了。这个模型相对来说更简单,也很容易实现。

好处是解决了scale的问题,弱化了quality的问题。上麦用户latency低,高架构可控、稳定,大部分场景下效果可以接受,成本相对低。但是这套方案,上课不行。延时、互动不同步。

针对这个方案有些变种可以继续优化,在Playback Speed Control这条路回来的信令流,不一定是实时的,可以加一个速率控制。我们可以知道视频的延时有多少,在把延时加回给信令的播放时长,这个问题也就解决掉了,这是相对直白的解法。

好处是现在可以上课了,成本也比较低,软件适配了。坏处是不公平,一个课程环境里,有些人永远抢答不到,因为他收到数据比别人晚几秒,这些人永远比别人慢一拍,这是教育公平性的缺失。

编码算法上也有一些讲究。一般来讲,编码输出的适合会有VBR、CBR。VBR就意味着质量是恒定的,但是做VBR时会做一些local buffering之类的,造成延时高。CBR保证码率,质量可变不恒定,延时降低了但质量不会特别好。我们探索这个事情时发现CBR更适合上课场景。

另外一个环节是容错,RTC容错大方向有两个,一个是RUDP,一个是FEC。怎么去做选择?我们对这个事情的判断是:如果网络稳定、丢包低,FEC效果好一点。但是如果网络极不稳定,有可能FEC不能帮你,你需要大量的重传,RUDP好一点。

另一个环节是就是容错,RTC的两个大方向分别是:Reliable UDP(RUDP)和FEC。Wikipedia上关于RUDP的解释,比UDP多的就是,如果传输失败有重试,是一个相对有保证的UDP,可以保障传输质量,不会有太多质量问题。目前它还不是一个标准,但很多人都在用。FEC(向前纠错),是发送方将要发送的数据附加上一定的冗余纠错码一并发送,接收方则根据纠错码对数据进行差错检测。

那RUDP和FEC如何选择呢?因为FEC会在原本的流上加多余的字节,所以网络好时,使用FEC是亏的,多传了很多没用的数据。我们队这件事的看法是,如果网络稳定丢包低,FEC效果更好,因为丢的包少,拿一点点冗余数据就可以做补偿。如果网络极不稳的,比如4G、网吧,丢失的数据很多,FEC就可能没有办法修复,就要考RUDP大量的重传。所以,如何选择没有一个确切的答案,还是要根据不同的场景选择。

大规模场景下要不要做P2P?据我个人了解,业界没有成熟方案。在学术界有一些建议的,比如Facebook、 Google在子网中做P2P,在公网做RTP,这时可以削峰,作为服务提供商会省钱,服务质量也会高。但有一些适用性的问题,与用户的分布有关系。

今年我看到的最近的一个案例是,意大利的一个学校在做,这个图跟传统P2P方案比较接近,但是也跟用户的网络分布有一定关系。这都是一些可以想到的方法,但是在商用时有没有特别好的表现,这是不确定的。

大规模直播场景下另外一个痛点是怎么在H5下做直播。能做的是在SFU节点加一个节点把流合并,通过RTMP推流到CDN上。这是大家经常会做的事情。在H5端可以看到这路RTC的流,但它有一定的延时。

这是我们做的另外一块分析,直播这个事情电量消耗多大。视频对于功耗的消耗其实并没有那么高,video打开后,不管直播还是非直播状态,功耗都在2000毫安,所以直播或者视频消耗大概是700毫瓦 的情况。但如果聊天打开,对界面压力非常大,功耗会从从2400多毫瓦飚升到4000多。从功耗角度来讲,优化音视频的收益跟优化聊天的代价一样大,可能聊天更容易取得收获。

总结,要考虑业务场景,RTC支持大规模要看业务场景是否一定要这么做,技术上是可达的,但是有成本代价。另外,周边系统比较关键,要把监控做得非常好,其他应用场景需要业内更多同事一起挖掘。

RTC在大规模直播场景下的技术分析相关推荐

  1. 阿里技术分享:电商IM消息平台,在群聊、直播场景下的技术实践

    本文由淘宝消息业务团队李历岷(花名骨来)原创分享,首次发表于公众号"淘系技术",有修订和改动. 1.引言 本文来自淘宝消息业务团队的技术实践分享,分析了电商IM消息平台在非传统IM ...

  2. 优酷智能档在大型直播场景下的技术实践

    作者 | 阿里文娱高级技术专家 肖文良 本文为阿里文娱高级技术专家肖文良在[阿里文娱2019双11猫晚技术沙龙]中的演讲,主要内容为如何通过优酷智能档,降低用户卡顿尤其是双11直播场景下,提升用户观看 ...

  3. 一些秒杀以及抢红包场景下的技术分析

    一.首先来一个抢红包的案例: 抢红包的场景有点像秒杀,但是要比秒杀简单点. 因为秒杀通常要和库存相关.而抢红包则可以允许有些红包没有被抢到,因为发红包的人不会有损失,没抢完的钱再退回给发红包的人即可. ...

  4. 【视频直播场景下P2P对等网技术②】任意两节点的联通性能评估

    [视频直播场景下P2P对等网技术②]任意两节点的联通性能评估 如上文([视频直播场景下P2P对等网技术①])所述,当一个新的节点 F F F加入现有的网络 G G G的时候,若 m = ∣ V G ∣ ...

  5. 【视频直播场景下P2P对等网技术①】挑战与形式化分析

    [视频直播场景下P2P对等网技术①]挑战与形式化分析 我在熊猫直播亲自主持的最后一个项目,就是要试图通过P2P对等网技术来切实降低互联网视频直播的流量成本,对此有一些数据上&经验的积累和检验. ...

  6. 从CV到ML 直播场景下新技术的应用

    版权声明:本文为博主原创文章,未经博主允许不得转载. https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/82392646 本文来自花椒 ...

  7. 微博直播场景下,如何实现百万并发的答题互动系统

    内容来源:2018 年 09 月 07 日,新浪微博系统开发工程师陈浩在"RTC2018 实时互联网大会"进行<微博直播场景下百万并发的消息互动系统>演讲分享.IT 大 ...

  8. 不同直播场景的CDN技术简析

    随着直播行业的兴起,各种直播应用.平台和产品万花齐放,直播场景也越来越多元化,这就对视频技术的发展提出了"日新月异"的需求.那么,目前视频直播的场景主要有哪些?不同类型的直播场景对 ...

  9. 直播间挂人气技术分析【简易版本】

    直播间挂人气技术分析 现在很多直播间推出了网页版本的进入方法,这就给我们用来直播间刷人气带来了很大的便利. 场景分析如下,如果一个网页能独立登录一个id,那么多打开几个网页就能实现这个功能了.不比较成 ...

最新文章

  1. 固定旋转_旋转压片机如何正确更换冲模?
  2. Go语言开发者福利 - 国内版 The Go Playground
  3. python ide如何运行_如何在Ubuntu上安装IDLE Python IDE
  4. 这家剑桥校友创办的苏州AI独角兽,再获4.1亿投资,将在国内IPO
  5. python学习------文件处理
  6. 基于XML的AOP实现事务控制
  7. centos6安装mysql权限被拒绝_CentOS6.6安装mysql出现的问题
  8. 【明人不说暗话】我就只讲进程与线程
  9. COJ 1700:联通与次联通
  10. 1.7 对新序列采样
  11. 存储相关知识-DAS/SAN/NAS
  12. python编程特点_Python基础(1)--Python编程习惯与特点
  13. UIScrollView setContentOffset: animated:YES 偶尔卡顿解决方案
  14. 拖动获取元素_如何使用HTML5实现多个元素的拖放功能
  15. 麻省理工线性代数第三讲
  16. 网页中的QQ和阿里旺旺聊天图标
  17. DroidCam---将手机转为电脑外接摄像头的软件(提供下载链接)
  18. 配置FreeSWITCH支持不带媒体信息的SIP信令
  19. 中秋之际献上【中秋快乐】藏头诗
  20. 【SEO工具】国内外网站速度测试工具都有哪些

热门文章

  1. 阿里研究院第三届学术委员会成立,主席曾鸣畅谈未来学术生态构建
  2. 程序猿转型AI必须知道的几件事!
  3. 音频增强工具:DeskFX Plus Mac
  4. 嵌入式系统及应用——SOC分类
  5. 20155322秦诗茂 我的期望与我的老师
  6. Dijkstra,A*,DWA,TEB
  7. 视频-视频基础(H264)
  8. java递归算法经典实例_Java实现简单的递归操作方法实例
  9. 自己动手,搭建家庭文件、打印、影音服务器
  10. CKA真题 :2019年12月英文原题和分值