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