奇葩说之RTC的那些事

LiveVideoStack 2020年11月17日


大家好,我是来自拍乐云的赵加雨。首先做个简单自我介绍,我2003年加入WebEx,在WebEx工作了14年,前面几年是在国内工作,后面几年在美国。在美国工作几年之后,发觉中国的环境也不错,于是在2017年回国加入了网易,任网易云信CTO,直到去年创立了拍乐云。大家可以看到,虽然我现在的头衔是CEO,但我过去的经历一直都是在做技术,现在在公司里和小伙伴们也会经常讨论技术,对技术也一直保留着很多热情。


本次分享是和我一直以来的工作经历和背景有关的视频会议,即RTC(Real time communication)相关的一个主题。今天这个题目还是挺特殊的,不知道大家有没有人喜欢看奇葩说,其实奇葩说里很多时候都是观点的碰撞,没有绝对的对或是错,但是通过辩论这样的方法,大家会得出自己的一个结论和输出,我觉得还是非常有意思的,今天演讲的题目也是借鉴了奇葩说。


RTC中涉及的点很多,如果很仔细地分享要花很多时间。那我今天想抛出6个问题来为大家拆解,我既当正方的辩手,也担当反方的辩手。通过拆解这6个问题,和大家做一个简单的分享。


最近几年,因为千播大战,包括线上业务的火热,很多公司开始进入RTC领域,这些公司对RTC技术有着各种各样的认知。采用的技术方案也有一些不同,在这里我列出了6个问题来和大家一起探讨。


200个节点 VS 十几个节点


第一个问题是关于网络节点问题。正方是200个节点,反方是10几个节点。大家认为哪种方法能够提供更好的服务呢?这是非常符合常识的一个认知,大家会觉得200个节点应该能够提供更好的服务。


WebEx:12 Data Centers

Zoom:18 Data Centers


实际来看,现在最火的视频会议公司就是Zoom了。当然在Zoom之前其实还有WebEx,即使现在它的市场占有率已经被Zoom超越,但WebEx现在每个月视频会议的分钟数仍有百亿分钟。所以说WebEx和Zoom都是服务于全球的视频会议公司,差不多覆盖200多个国家和地区,大家可以看到他们的数据中心,在网上有公开数据可以查到。WebEx在全球有12个数据中心,Zoom在全球是18个数据中心。这个有点反常识对吧。那按照道理,200多个节点应该能够提供更好的一个服务,那为什么WebEx和Zoom他们都只有十几个数据中心呢,这是怎么回事?是WebEx和Zoom他们没有钱吗?那肯定不是。Zoom现在是市值1500亿美金的公司了,WebEx现在属于思科,思科也是市值1600亿美金的公司。那这个问题就一定不是由于成本的原因。


因为这两家视频会议的领导者,他们自己在提供视频会议这个服务的过程当中,这是他们总结出来的最高效的方案。通过十几个数据中心和网络层的基建,可以给用户提供非常好的全球网络覆盖。这是这两家视频会议的领导者,做出来的技术上的最优选择。


那为什么会有一些厂商会说他们有200多个节点,甚至有的会说自己有300多个节点,那为什么他们会选择部署这么多的节点呢?可能的一个原因就是大家的技术方案、技术选型是不一样的。


很多RTC厂商的网络分发参考了CDN技术,CDN的做法是通过小城市的边缘机房来做客户的接入,再通过向中心机房的汇聚来实现跨网的问题。我们知道CDN服务于文件下载、视频点播和直播这样的应用,这些都是时延不那么敏感的,分发路径上经过了多个节点所带来的时延损耗并不会影响用户体验,CDN技术是一种低成本的用于大规模数据分发的技术方案。这样的分发方式对于RTC未必是最优选择。


要构建一张全球音视频分发大网,问题的关键其实不在于多少个节点,多并不等于好,关键在于是否解决了音视频全球分发的这些问题:各国出口带宽受限问题、防火墙问题,各个运营商互联互通问题,网络路由变化导致的Jitter问题,链路的灵活调度,等等。


时延越低越好吗?


