WebRTC直播課堂實踐：實時互動是核心

隨着低延時流媒體技術的不斷進步，在線教育行業持續升溫。基於WebRTC架構的低延時直播技術突破以及其在教育行業中的實踐與思考。
GitHub：
先放github連接
(更多完整項目下載。未完待續。源碼。圖文知識後續上傳github。)
( VX：mm14525201314)

很是榮幸能夠跟你們分享我所作的一些項目和實踐，本次我要分享的主要內容包括如下幾個方面：

1，視音頻技術的演進；
2， WebRTC 課堂實踐；
3， WebRTC 在教育行業的思考；

1、視音頻技術的演進

首先，咱們一塊兒來看上面這張圖，這張圖是由國際電信聯盟電信標準化部門統計所得，圖中的橫軸座標是毫秒，表明着時延，縱軸座標是用戶的體驗度。由上圖，咱們不難發現，時延達到150毫秒的時候，用戶的體驗度開始降低，當達到400毫秒的時候，用戶的感覺是沒法容忍。由此，ITU-T G.114國際標準規定，延時超過150毫秒錶示已經開始影響用戶體驗，而且用戶能夠容忍的最高延時是400毫秒。

舉個例子，當發生颱風天氣時，電視臺的主持人一般會連線現場的記者，當連線返回現場報道時，基本是過了兩秒左右的時間，現場記者才收到主持人的話，聽衆的體驗感至關很差。相似於上面的狀況基本上是沒法實現實時互動的，想要進行實時互動的關鍵點就在於低延時。我之前也曾經作過八年直播相關的研發，從最初的底層協議到RTMP協議再到如今的WebRTC，用戶需求爲什麼會逐漸從點播域向直播域靠攏，直播流媒體實時音視頻爲什麼會愈來愈關注互動，也正是由於有了低延時，互動才得以慢慢發展出來。

不知道你們是否清楚，爲何流媒體在以前都沒有發展起來這種很好的互動性呢？有不少人認爲RTMP協議很不錯，而且如今外面大部分採用的都是RTMP協議。

既然如此，爲何你們都去研究WebRTC呢？首先，RTMP是基於TCP協議的，TCP是一個安全可靠的協議，它包含了不少機制，如數據的安全保障、三次握手、重傳機制等，可是這偏偏會影響到它的傳輸時間。

舉個例子，我如今手上有一份數據要發送給另一我的，發送過去以後因爲網絡抖動致使丟包。他沒有收到包則會返回一個消息來告訴我他沒收到個人包，這樣就會產生很大的延遲。那麼，能不能直接用UDP呢？三年前的廣電系統，好比北京衛視等採用的是TS流，TS流就是基於UDP的，它的傳輸很是有效。TS傳輸具備高可靠度，流媒體安全且質量好，可是基於UDP都是基於內網的，對網絡的要求很是高。北京衛視也只有內部的網絡所有用的是TS流，採用UDP的協議來傳送，一旦離開公司，就不可行了。由於UDP是不安全的，它沒有重傳機制，沒有各類保障的能力。從上圖中能夠看出，UDP相對來講延時是最低的，但總體質量很低，對網絡的依賴程度也很是高，因此我認爲這是一個成本的問題。在這裏推出一個概念，叫作RUDP（Reliable UDP）。RUDP指的是將TCP和UDP各類優點結合在一塊兒，包含的功能有：

1）冗餘編碼和前向糾錯；
2）場景化的重傳策略；
3）帶寬自適應調整；
4）更優的擁塞控制算法；
5）多點 relay…

簡單解釋一下什麼叫作場景化的重傳，UDP由於沒有重傳策略，對於咱們來講絕對不安全，場景化重傳就是說，若是是I幀這種關鍵幀丟失，那就重傳一個I幀，若是是一個不是特別重要的幀丟失，則不重傳，或者說有一些能夠作同步的信令標準沒有到達，我也不重傳，這樣就能夠極大的優化傳輸效率。

接下來介紹的是WebRTC的核心，你們也能夠在Chrome，Google或WebRTC的官網上找到它的解釋。歸納一下，WebRTC 內核提供的技術能力包括：

• 第一，低延時的音視頻採集編碼和解碼。編碼和解碼是音視頻中最重要的部分，是提供低延時的保證。
• 第二，下降門檻，有瀏覽器的地方就可使用WebRTC；這點我以爲是Google作得很是好的地方，目前微軟、蘋果、Google等都支持WebRTC，除此以外，你們如今手上用的不少硬件設備，都已經支持。最終會達到只要存在瀏覽器的地方都能使用。
• 第三，優異的RUDP傳輸協議；WebRTC本來就是基於UDP的，在UDP上進行優化，能夠更有效的使其傳輸的數據安全、可靠。第四，端到端的協商/建聯框架；在七八年前，端到端上的直播幾乎不可能實現，爲何那時你們看到都是廣電作的直播，而不是互聯網在作直播？緣由是端上的系統度不夠。

