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

文 / 徐晶

整理 / LiveVideoStack

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

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

2， WebRTC 課堂實踐；

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

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

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

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

1）冗余編碼和前向糾錯；

2）場景化的重傳策略；

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

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

5）多點 relay…

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

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

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

二、WebRTC課堂實踐

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

2.1 在線白板

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

1) ?對白板改變進行沖突管理

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

3) ?降低 CDN 使用成本

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

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

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

2.2 高質(zhì)量通訊

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

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

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

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

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

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

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

2.3 IM/AI

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

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

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

精品文章推薦

技術(shù)干貨：

• 誰是最好的WebRTC SFU？

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

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

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

• 機器學習幫助WebRTC視頻質(zhì)量評價

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

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

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

總結(jié)

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

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