第二个问题,时延越低就越好吗?那这个问题的答案似乎也是显而易见的,我们在做RTC的应用时肯定是希望时延越低越好的。但是这其中存在着一个误区,如果我们单纯强调时延,其实可能会导致技术方案变形。我们在做RTC的应用时知道,如果时延超过400毫秒,用户在通话的过程中就会有感知。因此要保证时延低于400毫秒,最好是在200毫秒以内,这样整体效果会比较好。但是如果说150毫秒跟120毫秒有没有太多区别?从用户体验角度来说可能并没有太大的区别。


凡事皆有正反面,在音视频应用里为了保证流畅度,往往需要通过数据包缓冲区来抵抗丢包提升流畅,如果一味的追求低时延,而压缩数据包缓冲区大小,很可能会导致更容易出现卡顿。因此,追求低时延是合理的,但是不应该通过牺牲流畅来过分追求低时延。当然,有些场景确实需要更低的时延才能保证用户体验,譬如线上合唱,此时追求极致的低时延是合理的。


数据白板 VS 视频白板


第三个点,大家在做白板的过程中,我们实现白板有两种方式,一种是数据白板,一种是视频白板。大家如果有用过视频会议软件的话,多数视频会议软件是用视频白板的方式在做。当然视频白板和数据白板这两种做法其实各有优劣,从技术角度来说,视频白板和共享是类似的技术,通过一个方案来解决了共享和白板的问题,这样技术的包袱会更轻,维护的成本也会更低一些。但是我们假设在某些对于白板有强需求的这些场景,包括教育这个场景,可能视频白板的体验就没办法做到非常好。其实很多时候数据白板可能是一个更好的解决方法,数据白板带来的好处也是显而易见的。白板本质上其实是一个多人的轨迹同步,它是多人的消息的同步,再加上客户端的绘制。如果通过数据白板的方式来做的话,可以实现更少的数据量,占用的带宽也会更少,这样的话就可以保证自己更不容易卡顿,另外也可以把更多的带宽留给音视频。因为我们在做白板的时候,同时可能也会有音视频的通讯。


另外,数据白板的呈现会非常高清。因为是矢量数据,所以说不管是很小的一个窗口,还是很大的窗口,即使缩放到很大,白板的清晰度还是非常好。所以在具体的实现过程当中,从用户体验的角度我们认为数据白板可能是一个更好的实现方式。


1080P比720P体验更好吗?


第四个问题,1080P可以提供比720P更好的体验吗?这个听上去似乎也是显而易见的,1080P分辨率更高,当然比720P体验更好了。但是在RTC场景下,答案可能并没有那么显而易见。


首先要解释一下,视频分辨率并不等于清晰度,视频清晰度取决于分辨率、码率、帧率等,三者对清晰度的影响大致可以参考公式Bits/(Pixel*Frame),简单点说,相同码率下,分辨率越高清晰度越低,分辨率越低清晰度越高。当然实际情况稍微复杂一点,在码率一定的情况下,分辨率在一定范围内取值都将是清晰的;同样地,在分辨率一定的情况下,码率在一定范围内取值都将是清晰的。因此,如果码率不够,1080P的清晰度很可能比720P更差。


其次,对于目前的移动互联网应用来说,手机端的屏幕尺寸有限,多数情况下360P就够了,一般来说720P足够了,完全不需要1080P。


我们在做视频会议应用时,有一个原则叫够用就好,当手机只需要720P的视频时,如果我们发送1080P的视频,需要的码率更大,此时并不能带来更高清的体验,反而会带来副作用,因为更高的码率会更容易出现卡顿,也更加消耗手机CPU。同理,如果180P就可以满足需要,我们就应该发送180P的视频,而不是720P的视频。


我们借鉴视频会议经验支持了视频大小流,客户端可以按需选择大流或者小流,在同一个会议里,也支持部分人选择大流部分人选择小流,保证最优的视频体验。


AVC VS SVC


