關(guān)于RTC的六個問題

RTC本質(zhì)上是一個時延、流暢、質(zhì)量、成本等幾個點的平衡，我們不能在某些單點上用力過猛，導(dǎo)致最終的效果大打折扣。拍樂云CEO 趙加雨在LiveVideoStackCon 2020北京站的演講中拋出關(guān)于RTC的六個問題，同時站在辯論的正反方與大家拆解如何能夠讓RTC產(chǎn)品給用戶帶來更好的體驗。

大家好，我是來自拍樂云的趙加雨。首先做個簡單的自我介紹，我2003年加入WebEx，在WebEx工作了14年，前面幾年是在國內(nèi)工作，后面幾年在美國。在美國工作幾年之后，發(fā)覺中國的環(huán)境也不錯，于是在2017年回國加入了網(wǎng)易，任網(wǎng)易云信CTO，直到去年創(chuàng)立了拍樂云。大家可以看到，雖然我現(xiàn)在的頭銜是CEO，但我過去的經(jīng)歷一直都是在做技術(shù)，現(xiàn)在在公司里和小伙伴們也會經(jīng)常討論技術(shù)，對技術(shù)也一直保留著很多熱情。

本次分享是和我一直以來的工作經(jīng)歷和背景有關(guān)的視頻會議，即RTC（Real time communication）相關(guān)的一個主題。今天這個題目還是挺特殊的，不知道大家有沒有人喜歡看奇葩說，其實奇葩說里很多時候都是觀點的碰撞，沒有絕對的對或是錯，但是通過辯論這樣的方法，大家會得出自己的一個結(jié)論和輸出，我覺得還是非常有意思的，今天演講的題目也是借鑒了奇葩說。

RTC中涉及的點很多，如果很仔細地分享要花很多時間。那我今天想拋出6個問題來為大家拆解，我既當正方的辯手，也擔(dān)當反方的辯手。通過拆解這6個問題，和大家做一個簡單的分享。

最近幾年，因為千播大戰(zhàn)，包括線上業(yè)務(wù)的火熱，很多公司開始進入RTC領(lǐng)域，這些公司對RTC技術(shù)有著各種各樣的認知。采用的技術(shù)方案也有一些不同，在這里我列出了6個問題來和大家一起探討。

1200個節(jié)點 VS 十幾個節(jié)點

第一個問題是關(guān)于網(wǎng)絡(luò)節(jié)點問題。正方是200個節(jié)點，反方是10幾個節(jié)點。大家認為哪種方法能夠提供更好的服務(wù)呢？這是非常符合常識的一個認知，大家會覺得200個節(jié)點應(yīng)該能夠提供更好的服務(wù)。

WebEx：12 Data Centers

Zoom：18 Data Centers

實際來看，現(xiàn)在最火的視頻會議公司就是Zoom了。當然在Zoom之前其實還有WebEx，即使現(xiàn)在它的市場占有率已經(jīng)被Zoom超越，但WebEx現(xiàn)在每個月視頻會議的分鐘數(shù)仍有百億分鐘。所以說WebEx和Zoom都是服務(wù)于全球的視頻會議公司，差不多覆蓋200多個國家和地區(qū)，大家可以看到他們的數(shù)據(jù)中心，在網(wǎng)上有公開數(shù)據(jù)可以查到。WebEx在全球有12個數(shù)據(jù)中心，Zoom在全球是18個數(shù)據(jù)中心。這個有點反常識對吧。那按照道理，200多個節(jié)點應(yīng)該能夠提供更好的一個服務(wù)，那為什么WebEx和Zoom他們都只有十幾個數(shù)據(jù)中心呢，這是怎么回事？是WebEx和Zoom他們沒有錢嗎？那肯定不是。Zoom現(xiàn)在是市值1500億美金的公司了，WebEx現(xiàn)在屬于思科，思科也是市值1600億美金的公司。那這個問題就一定不是由于成本的原因。

