隨著低延時(shí)流媒體技術(shù)的不斷進(jìn)步，在線教育行業(yè)持續(xù)升溫。本文來自七牛云在線教育行業(yè)解決方案專家 徐晶在LiveVideoStackCon2018大會中的演講。在演講中他闡述了基于WebRTC架構(gòu)的低延時(shí)直播技術(shù)突破以及其在教育行業(yè)中的實(shí)踐與思考。本文由LiveVideoStack整理而成。

文 / 徐晶

整理 / LiveVideoStack

大家好，我是來自七牛云的徐晶，非常榮幸可以跟大家分享我所做的一些項(xiàng)目和實(shí)踐，本次我要分享的主要內(nèi)容包括以下幾個(gè)方面：

1， 視音頻技術(shù)的演進(jìn)；

2， WebRTC 課堂實(shí)踐；

3， WebRTC 在教育行業(yè)的思考；

一、視音頻技術(shù)的演進(jìn)

首先，我們一起來看上面這張圖，這張圖是由國際電信聯(lián)盟電信標(biāo)準(zhǔn)化部門統(tǒng)計(jì)所得，圖中的橫軸坐標(biāo)是毫秒，代表著時(shí)延，縱軸坐標(biāo)是用戶的體驗(yàn)度。由上圖，我們不難發(fā)現(xiàn)，時(shí)延達(dá)到150毫秒的時(shí)候，用戶的體驗(yàn)度開始下降，當(dāng)達(dá)到400毫秒的時(shí)候，用戶的感受是無法容忍。由此，ITU-T G.114國際標(biāo)準(zhǔn)規(guī)定，延時(shí)超過150毫秒表示已經(jīng)開始影響用戶體驗(yàn)，并且用戶可以容忍的最高延時(shí)是400毫秒。舉個(gè)例子，當(dāng)發(fā)生臺風(fēng)天氣時(shí)，電視臺的主持人通常會連線現(xiàn)場的記者，當(dāng)連線返回現(xiàn)場報(bào)道時(shí)，基本是過了兩秒左右的時(shí)間，現(xiàn)場記者才收到主持人的話，聽眾的體驗(yàn)感相當(dāng)不好。類似于上面的情況基本上是無法實(shí)現(xiàn)實(shí)時(shí)互動的，想要進(jìn)行實(shí)時(shí)互動的關(guān)鍵點(diǎn)就在于低延時(shí)。我以前也曾經(jīng)做過八年直播相關(guān)的研發(fā)，從最初的底層協(xié)議到RTMP協(xié)議再到現(xiàn)在的WebRTC，用戶需求為何會逐漸從點(diǎn)播域向直播域靠攏，直播流媒體實(shí)時(shí)音視頻為何會越來越關(guān)注互動，也正是因?yàn)橛辛说脱訒r(shí)，互動才得以慢慢發(fā)展出來。

不知道大家是否清楚，為什么流媒體在之前都沒有發(fā)展起來這種很好的互動性呢？有很多人認(rèn)為RTMP協(xié)議很不錯(cuò)，并且現(xiàn)在外面大部分采用的都是RTMP協(xié)議。既然如此，為什么大家都去研究WebRTC呢？首先，RTMP是基于TCP協(xié)議的，TCP是一個(gè)安全可靠的協(xié)議，它包含了很多機(jī)制，如數(shù)據(jù)的安全保障、三次握手、重傳機(jī)制等，但是這恰恰會影響到它的傳輸時(shí)間。舉個(gè)例子，我現(xiàn)在手上有一份數(shù)據(jù)要發(fā)送給另外一個(gè)人，發(fā)送過去之后由于網(wǎng)絡(luò)抖動導(dǎo)致丟包。他沒有收到包則會返回一個(gè)消息來告訴我他沒收到我的包，這樣就會產(chǎn)生很大的延遲。那么，能不能直接用UDP呢？三年前的廣電系統(tǒng)，比如北京衛(wèi)視等采用的是TS流，TS流就是基于UDP的，它的傳輸非常有效。TS傳輸具有高可靠度，流媒體安全且質(zhì)量好，但是基于UDP都是基于內(nèi)網(wǎng)的，對網(wǎng)絡(luò)的要求非常高。北京衛(wèi)視也只有內(nèi)部的網(wǎng)絡(luò)全部用的是TS流，采用UDP的協(xié)議來傳送，一旦離開公司，就不可行了。因?yàn)閁DP是不安全的，它沒有重傳機(jī)制，沒有各種保障的能力。從上圖中可以看出，UDP相對來說延時(shí)是最低的，但整體質(zhì)量很低，對網(wǎng)絡(luò)的依賴程度也非常高，所以我認(rèn)為這是一個(gè)成本的問題。在這里推出一個(gè)概念，叫做RUDP（Reliable UDP）。RUDP指的是將TCP和UDP各種優(yōu)勢結(jié)合在一起，包含的功能有：

