0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內(nèi)不再提示

關于RTC的六個問題

LiveVideoStack ? 來源:LiveVideoStack ? 作者:LiveVideoStack ? 2020-12-07 14:02 ? 次閱讀

RTC本質(zhì)上是一個時延、流暢、質(zhì)量、成本等幾個點的平衡,我們不能在某些單點上用力過猛,導致最終的效果大打折扣。拍樂云CEO 趙加雨在LiveVideoStackCon 2020北京站的演講中拋出關于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)歷一直都是在做技術,現(xiàn)在在公司里和小伙伴們也會經(jīng)常討論技術,對技術也一直保留著很多熱情。

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

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

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

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

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

WebEx:12 Data Centers

Zoom:18 Data Centers

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

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

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

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

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

2時延越低越好嗎?

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

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

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

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

其實很多時候數(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),簡單點說,相同碼率下,分辨率越高清晰度越低,分辨率越低清晰度越高。當然實際情況稍微復雜一點,在碼率一定的情況下,分辨率在一定范圍內(nèi)取值都將是清晰的;同樣地,在分辨率一定的情況下,碼率在一定范圍內(nèi)取值都將是清晰的。因此,如果碼率不夠,1080P的清晰度很可能比720P更差。

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

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

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

5AVC VS SVC

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

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

6H265 VS H264

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

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

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

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

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

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

責任編輯:lq

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 視頻
    +關注

    關注

    6

    文章

    1930

    瀏覽量

    72778
  • 數(shù)據(jù)中心

    關注

    16

    文章

    4644

    瀏覽量

    71906
  • RTC
    RTC
    +關注

    關注

    2

    文章

    524

    瀏覽量

    66242

原文標題:奇葩說之RTC的那些事