因為這兩家視頻會議的領(lǐng)導(dǎo)者，他們自己在提供視頻會議這個服務(wù)的過程當中，這是他們總結(jié)出來的最高效的方案。通過十幾個數(shù)據(jù)中心和網(wǎng)絡(luò)層的基建，可以給用戶提供非常好的全球網(wǎng)絡(luò)覆蓋。這是這兩家視頻會議的領(lǐng)導(dǎo)者，做出來的技術(shù)上的最優(yōu)選擇。

那為什么會有一些廠商會說他們有200多個節(jié)點，甚至有的會說自己有300多個節(jié)點，那為什么他們會選擇部署這么多的節(jié)點呢？可能的一個原因就是大家的技術(shù)方案、技術(shù)選型是不一樣的。

很多RTC廠商的網(wǎng)絡(luò)分發(fā)參考了CDN技術(shù)，CDN的做法是通過小城市的邊緣機房來做客戶的接入，再通過向中心機房的匯聚來實現(xiàn)跨網(wǎng)的問題。我們知道CDN服務(wù)于文件下載、視頻點播和直播這樣的應(yīng)用，這些都是時延不那么敏感的，分發(fā)路徑上經(jīng)過了多個節(jié)點所帶來的時延損耗并不會影響用戶體驗，CDN技術(shù)是一種低成本的用于大規(guī)模數(shù)據(jù)分發(fā)的技術(shù)方案。這樣的分發(fā)方式對于RTC未必是最優(yōu)選擇。

要構(gòu)建一張全球音視頻分發(fā)大網(wǎng)，問題的關(guān)鍵其實不在于多少個節(jié)點，多并不等于好，關(guān)鍵在于是否解決了音視頻全球分發(fā)的這些問題：各國出口帶寬受限問題、防火墻問題，各個運營商互聯(lián)互通問題，網(wǎng)絡(luò)路由變化導(dǎo)致的Jitter問題，鏈路的靈活調(diào)度，等等。

2時延越低越好嗎？

第二個問題，時延越低就越好嗎？那這個問題的答案似乎也是顯而易見的，我們在做RTC的應(yīng)用時肯定是希望時延越低越好的。但是這其中存在著一個誤區(qū)，如果我們單純強調(diào)時延，其實可能會導(dǎo)致技術(shù)方案變形。我們在做RTC的應(yīng)用時知道，如果時延超過400毫秒，用戶在通話的過程中就會有感知。因此要保證時延低于400毫秒，最好是在200毫秒以內(nèi)，這樣整體效果會比較好。但是如果說150毫秒跟120毫秒有沒有太多區(qū)別？從用戶體驗角度來說可能并沒有太大的區(qū)別。

凡事皆有正反面，在音視頻應(yīng)用里為了保證流暢度，往往需要通過數(shù)據(jù)包緩沖區(qū)來抵抗丟包提升流暢，如果一味的追求低時延，而壓縮數(shù)據(jù)包緩沖區(qū)大小，很可能會導(dǎo)致更容易出現(xiàn)卡頓。因此，追求低時延是合理的，但是不應(yīng)該通過犧牲流暢來過分追求低時延。當然，有些場景確實需要更低的時延才能保證用戶體驗，譬如線上合唱，此時追求極致的低時延是合理的。

3數(shù)據(jù)白板 VS 視頻白板

第三個點，大家在做白板的過程中，我們實現(xiàn)白板有兩種方式，一種是數(shù)據(jù)白板，一種是視頻白板。大家如果有用過視頻會議軟件的話，多數(shù)視頻會議軟件是用視頻白板的方式在做。當然視頻白板和數(shù)據(jù)白板這兩種做法其實各有優(yōu)劣，從技術(shù)角度來說，視頻白板和共享是類似的技術(shù)，通過一個方案來解決了共享和白板的問題，這樣技術(shù)的包袱會更輕，維護的成本也會更低一些。但是我們假設(shè)在某些對于白板有強需求的這些場景，包括教育這個場景，可能視頻白板的體驗就沒辦法做到非常好。