1）冗余編碼和前向糾錯(cuò)；

2）場景化的重傳策略；

3）帶寬自適應(yīng)調(diào)整；

4）更優(yōu)的擁塞控制算法；

5）多點(diǎn) relay…

簡單解釋一下什么叫做場景化的重傳，UDP因?yàn)闆]有重傳策略，對于我們來說絕對不安全，場景化重傳就是說，如果是I幀這種關(guān)鍵幀丟失，那就重傳一個(gè)I幀，如果是一個(gè)不是特別重要的幀丟失，則不重傳，或者說有一些可以做同步的信令標(biāo)準(zhǔn)沒有到達(dá)，我也不重傳，這樣就可以極大的優(yōu)化傳輸效率。

接下來介紹的是WebRTC的核心，大家也可以在Chrome，Google或WebRTC的官網(wǎng)上找到它的解釋。概括一下，WebRTC 內(nèi)核提供的技術(shù)能力包括：第一，低延時(shí)的音視頻采集編碼和解碼。編碼和解碼是音視頻中最重要的部分，是提供低延時(shí)的保證。第二，降低門檻，有瀏覽器的地方就可以使用WebRTC；這點(diǎn)我覺得是Google做得非常好的地方，目前微軟、蘋果、Google等都支持WebRTC，除此之外，大家現(xiàn)在手上用的很多硬件設(shè)備，都已經(jīng)支持。最終會達(dá)到只要存在瀏覽器的地方都能使用。第三，優(yōu)異的RUDP傳輸協(xié)議；WebRTC原本就是基于UDP的，在UDP上進(jìn)行優(yōu)化，可以更有效的使其傳輸?shù)臄?shù)據(jù)安全、可靠。第四，端到端的協(xié)商/建聯(lián)框架；在七八年前，端到端上的直播幾乎不可能實(shí)現(xiàn)，為什么那時(shí)大家看到都是廣電做的直播，而不是互聯(lián)網(wǎng)在做直播？原因是端上的系統(tǒng)度不夠。

此外，WebRTC還提供一系列的業(yè)務(wù)能力：第一，低延時(shí)音視頻垂直領(lǐng)域的發(fā)展； 什么是垂直領(lǐng)域？比如今天分享的主題——教育，就是一個(gè)非常垂直的領(lǐng)域，當(dāng)前在線教育的火爆也正是由于音視頻技術(shù)的發(fā)展，可以真正的實(shí)現(xiàn)溝通零距離。因此WebRTC對于垂直的領(lǐng)域非常有效，比如說教育、醫(yī)療行業(yè)等。第二，就是剛剛提到教育和醫(yī)療實(shí)時(shí)音視頻。第三，互動音視頻，遠(yuǎn)程廣電系統(tǒng)；我之前在阿里巴巴為阿里云做了一個(gè)五地互傳，當(dāng)時(shí)阿里云在紐約，新加坡，肯尼亞，杭州等都有很多分部，會發(fā)現(xiàn)你要把他們放在一起溝通是一件很難的事，當(dāng)時(shí)我們想到的第一個(gè)策略就是用衛(wèi)星，但衛(wèi)星的成本真的是高的離譜，而WebRTC就可以完全顛覆它，衛(wèi)星傳輸?shù)馁|(zhì)量不如WebRTC是因?yàn)閃ebRTC采用的技術(shù)和算法完全超越了硬件所能帶來的最低延時(shí)。第四，海外視頻；WebRTC還有一個(gè)最大的業(yè)務(wù)能力是進(jìn)行海外跨國傳輸，例如在之前將戛納電影節(jié)上的一些活動的內(nèi)容從戛納傳回來是一件基本不可能的事情，但是現(xiàn)在可以通過WebRTC實(shí)現(xiàn)，當(dāng)然還要結(jié)合一些網(wǎng)絡(luò)和語音的相關(guān)優(yōu)化。

