0
近日，雷鋒網開啟了“教育新基建”系列公開課第二期，邀請了國內云計算第一股UCloud實時音視頻平臺負責人裴志偉做客線上課堂，他以《線下教育如何平穩地過渡到線上》為題進行分享。
裴志偉，UCloud實時通信平臺負責人。主要負責實時音視頻RTC產品研發，擁有近10年互聯網行業的研發經驗。2015年初加入UCloud，分別負責過云主機、云網關、帶寬和UFile對象存儲等產品，覆蓋云計算的計算、網絡、存儲是三大領域，對云計算行業有豐富的經驗。
此次主題分享分為四個部分：
1. 疫情對于在線教育的短期和長期影響
2. 在線課堂遇到的技術挑戰
3. 實時高清音視頻通話背后的關鍵技術解析
4. 案例解析：如何快速構建高質量的在線課堂
以下為裴志偉的課程分享的部分回顧，雷鋒網對其做了不改變原意的編輯整理：
大家好，我來自UCloud，然后現在是UCloud實時音視頻平臺負責人，我今天的話題是關于大規模的實時視頻互動場景下面帶來什么樣的挑戰，以及有哪些關鍵的技術點？
首先我們先看看疫情對泛直播，包括一些用點播錄播的方式來做的微直播，帶來的短期變化是怎樣的？那就是學習、生產、經營都要去尋找一個線上的替代方式。
疫情期間線上課程為什么會體驗不佳呢？我們上半年也聽到過很多吐槽的聲音，大家都是在吐槽體驗不好，有卡頓、掉線，有各種各樣的問題。
這里面其實分為三個層面，第一個是缺少一個良好的產品設計，因為我們大家知道我們平時用的產品都是有產品的迭代，收集需求并去打磨，但是疫情突發而至的時候，實際上是很難有個很快應對或者是去了解需求的過程。甚至某種程度上大家都是拼湊式用的，就是并沒有人單獨為我需要的一個場景去設計產品，所以第一個核心是缺少一個良好的產品的設計或者迭代。
那么第二點，其實是它的技術。
2004年為什么發生了一個很大的變化，在2004年的時候，互聯網的遠程辦公的底層技術成熟了。技術和需求是共同組織發展的，所以在2004年之后，在美國work from home的人的比例在逐漸提升，而且我相信這次疫情之后，2020年又是個大的轉折，那個曲線會更加陡。
其實社會一直有這樣的需求，但是過去可能沒有這樣的技術產品，需求就被壓抑了。
我們來看疫情帶來的長期影響，要看兩個方面，第一是社會需求，第二是技術底層技術的支撐能力。技術是否能夠匹配支撐這個需求？
現在我們大家經?？吹降氖潜热缯f教育的場景在做分級，醫院也在做分級診療，緩解看病難等，未來還會出現在遠程辦公中。
實時音視頻技術會隨著需求不斷去完善自己，推動生態的建設，比如說硬件芯片的升級、操作系統的適配、瀏覽器的適配，還有各種各樣的生態，比如微信。
還有就是5G的到來，實時音視頻是一個很大的爆點。大家都知道5G的優勢，如帶寬很大，延遲很低，支持更多各種多樣的設備去連接進入網絡。所以，實時音視頻可以更好地發揮5G的優勢，它可以去更好地利用低延遲、大帶寬去提供比如VR全息投影的方式等等，會產生蝴蝶效應。
有了這樣的技術之后，還要再看產品設計。我們在互聯網領域一直非常強調產品設計，系統架構設計要以用戶體驗為導向，我們最終是為了讓用戶有一個良好的體驗，而不是我自己做技術做得爽。
用戶的核心訴求其實就是不卡、不掉、延遲要盡可能低，低到什么程度呢？我們在網絡的兩端去做線上的一些生產經營活動的時候，要盡可能模擬到感覺跟線下似的。什么叫跟線下似的？兩個人面對面的在交流的時候，實際上沒有延遲的，我說話聲音的傳播速度很快，我立刻就能看到對方的反應，對方的表情，對方會立刻給我反饋。但如果我們延遲大于一秒，甚至很多傳統的語音通話延遲都在5秒以上，這幾乎是不可接受的。
用戶還有什么衍生需求？音質要足夠好、信息要做降噪。如果你我的周圍有風的聲音，或者是有一些電流聲、按鍵聲，其實這種確定性的聲音還是可以去做降噪的，但比如說如果我走在戶外，突然有一輛車鳴笛經過，現在的技術還是很難做到過濾掉這些噪聲。
最后一個很大的方面，把線下的場景完全搬到線上會有很多迭代的需求。比如說在線下可以使用一個黑板就可以做到直接去演示一個東西，當然現在可以通過屏幕分享，通過傳文件的方式等來實現。
結合這些需求來看，系統架構設計核心最核心的就是四點，高并發、高可靠、低延遲和抗弱網，你要把它當做一個平臺去設計，對接各種各樣的算法。如果你全自己做的話，這個系統是非常大非常復雜的，所以音視頻產品一定是平臺化、模塊化的。
這是我們自己產品的一個整體架構圖。
從下往上，第一部分是有個接入模塊，第二部分是有個信令模塊，第三部分是有個媒體模塊，把這三個東西打包成一個PaaS，PaaS的解決方案是以SDK的形式，它提供給用戶可以去調SDK的接口，用戶可以在不需要對音視頻設備有太多理解的情況下，就能把自己產品這塊的能力補齊。
大家可以看到這里面會用到會有非常多的網絡協議，比如說websocket協議、SRTP協議、RTP、HTTPS等等，其實它很復雜，就像類似于通訊里面會有有控制面、數據傳輸面等等。
上面就是我們常見的一些互聯網的技術架構了，首先你要有API網關去對接，去接受資源上的控制。中間要做交易隊列，數據管理中心、媒體處理中心、注冊中心和調度中心等等?；A服務主要是對這些資源，還有實現周邊的訪問控制系統，然后server實現控制和傳輸的中繼。
接下來這個技術在整個直播和視頻領域里面最核心的一個模塊叫做抖動緩沖。這個模塊是干嘛的呢？我們看下面的這張圖，它實際上是音視頻整個全部的過程。
從端上的采集到編碼，包括中間還有預處理，把它去做封包，然后進入網絡去發送。到對單的時候要經過接收和組幀，然后要過這個Jitter Buffer，就叫做抖動緩沖區。
所以抖動緩沖區的核心模塊其實就是處理，因為我們走在互聯網的數據包，會遇到比如丟包、亂序、延遲到達等復雜的場景，那么這時候就要去做一個很核心的功能，我要盡量平緩地就像解碼模塊去輸出一個數據包幀，所以它其實是抗弱網的一個核心模塊。
其實我們都知道網絡具有不穩定性，如果大家關注過互聯網的數據包延遲的話，你會看到它其實是一個曲線，或者至少是一個鋸齒狀態，它是一直在波動的，偶爾就會有突發的一個抖動，或者是一個數據包的被丟失，甚至可能是因為端上的性能不足等會引發一些執行視頻相對比較復雜的地方，既然它比一般的直播延遲要更短，比如說我們一般定義是要100-200毫秒，那么在這么很短的情況下，如果網絡出現一個波動，它會導致短期的延遲都大于200毫秒了。
如何去設計你的緩沖區？比如直播，m318可以有9秒，我可以有三個分片，加起來6秒到9秒，甚至還有更夸張的有12秒緩沖區的設計。那么在實時音視頻的情況下是沒有的，他沒有這么大的一個緩沖區，怎么辦呢？所以它實際上也是一些預測算法，核心的上網叫做卡爾曼濾波，通過一些算法去估算當前網絡排隊的延遲情況，還有現在傳輸的信道的整體傳輸速率。
當然現在也有很多人把這個模塊輔助加一些預測，訓練出一些模型去簡單做一些預測，所以它主要是根據這幾個參數，比如抖動延遲的觀測值、前后兩幀的大小的差值，還有當前網絡噪聲和系統的誤差等參數去計算出來一個卡爾曼增益系數，去調整Jitter Buffer的大小。比如說如果發現數據不夠了，他可能會把一部分的數據去做拉長，這時候你就會聽到像類似于電音這樣的一些真實的效果。
第二塊叫補償算法。
在WiFi的標準里面，一個叫后項，一個叫形象補償算法，我們其實一般都是用的后項，在WiFi里面主要用前項，在其他領域一般用后項。
ARQ就是快速重傳，NACK也是快速送出來這種算法的一個動態的智能聯動。算法會根據不同的網絡情況，比如說你當前是丟包比較多，還是延遲比較高，會根據一些具體的情況去動態切換。
所有的切換其實就是要去調整一個東西，重傳包和冗余包的比例。
重傳包很好理解，就是一個數據包丟失了，需要立刻重傳一次，公網的RTT延遲在中國大陸的話一般平均在70毫秒，這樣的策略能控制整個音視頻延遲在400毫秒以內。
那么另外一種方式是通過冗余比例。人耳其實對音頻更敏感，比如說像直播的時候一般是相對靜態的畫面，其實視頻還好，因為你丟了一兩幀，只是在網絡非常卡的時候，可能看到人有點跳躍式的動作，不是那么連貫，但是影響不是那么大。
反而是音頻識別比較難，因為人耳相比于人眼本來就更敏感，如果音頻不連續，你聽起來會很奇怪，你聽到的表意是不完全的。人對聽到的聲音的理解其實是一個比較復雜的過程，你要先聽到每一句每個字，然后再把它組成詞，組成句，還有上下文的語境，那么這個過程其實相對比較復雜。
所以其實音頻更多的就是靠的是整個軟件的數據比例，比如說我們常見的至少是兩倍甚至還有三倍的，通過調整冗余包的比例，即使數據包丟失也不用擔心。
還有更高級的算法比如可以做低頻的數據和高頻的數據，把它去做拆分，如果你收到完整的數據，你聽到音頻的質量會更高，如果你只收到了低頻的部分，你聽到的這個聲音就稍微有點失真。
所以其實都是通過各種各樣的補償方法，在網絡相對比較差的情況下保證實時音視頻或者一個會議場景的效果。
下面這張圖解釋了為什么我們叫他把它叫做實時音視頻平臺，而不只是一個簡單的產品。
上行的一條線是采集、音視頻預處理、編碼、網絡傳輸、云服務端，有些還會有兩大分支處，一個是做錄制，第二個是旁路推流，旁路推流就是比如我們幾個人開會，還可以把這個會議直播出去給更多的人觀看。
另外一條下行的是網絡傳輸、解碼、后處理，比如說美顏、加水印等。
實際上每個步驟在每個真實的用戶場景里面都會有各種各樣的功能。我就舉個最簡單例子，比如音頻采集，是不是設置麥克風，有一些專業的麥克風、有混響，或者說他用了一些美顏相機；比如我在電腦上播放了一段音樂，我想要去采集應用播放出來的音樂聲，還有比如有些老師唱歌，用了一些聲卡，或者是我之前本地有一個音頻文件，想把音頻文件做成混音的效果……
視頻采集就更復雜了，比如手機有前置后置攝像頭，后置攝像頭還分為長焦遠焦；還有我們做桌面分享的時候，可能需要我做整個屏幕的或者是某個窗口某個區域的某個應用的分享；還有更專業的直播間需要去對接追蹤人臉的360°的網絡攝像頭。
所以一個標準的平臺產品，你要把它的底層設計做得足夠通用其實很復雜，這也就是為什么很難有一款SaaS產品能夠去很好地滿足各行各業的應用場景。我們只能是在PasS的基礎上搭建一個平臺，在這個平臺的基礎上，對每個模塊去做你熟悉的產品和場景，你了解它的功能，并了解底層提供的支撐一些功能的能力，這時候你去設計你的產品才是相對比較良性的狀態。
我們回顧音視頻的技術發展其實受制于一整個系列的影響，比如說硬件的性能夠不夠？操作系統支不支持？多媒體協議的發展，應用的展現形式，用戶的接受度，還包括整個互聯網的帶寬基礎設施的建設程度。比如最早大家用的都是音視頻，都是用專業的硬件，后來出現了通用CPU加多媒體的指令集。
第二個是從方式的角度，出現了線程緩沖、FEC算法，其實內核網絡協議沒有太多調整，比如最著名的就是在4.9的時候bb2，還有現在比如說像現在 HTTP3.0會把quick作為基礎等等，那么我們在協議上其實也在逐步做分層，比如說存儲會作用于冗余編碼糾錯、編解碼codec、傳輸編碼，同時也引入了容器這樣一個音視頻封裝概念。
比如還有我們大家都知道的像h264v8，現在未來會去往ABE去轉等等。其實每一代的發展都是去實現一個更高的壓縮率，讓你能夠以一個更低的綜合碼率去傳輸更高清的內容。
人對高清音視頻通話的追求是永無止境的。我們以前覺得馬賽克像素級的那種東西看得很開心，但是你現在應該很難回去了，你現在在看比賽的時候希望能看到球員臉上的毛孔，同時我們以前對音視頻更多只是做內容的一個分發傳播，其實現在已經發展為各類的實時和互動的場景，所以其實它的整個迭代引進是一方面是需求引進，一方面是底層的支撐能力的引進，而且它是一個協同發展的過程，每一塊都不可或缺。
為什么說短視頻要到4G時代才能迎來它的爆發點？你可以想象一下，如果你刷抖音，一個視頻刷的中間卡了幾秒鐘，你的體驗肯定是難以接受的。而且如果整個網絡支撐不住，所有人都這樣去刷的話，其實大家體驗也會非常差。
4G時代，大家的平均網絡帶寬是多少呢？20~30兆；在3G的時代，大家的網絡速度其實只有1兆到5兆之間，在2G網絡的時候是更小的，每個人其實只有二三十KB，只能刷刷網，看看小說，刷刷一些簡單的網頁。
那么面向未來也有一些很高級的功能，比如說剛剛我其實已經提到過了聲音處理，還有特效，比如每個人都希望自己的聲音更完美，男生希望更火爆，女生希望更可愛或御姐風等；
還有比如更智能的降噪還有聲紋識別。聲紋識別應用已經越來越多了，比如微信登錄時可以通過說幾句話來去識別一個人的聲紋的。實際上聲紋是個很好的生物密碼技術，每個人說話的聲音或者是念不同語句或者數字的聲音是不一樣的。
再比如說音軌的分離。一段語音可以由很多聲音組合而成，比如說我們現在常見的PC或者手機能處理36路這樣一個聲音去混合起來。混合起來容易，但是怎么樣去做分離？比如記者在采訪的過程中，實際上是有多個人在講話的，我能不能去分離出來某一個人講話的聲音，然后我把它先去做做語音轉寫等。
還有更高效的codec，這個是永無止境的追求。4k的視頻傳播大概對帶寬要求在8兆到20兆之間的，但是能不能去實現更低的，比如說2-4兆，在這樣一個帶寬要求上去實現4k的效果。實際上這部分已經有進展了，基本上可以確定它他會在5G時代落地。
最后一個，在RTC之前其實已經有很多業務，雖然互聯網化、數字化已經讓很多業務從線下搬到了線上，但還是有很多很重的場景做不到。比如說在線上課，比如說遠程看病，以前為什么做不到？是因為以前的視頻方式很難真正去滿足用戶的需求。
過去供給方和需求方是不愿意坐在一起去磨合的，那么疫情在某種程度上是把大家逼到了一起，沒有退路了，必須互相往中間去靠，不能是你指望我走999步，你只走1步。
在這個時候，我們傳統說的直播已經成為了一個生產力工具，它可以很好地去加速原來一些很頑固的線下場景線上化。包括現在的云旅游、互聯網看病、城市一網通管理。
第二，UCloud的思路是做PasS，因為做SasS，一個人一個公司一個團隊是不可能去滿足所有行業的需求，也很難去做到真正的聚焦。當然可能會比如像教育、視頻會議這些行業本身很大，專門投入進去做也沒問題。
第三，音視頻行業絕不僅僅局限于教育、醫療、辦公，作為一個云計算公司，我們發現很多有意思的需求，比如說工業的各類遠程控制，以前的設備是看不到當地的畫面的，只能通過一些傳感器的數據去做軟件操作，或者說我看到的畫面是有延遲的。如果它是實時的，就能去做一些更精密的控制，或者是更有想象力的一些操作，某種程度就可以解放人。
在疫情期間其實已經出現很多場景了，比如一個人在遠程去操作一個挖掘機，在某一個環境比較惡劣的地方去挖礦，還有通過智能家居的方式去控制家里的一些東西。
每一代技術的發展都是游戲娛樂領域的創新會走得更快。
另外，我認為5G時代會出現云游戲的概念，原先我們在玩手機游戲的時候是非常消耗手機性能的，那么未來渲染可能是放在云端去完成，本地其實只是相當于在看一個電影似的，然后其他的操作觸碰的一些指令是單獨完成的。
最后我們堅信的一點，每一次交互方式的變化都是革命性的，比如說手機的交互從傳統的數字按鍵變成了觸摸屏，電阻屏變成了電容屏，比如說語音的交互。
如果能有一個穩定、易得、便宜的RTC云服務將是引爆這些需求的最好契機，也是將這些需求線上化最好的催化劑。
問：疫情期期間的在線網課，連阿里騰訊都要緊急擴容，目前的技術水平是否難以應對這種超級高并發？
答：首先我們要正確理解兩個東西，第一個是并發，這個并發算高嗎？今年在疫情期間，釘釘的最高峰值是3000~5000萬，騰訊視頻騰訊會議的最高并發好像是2000萬左右。我們都知道目前的國內的最高并發應該算是像微信的十幾億并發，或者是騰訊阿里雙11的時候，這種每秒的幾萬筆支付，還有比如說像秒殺活動算高并發。我認為在線網課的這個并發不算高，而且這個并發是可以去做隔離的，比如說我可以按照一個房間來，可以按照一個地區來，是可以去做分級群這樣一個架構設計的，反而真正復雜的是資源，需要海量的計算網絡存儲資源。目前并不是國內的技術水平不能達到，而是大家平時不會囤那么多的資源在那。
問：疫情期間很多機房無法進入服務器，供應商也無法及時上門服務，如何去保證服務的穩定？
答：這個事情叫巧婦難為無米之炊，如果沒有足夠量的資源儲備，實際上是誰都沒有辦法。所以第一個是你的資源池要足夠龐大，比如說現在云服務都是全球部署，資源的儲備肯定是很重要的。
對于客戶而言，比如說我們一個地區可能有數萬臺服務器這樣一個規模的話，總歸是提供了更大的彈性，然后大家可以更多的去復用，比如說你是白天上課，我是晚上娛樂，我是中午吃飯，發新聞等等。更多的云計算是通過這樣一個集中式的更大資源池提供更高的彈性。
問：疫情期間總是出現卡頓和崩潰的現象，這個問題是如何去解決的？
答：崩潰的問題其實主要是幾個方面，第一個是性能問題，長時間高性能的運作，會導致你的設備系統的穩定性較差。第二個是產品的設計問題，如果你產品都沒有很充分的去設計，沒有考慮用戶的使用場景，只是把供應堆積在那，這種事情是難以避免的。
最后一個，互聯網的任何地方都是可能會存在bug，隨著整個產品去迭代，這種現象會越來越少，性能也會越來越優化。
但是卡頓就是一個比較復雜問題，卡的問題其實也是要分情況的。比如說剛剛我之前有提到過，在視頻會議或者是在教學場景下最極端的情況下，我們可以把視頻降到更低的分辨率，或者說比如說現在假設我的網絡很差，我可以把攝像頭屏蔽掉，我只傳播聲音。
第二，還是要取決于整個服務抗弱網的一些更優秀的算法，或者是一些在工程上面的創新。同時也離不開基礎設施的提升，比如以前大家上網用ABS撥號，后來換成了光纖入戶。未來的網絡也會逐步提高，同時在無線通訊上，4G網絡的平均延遲只有30毫秒左右，在3G時代是400毫秒左右。所以某種程度4G網絡下已經可以去實現實時音視頻的互動，那么在5G下效果可能會更高，所以卡頓其實是要綜合來考慮的。
問：純線上課的互動和教學都不如線下，怎么讓大家從心理上去接受線上線上教育？
答：線上課的最大的問題就是互動和教學的效果，本質的一個原因是線上教學老師傳遞的信息不夠多。比如說老師現在在一個課堂里面上課的時候，老師一抬頭可以看到這個房間里面的所有信息，只要一個動作，我就可以接收到很多信息。
但在線上課，現在的產品能力做不到。比如說一個房間有幾十個人的時候，如果把這幾十個人的圖像都堆在下面，老師什么都看不到，但其實現在已經有一些產品設計了，比如說這個房間里面是一個小班教學，35個人的圖像輪流滾動，每次放5個人的圖像在下面，這種方式老師其實就已經能夠看到部分學生的教學反饋了。
還有一個是大家可能都沒有意識到，上課的時候，老師會不自覺地問大家有沒有感覺到卡頓，有沒有聽不清，其實有很多無效的互動都會浪費在了這些問題的回答上。
如果我們的服務足夠穩定，我們的產品設計能夠讓老師捕捉到更多的信息，老師不用去關心學生是否聽到我的回答，當某個學生掉線的時候，老師能立刻能有個東西提示他，把所有主動做的事情全都變成被動，任何意外情況都會以一種形式去通知到老師，這樣互動效果就會大大提升，這也是接下來整個面向在線教育產品升級的地方。
教學效果為什么不如線下，也包括一個監督不夠的問題?，F在也已經有一些針對性的產品設計了，比如說端上至少可以做一個事情，我可以捕捉學生的畫面，如果我識別不到人臉的，我就發一個提示聲音去通知學生，甚至還可以通知到老師。
第二我們再去做一些輔助教學工具，老師平時在黑板上寫板書很容易，但是如果在電腦上要去手寫一個東西相對比較困難，現在有些手寫板的功能也慢慢在做了。
這些問題并不是說不可逾越，都是可以通過產品技術或者是在上課過程中的一些創新的教學方法、教學理念去大幅改善。
問：地方的小型培訓機構，還有轉型線上的必要嗎？
答：在我看來是非常有必要。
首先第一個是疫情的反復，我認為疫情是長期存在，今年疫情期間，我看到一個數據說之前有40萬的培訓機構，疫情后驟減到25萬，倒閉了40%。如果再來一次疫情，還有多少人能保證自己活著？
所以在我看來，不叫轉型線上，而是要儲備一定的線上能力。小型的公司可以去簡單使用一些大的平臺，看誰用得好，你可以跟著去學習去改變你的使用方式 ；大一點的機構，可以去儲備自己的線上產品；更大的機構，甚至還要做技術儲備、教學工具教學設備。比如我看到很多大的教育機構，現在其實都在花很多的錢去去蓋樓建直播間。
第二你也可以去思考，我們去看教學的場景分為三個大的方面，教學、輔導、練習。那么練習這個事情是不是很好地可以通過線上的方式完成？輔導，尤其像一對一的方式，是不是有一部分可以通過線上？有一部分很重的很復雜的采用線下？知識是有記憶曲線的，比如說線下很多時候必須要家長去接送，有時候課必須是周末才能上的，那么這時候可能有些知識點就已經忘記了。如果我在周中的時候去穿插一節網課，不講新的內容，只做鞏固，是不是效果就會好很多？
所以在我看來，這不叫轉型線上，而是一定要去具備線上的思維方式，儲備一定線上的能力。
問：怎么樣去看待云技術對教育行業的重構？
答：這個問題其實我是這樣看的，因為教育是一個很相對比較傳統比較重要的行業，但是同時它的數字化過程不會那么迅猛。比如說現在可能大家只聽到一些互聯網大學的概念，基本上不會聽到互聯網小學、小學、中學。
第二，教育某種程度上是一個人力密集型行業，效率相對比較低下，比如說老師批改作業可以用AI來實現，另外，老師在備課的過程中也有很多工具，我見過在線教育機構有的備課已經是用游戲引擎來做了，他們做出來的是一個動畫效果，而不是簡單的小視頻和圖片做演示。
再比如說孔子一直講因材施教，有教無類，我們現在可以通過推薦算法去識別一個人的真實能力，這樣就可以避免非?？菰锏念}海戰術。我們大家在面對高考或者中考等應試教育的過程中，實際上做了大量無效的工作，比如說題目的知識點我已經很熟悉了，但是我還是在不斷去刷題等，那么未來能不能通過大數據去滿足智能化的題目推薦。
以上就是我今天的分享，謝謝大家！
本期公開課完整視頻鏈接：http://m.qcxyk.com/openCourse/view/s/5f169723649a7
雷鋒網“教育新基建”系列公開課正在火熱進行中，后續將上線更多重磅嘉賓和課程，敬請關注~
添加雷鋒網-小雷哥微信leiphonesz2018，即可拉你進群觀看直播~
欲申請雷鋒網”教育新基建“公開課演講的廠商，請加雷鋒網-海棠姐微信：lijingying0451
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