其實很多時候數(shù)據(jù)白板可能是一個更好的解決方法，數(shù)據(jù)白板帶來的好處也是顯而易見的。白板本質(zhì)上其實是一個多人的軌跡同步，它是多人的消息的同步，再加上客戶端的繪制。如果通過數(shù)據(jù)白板的方式來做的話，可以實現(xiàn)更少的數(shù)據(jù)量，占用的帶寬也會更少，這樣的話就可以保證自己更不容易卡頓，另外也可以把更多的帶寬留給音視頻。因為我們在做白板的時候，同時可能也會有音視頻的通訊。

另外，數(shù)據(jù)白板的呈現(xiàn)會非常高清。因為是矢量數(shù)據(jù)，所以說不管是很小的一個窗口，還是很大的窗口，即使縮放到很大，白板的清晰度還是非常好。所以在具體的實現(xiàn)過程當中，從用戶體驗的角度我們認為數(shù)據(jù)白板可能是一個更好的實現(xiàn)方式。

41080P比720P體驗更好嗎？

第四個問題，1080P可以提供比720P更好的體驗嗎？這個聽上去似乎也是顯而易見的，1080P分辨率更高，當然比720P體驗更好了。但是在RTC場景下，答案可能并沒有那么顯而易見。

首先要解釋一下，視頻分辨率并不等于清晰度，視頻清晰度取決于分辨率、碼率、幀率等，三者對清晰度的影響大致可以參考公式Bits/（Pixel*Frame），簡單點說，相同碼率下，分辨率越高清晰度越低，分辨率越低清晰度越高。當然實際情況稍微復(fù)雜一點，在碼率一定的情況下，分辨率在一定范圍內(nèi)取值都將是清晰的；同樣地，在分辨率一定的情況下，碼率在一定范圍內(nèi)取值都將是清晰的。因此，如果碼率不夠，1080P的清晰度很可能比720P更差。

其次，對于目前的移動互聯(lián)網(wǎng)應(yīng)用來說，手機端的屏幕尺寸有限，多數(shù)情況下360P就夠了，一般來說720P足夠了，完全不需要1080P。

我們在做視頻會議應(yīng)用時，有一個原則叫夠用就好，當手機只需要720P的視頻時，如果我們發(fā)送1080P的視頻，需要的碼率更大，此時并不能帶來更高清的體驗，反而會帶來副作用，因為更高的碼率會更容易出現(xiàn)卡頓，也更加消耗手機CPU。同理，如果180P就可以滿足需要，我們就應(yīng)該發(fā)送180P的視頻，而不是720P的視頻。

我們借鑒視頻會議經(jīng)驗支持了視頻大小流，客戶端可以按需選擇大流或者小流，在同一個會議里，也支持部分人選擇大流部分人選擇小流，保證最優(yōu)的視頻體驗。

5AVC VS SVC

第五點是AVC vs SVC。我們現(xiàn)在主流使用的視頻標準其實還是H264。在H264里面分為兩種，一種就是AVC，另外一個是SVC。大家知道SVC是分層編碼，它可以提供時域、空域、質(zhì)量域的分層，聽起來是非常好的編碼手段，因為通過分層，如果帶寬很好或者端的設(shè)備很好，可以首先接收base layer，接收到base layer之后，可以再接收上面的一些增強的layer。而通過增強的layer就可以實現(xiàn)更高清的畫質(zhì)或者更高的幀率。這樣對于視頻的分發(fā)來說，你的手段就會更多。如果接收端的帶寬受限或者接收端的設(shè)備本身性能很差，那這個時候可能只要選擇接受base layer就可以了，這樣可以保證一個比較流暢的視頻體驗。從技術(shù)角度來說，SVC好像是比AVC更先進的技術(shù)，但是實際上我們在選擇的過程當中，這里沒有標準的答案，只是我們在選擇時需要慎重。