二、WebRTC課堂實(shí)踐

接下來，從垂直領(lǐng)域來為大家介紹一下WebRTC在教育行業(yè)的課堂實(shí)踐中的一些能力，包括電子白板、高質(zhì)量通訊、IM和協(xié)作能力。

2.1 在線白板

電子白板是用于解決多人互動場景下，用戶理解和分析的黑板能力。在教育行業(yè)中，無論是視頻還是音頻，都離不開這個(gè)白板。在學(xué)校里，對比現(xiàn)在和過去的課堂我們會發(fā)現(xiàn)變化是非常大的，但是只有一樣?xùn)|西沒變，就是黑板，所以足以證明黑板有多么的重要。當(dāng)我在一塊黑板上面寫字，一般人的做法是將它變成一個(gè)視頻然后傳播出去，讓大家看到。但是這樣有一個(gè)很大的問題，視頻資源最少需要300kbps的帶寬，這會占用用戶很多的帶寬，對于資源消耗是非常高的。我們做了一件事情，就是讓黑板變成一種描述性的語言。用描述性語言來替代白板，用它來描述白板到底畫了一些什么，而它所占的帶寬資源最高是9kbps，也就意味著，它的帶寬消耗是用傳統(tǒng)方式傳輸最低質(zhì)量視頻這種方式的1/30。這是一個(gè)非常偉大的突破，可以為客戶節(jié)約大量的成本和資源消耗。視頻化白板的體驗(yàn)問題包括無法放大縮小、不具備交互能力。但如果它是一個(gè)描述性語言，就可以隨意放大縮小，并保持清晰。另外，對于視頻，我無法在上面做第二次操作，但描述性語言可以。在數(shù)據(jù)擴(kuò)充性方面，視頻化白板是很差的，由于視頻內(nèi)容是非結(jié)構(gòu)化的，導(dǎo)致很難被存儲。另外，AI是無法識別視頻索引的。舉例說明，我畫了一只貓，現(xiàn)在AI的能力還不足以識別它是一只貓。因?yàn)槲耶嫷牟⒉皇翘貏e有效，因此識別不了，但如果是描述性語言來表示，就能立刻識別出是只貓。最后是視頻化白板的數(shù)據(jù)識別轉(zhuǎn)換低。舉個(gè)例子，有些AI公司會將一些視頻中的數(shù)學(xué)符號識別成了數(shù)字，這是因?yàn)樗鼰o法識別。但對于描述性語言就可以輕松識別，因?yàn)樗且粋€(gè)矢量數(shù)據(jù)，它可以體量。這些說明了使用描述性語言改善了白板是有效的，在這里總結(jié)了一下，使用描述性語言白板帶來的好處：

1) ?對白板改變進(jìn)行沖突管理

2) ?描述性語言降低整個(gè)白板視頻帶寬

3) ?降低 CDN 使用成本

4) ?回放和錄制存儲要求極低，幾乎可以忽略

5) ?矢量信息可無限放大細(xì)節(jié)

6) ?多端同步，相互備份

2.2 高質(zhì)量通訊