此外，WebRTC還提供一系列的業務能力：

• 第一，低延時音視頻垂直領域的發展； 什麼是垂直領域？好比今天分享的主題——教育，就是一個很是垂直的領域，當前在線教育的火爆也正是因爲音視頻技術的發展，能夠真正的實現溝通零距離。所以WebRTC對於垂直的領域很是有效，好比說教育、醫療行業等。
• 第二，就是剛剛提到教育和醫療實時音視頻。第三，互動音視頻，遠程廣電系統；我以前在阿里巴巴爲阿里雲作了一個五地互傳，當時阿里雲在紐約，新加坡，肯尼亞，杭州等都有不少分部，會發現你要把他們放在一塊兒溝通是一件很難的事，當時咱們想到的第一個策略就是用衛星，但衛星的成本真的是高的離譜，而WebRTC就能夠徹底顛覆它，衛星傳輸的質量不如WebRTC是由於WebRTC採用的技術和算法徹底超越了硬件所能帶來的最低延時。第四，海外視頻；WebRTC還有一個最大的業務能力是進行海外跨國傳輸，例如在以前將戛納電影節上的一些活動的內容從戛納傳回來是一件基本不可能的事情，可是如今能夠經過WebRTC實現，固然還要結合一些網絡和語音的相關優化。

2、WebRTC課堂實踐

接下來，從垂直領域來爲你們介紹一下WebRTC在教育行業的課堂實踐中的一些能力，包括電子白板、高質量通信、IM和協做能力。

2.1 在線白板

電子白板是用於解決多人互動場景下，用戶理解和分析的黑板能力。在教育行業中，不管是視頻仍是音頻，都離不開這個白板。在學校裏，對比如今和過去的課堂咱們會發現變化是很是大的，可是隻有同樣東西沒變，就是黑板，因此足以證實黑板有多麼的重要。當我在一塊黑板上面寫字，通常人的作法是將它變成一個視頻而後傳播出去，讓你們看到。可是這樣有一個很大的問題，視頻資源最少須要300kbps的帶寬，這會佔用用戶不少的帶寬，對於資源消耗是很是高的。

咱們作了一件事情，就是讓黑板變成一種描述性的語言。用描述性語言來替代白板，用它來描述白板到底畫了一些什麼，而它所佔的帶寬資源最高是9kbps，也就意味着，它的帶寬消耗是用傳統方式傳輸最低質量視頻這種方式的1/30。這是一個很是偉大的突破，能夠爲客戶節約大量的成本和資源消耗。視頻化白板的體驗問題包括沒法放大縮小、不具有交互能力。但若是它是一個描述性語言，就能夠隨意放大縮小，並保持清晰。另外，對於視頻，我沒法在上面作第二次操做，但描述性語言能夠。在數據擴充性方面，視頻化白板是不好的，因爲視頻內容是非結構化的，致使很難被存儲。

另外，AI是沒法識別視頻索引的。舉例說明，我畫了一隻貓，如今AI的能力還不足以識別它是一隻貓。由於我畫的並非特別有效，所以識別不了，但若是是描述性語言來表示，就能馬上識別出是隻貓。最後是視頻化白板的數據識別轉換低。舉個例子，有些AI公司會將一些視頻中的數學符號識別成了數字，這是由於它沒法識別。但對於描述性語言就能夠輕鬆識別，由於它是一個矢量數據，它能夠體量。這些說明了使用描述性語言改善了白板是有效的，在這裏總結了一下，使用描述性語言白板帶來的好處：

1)  對白板改變進行衝突管理
2)  描述性語言下降整個白板視頻帶寬
3)  下降 CDN 使用成本
4)  回放和錄製存儲要求極低，幾乎能夠忽略
5)  矢量信息可無限放大細節
6)  多端同步，相互備份

2.2 高質量通信

Mesh、MCU和SFU是WebRTC的三種模式，目前能夠說大部分使用WebRTC的廠商都選擇了SFU模式，由於它是最高效的。MCU通常應用於廣電領域，MCU就是不一樣端的推流，都發送到一箇中央處理器上進行混流處理，處理完成後再分發給每一個客戶端。SFU指的是每一個客戶端都推流到服務器，由服務器轉發全部的數據到各個客戶端。若是廣電要用到畫中畫的功能，MCU是沒辦法實現的。通俗的講就是MCU將東西都固定好了，不能進行某一個區域的放大，它在服務端就已經進行了拼合。可是對於SFU，在收到服務器返回的數據流後能夠再隨意進行拼合。Mesh是一個最基本的，相對高質量的模式，但因爲它消耗的資源及帶寬功耗都比較高，因此不會常常用到。