比如選擇AVC，就要知道AVC的優(yōu)缺點；選擇SVC，就要知道SVC的優(yōu)缺點。SVC從技術(shù)角度來說更先進，可以幫助我們實現(xiàn)更好的視頻的分發(fā)。但是SVC帶來的一個副作用就是在編碼的時候占用的資源會更多，可能會更耗電或者某些設(shè)備支撐起來可能CPU消耗會更高。所以這兩個選擇沒有對錯，可能要在對應(yīng)的場景根據(jù)需要去選擇。

6H265 VS H264

第六個點跟技術(shù)不那么相關(guān)了，只是和大家做一個簡單的分享。我們知道最近H266也已經(jīng)定稿了，關(guān)于H265，從視頻標準角度來說領(lǐng)先了H264一代，是更好的視頻標準。但是實際上現(xiàn)在H265涉及專利問題。H265現(xiàn)在已知的就有三個專利池，而且還有一些專利的擁有者，他們是不在這三個專利池里面的。所以采用H265會面臨專利問題。如果你們的業(yè)務(wù)在發(fā)展壯大的過程中，將來真的能夠做大或者做到國際化的話，可能就會面臨專利的風(fēng)險。如果你做的很好，做到像Zoom一樣的全球化大公司，那就更不應(yīng)該采用H265，因為這里面有很多專利的坑。

H266在試圖解決這些問題，它在定標準和選擇工具的時候，也都跟對應(yīng)的專利擁有者做了溝通，試圖解決這樣的問題。所以我們也期待H266能夠把專利問題解決好，因為H264畢竟是在2003年就已經(jīng)定稿的標準，經(jīng)過這么多年的發(fā)展，其實H264在很多方面，比如更大的分辨率、視頻的壓縮方面已經(jīng)需要被改進了，希望新一代的視頻標準，譬如H266、AV1等，能在提供更好視頻壓縮的情況下也能解決好專利問題。

RTC是時延、流暢、質(zhì)量、成本等的平衡

因為RTC的應(yīng)用涉及到的點會比較多，我們剛才通過6個點的分享，大家可以看到RTC本質(zhì)上是一個時延、流暢、質(zhì)量、成本幾個點的平衡，沒有一個銀彈能夠解決所有的問題。RTC應(yīng)用本質(zhì)上就是在一個受限的環(huán)境下，去平衡各種選擇并盡量呈現(xiàn)最好的音視頻體驗給到用戶。

在所有這些受限的資源里面，我們既想保證時延，又想給用戶非常流暢的體驗，同時也希望能夠盡量讓客戶看到更好的視頻、音頻質(zhì)量，最終還要需要兼顧成本，否則這樣的商業(yè)模型也不成立。所以我們需要在這些關(guān)鍵點里做平衡，同時在這些受限的資源里面，我們希望找到最低的時延，最流暢的音視頻和最高的畫質(zhì)，以及最低的成本，這里其實就是在做各個維度的選擇。我們在做RTC應(yīng)用的時候，不應(yīng)該一味地追求一些點，不應(yīng)該在某些單點上用力過猛，導(dǎo)致最終的效果會打很多折扣。

其實大家可以思考一下Zoom，Zoom現(xiàn)在是非常炙手可熱的一個公司。他的產(chǎn)品大家可以去體驗一下，Zoom從來不會宣傳自己的時延很低，也不會宣傳自己的畫質(zhì)非常高，但是最終呈現(xiàn)給用戶的體驗是非常好的。去年我們創(chuàng)立拍樂云也是出于一樣的思考，我們覺得，RTC涉及到的點很多，包括算法、工程、網(wǎng)絡(luò)等等，客戶仍然需要一個90分以上的RTC產(chǎn)品，作為一群視頻會議的老兵，我們希望將最好的視頻會議技術(shù)封裝成簡單易集成的SDK給到客戶，這也是我自己做了快20年的技術(shù)，然后轉(zhuǎn)過頭來創(chuàng)立拍樂云這樣一個公司的原因。

責(zé)任編輯：lq