Mesh、MCU和SFU是WebRTC的三種模式，目前可以說大部分使用WebRTC的廠商都選擇了SFU模式，因?yàn)樗亲罡咝У摹CU一般應(yīng)用于廣電領(lǐng)域，MCU就是不同端的推流，都發(fā)送到一個(gè)中央處理器上進(jìn)行混流處理，處理完成后再分發(fā)給每個(gè)客戶端。SFU指的是每個(gè)客戶端都推流到服務(wù)器，由服務(wù)器轉(zhuǎn)發(fā)所有的數(shù)據(jù)到各個(gè)客戶端。如果廣電要用到畫中畫的功能，MCU是沒辦法實(shí)現(xiàn)的。通俗的講就是MCU將東西都固定好了，不能進(jìn)行某一個(gè)區(qū)域的放大，它在服務(wù)端就已經(jīng)進(jìn)行了拼合。但是對于SFU，在收到服務(wù)器返回的數(shù)據(jù)流后可以再隨意進(jìn)行拼合。Mesh是一個(gè)最基本的，相對高質(zhì)量的模式，但由于它消耗的資源及帶寬功耗都比較高，所以不會經(jīng)常用到。

高質(zhì)量的通訊包括畫質(zhì)、流暢度和協(xié)同，畫質(zhì)包括了編碼方式、碼率和編碼效率，流暢度包括了中間層構(gòu)建、Plus插件和帶寬優(yōu)化方案，協(xié)同包括配套播放器和沖突管理。那在這里有幾個(gè)問題想和大家分享一下：

1) ?1.8Mbps 的 720P 清晰度高還是 3Mbps 的 1080P 清晰度高？

2) ?H264 Profile Level 決定了哪些要素？用戶體驗(yàn)是什么？

3) ?為什么有些場景下只能用 Profile level 3.1 ?

4) ?究竟我們應(yīng)該使用哪些最優(yōu)方案去做畫面的匹配？

對于第一個(gè)問題，我問了很多人，最后發(fā)現(xiàn)一個(gè)很神奇的事情，還是有很多人會選擇3M碼率的1080P的清晰度高。我想跟大家說，Adobe官方有一個(gè)推薦，剛開始推RTMP協(xié)議的時(shí)候，對編解碼也給出了一個(gè)標(biāo)準(zhǔn)的推薦值，720P推薦的是1.8Mbps，1080P推薦的是5.5Mbps，只有這樣才能滿足相應(yīng)畫質(zhì)的傳輸。那么這個(gè)問題的答案也就自然而然了，用3Mbps去傳輸1080P是不滿足對應(yīng)畫質(zhì)的，看起來的效果不如1.8Mbps 的 720P 清晰度高。對于第二個(gè)問題，H264 Profile有3.0、3.1、4.0、4.1等不同level，這些算法依次是復(fù)雜程度越高，圖像的精度也越好，這也決定了畫質(zhì)和效率，而用戶體驗(yàn)指的是流暢度。對于第三個(gè)問題，為什么有些場景下只能用H264 Profile Level 3.1，而它的畫質(zhì)沒有那么清晰？舉例說明，有一天小天才的負(fù)責(zé)人跟我說，他要做一件事情，就是讓孩子的父母可以用著手表進(jìn)行有效的溝通。那這當(dāng)中有個(gè)問題，我們當(dāng)時(shí)給它設(shè)計(jì)的是畫質(zhì)優(yōu)先，將profile level調(diào)到了4.1，結(jié)果發(fā)現(xiàn)，手表8分鐘就燙得戴不了，功耗實(shí)在是有點(diǎn)高。后來，我們想到把這種嵌入式設(shè)備的profile level降到3.1，所以這就回答了為什么是有些地方情愿不需要畫質(zhì)，而需要它的profile level更高效，這跟功耗有關(guān)。 對于最后一個(gè)問題，就畫面匹配這件事情來說，到底是提供一個(gè)高profile level的算法，還是低功耗的性能？這是兩件事情，需要有一些權(quán)衡，確定其中一個(gè)有最大化利益。

2.3 IM/AI

