WebRTC直播課堂實踐：實時互動是核心
隨著低延時流媒體技術的不斷進步，線上教育行業持續升溫。本文來自七牛雲線上教育行業解決方案專家 徐晶在LiveVideoStackCon2018大會中的演講。在演講中他闡述了基於WebRTC架構的低延時直播技術突破以及其在教育行業中的實踐與思考。本文由LiveVideoStack整理而成。
文 / 徐晶
整理 / LiveVideoStack
大家好，我是來自七牛雲的徐晶，非常榮幸可以跟大家分享我所做的一些專案和實踐，本次我要分享的主要內容包括以下幾個方面：
1， 視音訊技術的演進；
2， WebRTC 課堂實踐；
3， WebRTC 在教育行業的思考；
一、視音訊技術的演進
首先，我們一起來看上面這張圖，這張圖是由國際電信聯盟電信標準化部門統計所得，圖中的橫軸座標是毫秒，代表著時延，縱軸座標是使用者的體驗度。由上圖，我們不難發現，時延達到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實現，當然還要結合一些網路和語音的相關優化。
二、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.1、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來做課堂筆記，在講課的同時，將老師和學生的語音進行語音識別直接轉成了文字，也就意味著，當這個課堂結束，課堂的所有筆記以及老師說的每一句話，已經全部變成一個文件留存下來。
三、WebRTC 在教育行業的思考
最後，說說我們在教育行業裡面的思考。第一，傳統教育是解決更多場景化的共性需求。舉一個簡單的例子，場景化教育就是當我有一天站在某個傳統高校的講堂進行演講的時候，該如何幫助提升效率。第二，垂直教育，利用WebRTC能力，構建創新型協作思維，讓程式設計師也可以做教育。第三，PUDC的開放，我認為現在中國教育還是有很多機構參與的，但未來會是一個PUDC的時代，每個人都是老師，每個人都是學生。最後，智慧改變，就是去實現各種AI的教育。
精品文章推薦
技術乾貨：