文章出處:【微信號:livevideostack,微信公眾號:LiveVideoStack】歡迎添加關注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關推薦

    無刷直流電機控制器六個功率管如何控制120度和60度的?

    無刷直流電機(BLDC)控制器中的六個功率管在控制120度和60度換相時,扮演著至關重要的角色。這兩種控制方式主要區(qū)別在于換相時功率管的開關序列和時序,以及它們?nèi)绾闻c霍爾傳感器的輸出信號相配合。以下
    的頭像 發(fā)表于 09-03 10:32 ?589次閱讀

    什么是RTC模塊?

    什么是“RTC”?“RTC”是實時時鐘的縮寫,它是一種測量時間的電子設備。什么是“RTC模塊”?“RTC模塊”是一集成了RTCIC、振蕩器
    的頭像 發(fā)表于 07-24 14:14 ?336次閱讀
    什么是<b class='flag-5'>RTC</b>模塊?

    如何創(chuàng)建具有不同占空比(但相同起始相位)的一或多個額外的PWM輸出?

    我實際上只需要一PWM(一頻率),但有五甚至六個輸出,具有六個不同的占空比。 是否有關于P
    發(fā)表于 07-08 07:09

    esp32c3的rtc gpio不足怎么解決?

    關于esp32c3,我看io0-io3不建議使用,那么rtc gpio 就只有io4和io5了,但我需要用2rtc io和一有adc功能
    發(fā)表于 06-18 06:38

    RTC和CPU有什么關系

    在現(xiàn)代計算機系統(tǒng)中,實時時鐘(RTC, Real-Time Clock)和中央處理單元(CPU, Central Processing Unit)是兩至關重要的組成部分。它們各自承載著不同的功能
    的頭像 發(fā)表于 05-30 17:07 ?538次閱讀

    如果有六個獨立的PWM通道都需要測量ADC,是不是單片的STM32H7不夠用?

    大家好, STM32H7 系列中 由三ADC, 每個ADC的轉(zhuǎn)換可以由 PWM Timer 觸發(fā)轉(zhuǎn)換。我的問題是,如果有六個獨立的PWM 通道都需要 測量ADC,是不是單片的 STM32H7 不夠用 (我的理解是,單個ADC只能設置一
    發(fā)表于 04-18 07:49

    具有六個200mA通道的TPS92391升壓/SEPIC 高調(diào)光性能LED驅(qū)動器數(shù)據(jù)表

    電子發(fā)燒友網(wǎng)站提供《具有六個200mA通道的TPS92391升壓/SEPIC 高調(diào)光性能LED驅(qū)動器數(shù)據(jù)表.pdf》資料免費下載
    發(fā)表于 04-01 16:13 ?0次下載
    具有<b class='flag-5'>六個</b>200mA通道的TPS92391升壓/SEPIC 高調(diào)光性能LED驅(qū)動器數(shù)據(jù)表

    RTC電池壽命的評估考慮因素

    本案例是一RTC功能的工業(yè)產(chǎn)品,RTC部分的供電電路如下下圖,產(chǎn)品發(fā)往市場半年以后,就提示更換RTC電池,遠遠低于設計壽命5年。
    發(fā)表于 03-15 10:29 ?551次閱讀
    <b class='flag-5'>RTC</b>電池壽命的評估考慮因素

    英偉達崩了!一天跌了3中芯國際!

    在連漲六個交易日、累計漲幅超過19%之后,英偉達股價終于崩了,出現(xiàn)9月以來的最大單日跌幅。
    的頭像 發(fā)表于 03-11 09:43 ?520次閱讀
    英偉達崩了!一天跌了3<b class='flag-5'>個</b>中芯國際!

    蘋果股價連跌 蘋果最新市值

    近期,蘋果公司的股價走勢引發(fā)了市場的廣泛擔憂。在短短六個交易日內(nèi),其市值驚人地蒸發(fā)了超過2000億美元,這一數(shù)字令人咋舌。
    的頭像 發(fā)表于 03-07 15:46 ?549次閱讀

    求助,關于pSoC6 RTC實時時鐘復位后的狀態(tài)問題求解

    請教一關于rtc的問題。psoc6在有bootloader和app兩程序的情況下。bootload沒有對rtc進行初始化配置。app對于
    發(fā)表于 02-18 08:34

    求助,請教一關于RTC中斷的問題

    是這樣的,我的硬件是外部接了12M晶振,以及RTC時鐘的兩引腳接了32.768K的晶振,用官網(wǎng)的RTC例程測試,時鐘和中斷都可以。我用了我們之前新唐供應商給的庫程序,時鐘顯示跟實際時間比較,顯示
    發(fā)表于 01-16 07:37

    RTC第二功能和應用程序

    一般RTC模塊設備管理時間日歷、計時器等。從年到二。一些愛普生RTC模塊可以通過使用來自32768 Hz的分割頻率來管理次第二功能。本文件描述了RTC模塊的三具體的應用程序。(表1)
    發(fā)表于 01-03 15:45 ?0次下載

    ADXL1001六個引腳,是VDD GND接電源,然后ST STB也要接地Vout才會有正確的輸出結(jié)果?

    這個評估版共六個引腳,是VDD GND接電源,然后ST STB也要接地,Vout才會有正確的輸出結(jié)果嗎
    發(fā)表于 12-28 08:10

    六個提升網(wǎng)站開發(fā)效率秘訣,最后一華為云產(chǎn)品絕對值得收藏

    網(wǎng)站訪問速度緩慢,用戶體驗下降,不僅會影響到用戶對企業(yè)的印象和信任度,也會降低網(wǎng)站的轉(zhuǎn)化率和競爭力。下面介紹六個技巧,幫助企業(yè)網(wǎng)站制作提高訪問速度,提高用戶體驗,提高網(wǎng)站轉(zhuǎn)化率和競爭力。 壓縮網(wǎng)頁和縮小圖片
    的頭像 發(fā)表于 11-23 00:56 ?169次閱讀
    <b class='flag-5'>六個</b>提升網(wǎng)站開發(fā)效率秘訣,最后一<b class='flag-5'>個</b>華為云產(chǎn)品絕對值得收藏