在這里我想給大家講一些案例，就是AI在視頻里的一些應(yīng)用。噠噠英語的老板，給了我一個(gè)案例，他說有一個(gè)小孩上他們的課，噠噠都是一對一模式上課，結(jié)果那個(gè)小孩上來跟老師說， “老師啊，那個(gè)我不想上課，是我爸讓來的，你該干嘛干嘛去吧，我打游戲去了”。最后，這個(gè)課堂只是攝像頭開著，但是兩邊都沒有人，成了一個(gè)無效的課堂。后來，我設(shè)計(jì)了一樣?xùn)|西，就是AI在視頻里面的應(yīng)用。這個(gè)東西就是用一個(gè)機(jī)制去計(jì)算攝像頭的兩端，如果超過一分鐘沒有識別到人臉，那么它觸發(fā)一個(gè)報(bào)警給到教務(wù)，告訴他說，這是一個(gè)無效的課堂，你應(yīng)該管管。第二個(gè)案例，為了防止高校中的翹課現(xiàn)象，我在課堂上裝一個(gè)攝像頭，然后對視音頻進(jìn)行AI的識別，事先知道每個(gè)人是誰，然后不間斷去識別。若某位同學(xué)進(jìn)來后，10分鐘之后他從后門溜走導(dǎo)致識別不到他，立刻出現(xiàn)一個(gè)報(bào)警，表示沒有檢測到某位同學(xué)。還有一個(gè)應(yīng)用是我在跟浙江傳媒大學(xué)一起溝通的時(shí)候發(fā)現(xiàn)的，中國的教育到現(xiàn)在還沒有一個(gè)龐大的數(shù)據(jù)庫，沒有對某一個(gè)學(xué)生從0到1的分解。舉個(gè)例子，現(xiàn)在的探頭在視頻里的應(yīng)用可以偵測很多行為，我發(fā)現(xiàn)上語文課時(shí)，有個(gè)小姑娘永遠(yuǎn)坐在第一排，并且偵測她舉手次數(shù)超過30次，然后又發(fā)現(xiàn)她上數(shù)學(xué)課時(shí)，永遠(yuǎn)在最后一排睡覺。它觸發(fā)的是系統(tǒng)自動進(jìn)行一個(gè)大數(shù)據(jù)分析來告訴說這個(gè)女孩是適合文科，而不適合理科的，然后把這個(gè)信息交給教務(wù)，在這個(gè)女孩身上她打了一個(gè)標(biāo)簽，大數(shù)據(jù)識別出來她適合文科，這就是社會價(jià)值、教育的價(jià)值。還有就是在教育領(lǐng)域也已經(jīng)做了的，利用AI來做課堂筆記，在講課的同時(shí)，將老師和學(xué)生的語音進(jìn)行語音識別直接轉(zhuǎn)成了文字，也就意味著，當(dāng)這個(gè)課堂結(jié)束，課堂的所有筆記以及老師說的每一句話，已經(jīng)全部變成一個(gè)文檔留存下來。

三、WebRTC 在教育行業(yè)的思考

最后，說說我們在教育行業(yè)里面的思考。第一，傳統(tǒng)教育是解決更多場景化的共性需求。舉一個(gè)簡單的例子，場景化教育就是當(dāng)我有一天站在某個(gè)傳統(tǒng)高校的講堂進(jìn)行演講的時(shí)候，該如何幫助提升效率。第二，垂直教育，利用WebRTC能力，構(gòu)建創(chuàng)新型協(xié)作思維，讓程序員也可以做教育。第三，PUDC的開放，我認(rèn)為現(xiàn)在中國教育還是有很多機(jī)構(gòu)參與的，但未來會是一個(gè)PUDC的時(shí)代，每個(gè)人都是老師，每個(gè)人都是學(xué)生。最后，智能改變，就是去實(shí)現(xiàn)各種AI的教育。

精品文章推薦

技術(shù)干貨：

• 誰是最好的WebRTC SFU？

• WebRTC的擁塞控制和帶寬策略
  

• 使用級聯(lián)SFU改善媒體質(zhì)量和規(guī)模
  

• 基于HLS格式的低延時(shí)互動直播技術(shù)

• 機(jī)器學(xué)習(xí)幫助WebRTC視頻質(zhì)量評價(jià)

• 用WebRTC在Firefox上實(shí)現(xiàn)YouTube直播

• UDP成為低延時(shí)流媒體關(guān)鍵 選SRT還是QUIC？

• 下一代低延時(shí)直播CDN：HLS、RTMP 與UDP +WebRTC

總結(jié)

以上是生活随笔為你收集整理的WebRTC直播课堂实践：实时互动是核心的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。