RTC本质上是一个时延、流畅、质量、成本等几个点的平衡，我们不能在某些单点上用力过猛，导致最终的效果大打折扣。拍乐云CEO 赵加雨在LiveVideoStackCon 2020北京站的演讲中抛出关于RTC的六个问题，同时站在辩论的正反方与大家拆解如何能够让RTC产品给用户带来更好的体验。
WebEx：12 Data Centers
Zoom：18 Data Centers
第二个问题，时延越低就越好吗？那这个问题的答案似乎也是显而易见的，我们在做RTC的应用时肯定是希望时延越低越好的。但是这其中存在着一个误区，如果我们单纯强调时延，其实可能会导致技术方案变形。我们在做RTC的应用时知道，如果时延超过400毫秒，用户在通话的过程中就会有感知。因此要保证时延低于400毫秒，最好是在200毫秒以内，这样整体效果会比较好。但是如果说150毫秒跟120毫秒有没有太多区别？从用户体验角度来说可能并没有太大的区别。
凡事皆有正反面，在音视频应用里为了保证流畅度，往往需要通过数据包缓冲区来抵抗丢包提升流畅，如果一味的追求低时延，而压缩数据包缓冲区大小，很可能会导致更容易出现卡顿。因此，追求低时延是合理的，但是不应该通过牺牲流畅来过分追求低时延。当然，有些场景确实需要更低的时延才能保证用户体验，譬如线上合唱，此时追求极致的低时延是合理的。
另外，数据白板的呈现会非常高清。因为是矢量数据，所以说不管是很小的一个窗口，还是很大的窗口，即使缩放到很大，白板的清晰度还是非常好。所以在具体的实现过程当中，从用户体验的角度我们认为数据白板可能是一个更好的实现方式。
第四个问题，1080P可以提供比720P更好的体验吗？这个听上去似乎也是显而易见的，1080P分辨率更高，当然比720P体验更好了。但是在RTC场景下，答案可能并没有那么显而易见。
首先要解释一下，视频分辨率并不等于清晰度，视频清晰度取决于分辨率、码率、帧率等，三者对清晰度的影响大致可以参考公式Bits/(Pixel*Frame)，简单点说，相同码率下，分辨率越高清晰度越低，分辨率越低清晰度越高。当然实际情况稍微复杂一点，在码率一定的情况下，分辨率在一定范围内取值都将是清晰的；同样地，在分辨率一定的情况下，码率在一定范围内取值都将是清晰的。因此，如果码率不够，1080P的清晰度很可能比720P更差。
其次，对于目前的移动互联网应用来说，手机端的屏幕尺寸有限，多数情况下360P就够了，一般来说720P足够了，完全不需要1080P。
我们在做视频会议应用时，有一个原则叫够用就好，当手机只需要720P的视频时，如果我们发送1080P的视频，需要的码率更大，此时并不能带来更高清的体验，反而会带来副作用，因为更高的码率会更容易出现卡顿，也更加消耗手机CPU。同理，如果180P就可以满足需要，我们就应该发送180P的视频，而不是720P的视频。
我们借鉴视频会议经验支持了视频大小流，客户端可以按需选择大流或者小流，在同一个会议里，也支持部分人选择大流部分人选择小流，保证最优的视频体验。
第五点是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消耗会更高。所以这两个选择没有对错，可能要在对应的场景根据需要去选择。
第六个点跟技术不那么相关了，只是和大家做一个简单的分享。我们知道最近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年的技术，然后转过头来创立拍乐云这样一个公司的原因。
本文分享自微信公众号 - LiveVideoStack（livevideostack）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