第五点是AVC vs SVC。我们现在主流使用的视频标准其实还是H264。在H264里面分为两种,一种就是AVC,另外一个是SVC。大家知道SVC是分层编码,它可以提供时域、空域、质量域的分层,听起来是非常好的编码手段,因为通过分层,如果带宽很好或者端的设备很好,可以首先接收base layer,接收到base layer之后,可以再接收上面的一些增强的layer。而通过增强的layer就可以实现更高清的画质或者更高的帧率。这样对于视频的分发来说,你的手段就会更多。如果接收端的带宽受限或者接收端的设备本身性能很差,那这个时候可能只要选择接受base layer就可以了,这样可以保证一个比较流畅的视频体验。从技术角度来说,SVC好像是比AVC更先进的技术,但是实际上我们在选择的过程当中,这里没有标准的答案,只是我们在选择时需要慎重。


比如选择AVC,就要知道AVC的优缺点;选择SVC,就要知道SVC的优缺点。SVC从技术角度来说更先进,可以帮助我们实现更好的视频的分发。但是SVC带来的一个副作用就是在编码的时候占用的资源会更多,可能会更耗电或者某些设备支撑起来可能CPU消耗会更高。所以这两个选择没有对错,可能要在对应的场景根据需要去选择。


H265 VS H264


第六个点跟技术不那么相关了,只是和大家做一个简单的分享。我们知道最近H266也已经定稿了,关于H265,从视频标准角度来说领先了H264一代,是更好的视频标准。但是实际上现在H265涉及专利问题。H265现在已知的就有三个专利池,而且还有一些专利的拥有者,他们是不在这三个专利池里面的。所以采用H265会面临专利问题。如果你们的业务在发展壮大的过程中,将来真的能够做大或者做到国际化的话,可能就会面临专利的风险。如果你做的很好,做到像Zoom一样的全球化大公司,那就更不应该采用H265,因为这里面有很多专利的坑。


H266在试图解决这些问题,它在定标准和选择工具的时候,也都跟对应的专利拥有者做了沟通,试图解决这样的问题。所以我们也期待H266能够把专利问题解决好,因为H264毕竟是在2003年就已经定稿的标准,经过这么多年的发展,其实H264在很多方面,比如更大的分辨率、视频的压缩方面已经需要被改进了,希望新一代的视频标准,譬如H266、AV1等,能在提供更好视频压缩的情况下也能解决好专利问题。


RTC是时延、流畅、质量、成本等的平衡


因为RTC的应用涉及到的点会比较多,我们刚才通过6个点的分享,大家可以看到RTC本质上是一个时延、流畅、质量、成本几个点的平衡,没有一个银弹能够解决所有的问题。RTC应用本质上就是在一个受限的环境下,去平衡各种选择并尽量呈现最好的音视频体验给到用户。


在所有这些受限的资源里面,我们既想保证时延,又想给用户非常流畅的体验,同时也希望能够尽量让客户看到更好的视频、音频质量,最终还要需要兼顾成本,否则这样的商业模型也不成立。所以我们需要在这些关键点里做平衡,同时在这些受限的资源里面,我们希望找到最低的时延,最流畅的音视频和最高的画质,以及最低的成本,这里其实就是在做各个维度的选择。我们在做RTC应用的时候,不应该一味地追求一些点,不应该在某些单点上用力过猛,导致最终的效果会打很多折扣。


其实大家可以思考一下Zoom,Zoom现在是非常炙手可热的一个公司。他的产品大家可以去体验一下,Zoom从来不会宣传自己的时延很低,也不会宣传自己的画质非常高,但是最终呈现给用户的体验是非常好的。去年我们创立拍乐云也是出于一样的思考,我们觉得,RTC涉及到的点很多,包括算法、工程、网络等等,客户仍然需要一个90分以上的RTC产品,作为一群视频会议的老兵,我们希望将最好的视频会议技术封装成简单易集成的SDK给到客户,这也是我自己做了快20年的技术,然后转过头来创立拍乐云这样一个公司的原因。


还可输入800
全部评论
作者介绍

赵加雨

拍乐云

创始人&CEO

文章

粉丝

视频

阅读排行
  • 2周
  • 4周
  • 16周
热门视频

WebRTC视频数据流程分析

许建林/《WebRTC Native开发实战》书籍作者