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

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

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

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

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

1200個節點 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問題，鏈路的靈活調度，等等。

2時延越低越好嗎？

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

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

3數據白板 VS 視頻白板

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

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

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

41080P比720P體驗更好嗎？

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

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

其次，對于目前的移動互聯網應用來說，手機端的屏幕尺寸有限，多數情況下360P就夠了，一般來說720P足夠了，完全不需要1080P。

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

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

5AVC 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消耗會更高。所以這兩個選擇沒有對錯，可能要在對應的場景根據需要去選擇。

6H265 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年的技術，然后轉過頭來創立拍樂云這樣一個公司的原因。

責任編輯：lq