全民直播時代——基於WebRTC開發實時通訊服務

內容來源：2017年7月8日，又拍雲多媒體開發資深工程師劉博在「不止雲計算，雲時代還有哪些寶典」進行《雲通訊 - 基於 WebRTC 技術的實時通訊服務開發實踐》演講分享。IT 大咖說（id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：1126 | 4分鐘閱讀

嘉賓演講視頻回顧及PPT：suo.im/3zAPJv

摘要

本次分享基於 WEBRTC 技術的實時通訊服務的開發經驗，但願經過此次分享能讓你們對這方面更有興趣。

什麼是互動直播？

互動直播是多路音視頻以及數據實時通訊的解決方案。

首先看一下咱們又拍雲本身的應用場景。又拍雲是由杭州研發總部加上北京、上海、廣州等多家分公司組成的。咱們的管理層每週一上午有個每週例會，咱們很須要一個簡單可靠的遠程會議系統。

在過去，咱們用的是傳統的電話會議硬件，複雜難用，價格不便宜，並且效果也不理想。

如今，咱們只須要一臺筆記本電腦外加一個高清攝像頭就能夠了，不須要任何配置、安裝任何插件。

互動直播的特色

互動直播和傳統直播相比的本質的區別是延時。

與傳統的直播相比，互動直播賦予了參與直播的每個成員互動交流的能力。所以，也對實時性、抗回聲要求更高。

在視頻會議、遠程教育、遠程諮詢、視頻社交、互動遊戲等不少場景每每只能選擇實時性更高的互動直播技術。

爲何選擇 WEBRTC？

WebRTC是一個開源，免專利費的項目，大大節省了咱們的開發時間成本。

WebRTC由Google 主導，技術很是先進。

各大瀏覽器以及終端逐漸加大對 WebRTC 技術的支持。

WEBRTC OVERVIEW

WebRTC全稱是 Web Real-Time Communication。WebRTC 並非一個單一的協議，而是一個標準，包含一堆協議和API。

WebRTC經過提供簡單易用的JavaScript APIs讓瀏覽器擁有了 P2P音視頻和數據分享的能力，同時不須要安裝任何插件。

WEBRTC STANDARDS AND HISTORY

2010年5月，Google花了$68.2million收購了GIPS，一年後Google就開源了WebRTC項目。

WEBRTCW3C Working Group：瀏覽器API；

RTCWEBIETF Working Group：協議、數據格式、安全、P2P等。

WebRTC並非一個孤立的協議。起初是爲了瀏覽器與瀏覽器之間實時通訊，也能夠經過信令協議對接現有的SIP客戶端、PSTN 網絡、移動端等。

WEBRTC的核心組成

音視頻引擎：OPUS、VP8/VP九、H264；

傳輸層協議：底層傳輸協議爲UDP；

媒體協議：SRTP/SRTCP；

數據協議：DTLS/SCTP；

P2P內網穿透：STUN/TURN/ICE/Trickle ICE；

信令與SDP協商：HTTP/WebSocket/SIP. Offer Answer模型。

咱們的實時通訊底層平臺UPRTC

傳統的 WebRTC 應用模式是 P2P 的，咱們改形成服務器中轉的模式。

徹底分佈式系統, 部署到全國全部邊緣節點，經過咱們的內部加速網絡加速。

網絡擁塞自適應控制, 較強的弱網適應能力。

針對底層開源組件進行優化改造，支持高併發。

靈活高效的業務信令，支持對敏感信令進行鑑權。

utun解決跨地區，跨ISP延遲高且不穩定等網絡問題。

覆蓋200多個邊緣節點，4000多臺服務器；覆蓋3個大運營商，2個小運營商。

uprtc實現媒體接入，接入Web端與移動端。

基於咱們底層 UPRTC 平臺的第一個項目——上會

咱們選用的編碼格式H.264 + Opus。修復WebRTC內核 iOS 端有音頻處理過分消耗CPU的BUG，以及修復WebRTC的core音視頻不一樣步的BUG。Android端H.264編碼不支持高通之外芯片硬解碼。客戶端解碼能力有限，總會話人數須要控制在8人之內。服務器端需加入碼率自適應算法，自動根據參與人數控制總帶寬在2Mbps之內。美顏、濾鏡接入會增長處理延時，因此對此性能要求很是高。

我今天的分享就到這裏，謝謝你們！