高質量的通信包括畫質、流暢度和協同，畫質包括了編碼方式、碼率和編碼效率，流暢度包括了中間層構建、Plus插件和帶寬優化方案，協同包括配套播放器和衝突管理。那在這裏有幾個問題想和你們分享一下：

• 1)  1.8Mbps 的 720P 清晰度高仍是 3Mbps 的 1080P 清晰度高？
• 2)  H264 Profile Level 決定了哪些要素？用戶體驗是什麼？
• 3)  爲何有些場景下只能用 Profile level 3.1 ?
• 4)  究竟咱們應該使用哪些最優方案去作畫面的匹配？

對於第一個問題，我問了不少人，最後發現一個很神奇的事情，仍是有不少人會選擇3M碼率的1080P的清晰度高。我想跟你們說，Adobe官方有一個推薦，剛開始推RTMP協議的時候，對編解碼也給出了一個標準的推薦值，720P推薦的是1.8Mbps，1080P推薦的是5.5Mbps，只有這樣才能知足相應畫質的傳輸。那麼這個問題的答案也就天然而然了，用3Mbps去傳輸1080P是不知足對應畫質的，看起來的效果不如1.8Mbps 的 720P 清晰度高。

對於第二個問題，H264 Profile有3.0、3.一、4.0、4.1等不一樣level，這些算法依次是複雜程度越高，圖像的精度也越好，這也決定了畫質和效率，而用戶體驗指的是流暢度。對於第三個問題，爲何有些場景下只能用H264 Profile Level 3.1，而它的畫質沒有那麼清晰？舉例說明，有一天小天才的負責人跟我說，他要作一件事情，就是讓孩子的父母能夠用着手錶進行有效的溝通。那這當中有個問題，咱們當時給它設計的是畫質優先，將profile level調到了4.1，結果發現，手錶8分鐘就燙得戴不了，功耗實在是有點高。後來，咱們想到把這種嵌入式設備的profile level降到3.1，因此這就回答了爲何是有些地方情願不須要畫質，而須要它的profile level更高效，這跟功耗有關。

對於最後一個問題，就畫面匹配這件事情來講，究竟是提供一個高profile level的算法，仍是低功耗的性能？這是兩件事情，須要有一些權衡，肯定其中一個有最大化利益。

2.3 IM/AI

在這裏我想給你們講一些案例，就是AI在視頻裏的一些應用。某英語的老闆，給了我一個案例，他說有一個小孩上他們的課，都是一對一模式上課，結果那個小孩上來跟老師說， 「老師啊，那個我不想上課，是我爸讓來的，你該幹嗎幹嗎去吧，我打遊戲去了」。最後，這個課堂只是攝像頭開着，可是兩邊都沒有人，成了一個無效的課堂。

後來，我設計了同樣東西，就是AI在視頻裏面的應用。這個東西就是用一個機制去計算攝像頭的兩端，若是超過一分鐘沒有識別到人臉，那麼它觸發一個報警給到教務，告訴他說，這是一個無效的課堂，你應該管管。

第二個案例，爲了防止高校中的翹課現象，我在課堂上裝一個攝像頭，而後對視音頻進行AI的識別，事先知道每一個人是誰，而後不間斷去識別。若某位同窗進來後，10分鐘以後他從後門溜走致使識別不到他，馬上出現一個報警，表示沒有檢測到某位同窗。

還有一個應用是我在跟浙江傳媒大學一塊兒溝通的時候發現的，中國的教育到如今尚未一個龐大的數據庫，沒有對某一個學生從0到1的分解。舉個例子，如今的探頭在視頻裏的應用能夠偵測不少行爲，我發現上語文課時，有個小姑娘永遠坐在第一排，而且偵測她舉手次數超過30次，而後又發現她上數學課時，永遠在最後一排睡覺。它觸發的是系統自動進行一個大數據分析來告訴說這個女孩是適合文科，而不適合理科的，而後把這個信息交給教務，在這個女孩身上她打了一個標籤，大數據識別出來她適合文科，這就是社會價值、教育的價值。還有就是在教育領域也已經作了的，利用AI來作課堂筆記，在講課的同時，將老師和學生的語音進行語音識別直接轉成了文字，也就意味着，當這個課堂結束，課堂的全部筆記以及老師說的每一句話，已經所有變成一個文檔留存下來。

3、WebRTC 在教育行業的思考

最後，說說咱們在教育行業裏面的思考。第一，傳統教育是解決更多場景化的共性需求。舉一個簡單的例子，場景化教育就是當我有一天站在某個傳統高校的講堂進行演講的時候，該如何幫助提高效率。第二，垂直教育，利用WebRTC能力，構建創新型協做思惟，讓程序員也能夠作教育。第三，PUDC的開放，我認爲如今中國教育仍是有不少機構參與的，但將來會是一個PUDC的時代，每一個人都是老師，每一個人都是學生。最後，智能改變，就是去實現各類AI的教育。