rtc/webrtc 2017實時音視頻大會分享

Share of RTC2017

Walker.Xu

RTC2017

RTC實時互聯網大會在美國已成功舉辦8屆，是全球範圍影響最大最權威的實時通訊行業技術會議。該會議吸引了來自全球數萬名開發者和技術大咖參加，Google、Ericsson、Oracle、Intel、Agora.io、Mozilla、Avaya等公司均曾在大會上分享過各自在實時通訊領域的技術、應用與經驗。

RTC2017由聲網Agora.io主辦，CSDN和Allthingsrtc.org協辦的在亞洲的第3屆盛會，也是亞洲惟一最權威的RTC實時通訊行業技術會議。
1.商業目的，生態鏈
2.技術，應用交流

參會目的

1.學習，瞭解RTC行業的先進水平
2.開闊思路，瞭解音視頻技術，實時音視頻技術的發展方向

實時音視頻應用場景

社交

微信，QQ，陌陌，face u，holla，house party，facebook

直播，連麥

熊貓TV，YY，映客，花椒，荔枝FM(語音直播，萬人連麥)，twitch

遊戲

王者榮耀，狼人殺，飯局狼人殺，棋牌類遊戲

在線教育

滬江CCtalk

其餘：醫療，金融服務，工具類，會議類
遠程助手，slack

實時音視頻技術扮演的角色

1.創造應用場景，沒有實時音視頻技術就沒有這個用戶場景，社交視頻語音聊天，直播連麥，各類狼人殺，在線課堂
2.加強應用體驗，王者榮耀語音，棋牌類遊戲
3.跨界，行業融合，直播連麥社交，狼人殺是遊戲也是社交，twitch，熊貓是直播跟遊戲密不可分

咱們出不去，別人進不來

硬實力軟實力

南亞，東南亞

北美，美國：3.23億，加拿大：3628萬
東亞，東南亞，南亞，非中國大陸，越南：9270萬，泰國：6886萬，馬來西亞：3118萬，印度尼西亞：2.611億，菲律賓：1.03億，巴基斯坦：1.93億，孟加拉國：1.7億，印度：13.24億，日本：1.27億，韓國：5125萬，臺灣：2349萬，新加坡：560萬，香港：737萬
中國大陸：14億
中亞：7000萬

實時音視頻技術，應用生態（組成）

1.標準組織
2.研究機構
3.技術框架聯盟，通常大公司牽頭髮起，開源社區
4.技術實現，質量監測，數據分析等服務提供商
5.開源應用，技術框架
6.行業應用

實時音視頻技術，應用生態(國內外差別)

1.國內RTC

騰訊，YY爲表明的，從技術到服務到應用都本身幹
Agora.io爲表明的技術，服務提供商，服務了陌陌，face u，holla，熊貓TV，小米，cctalk等
技術體系私有，或webrtc變種
一個供應商解決全部問題，快速反應，提供保姆式服務，國情決定

2.國外WebRTC

IETF:國際互聯網工程任務組（The Internet Engineering Task Force）
W3C
CoSMo Software Consulting: webrtc research and api test of browsers
Google: add GIPS to webrtc and open source
Callstates.io: webrtc a/v quality monitor service
Jitsi
Slack
Twitch
Facebook
生態比較多樣，分工較明確

實時音視頻與新技術的結合

實時音視頻技術是一個技術平臺能夠將不少新的多媒體技術融合進來，進行組合，創造新的應用場景
1.AI：小米音箱
2.AR
3.VR+人臉識別
4.holographic projection:全息投影, art media直播+全息投影
5.全景聲技術：dolby atoms

實時音視頻技術

What？

RTC, real time communication, webrtc是RTC的一種

Why?

咱們不是有http,https,hls,rtsp,rtmp嗎，爲何還要開發實時音視頻技術
簡單來講就是不知足進行實時音視頻通訊的要求
1.延時低
2.雙向／多向

Http, https,hls延時10s左右，pass
rtmp延時1~3s還不錯，進行實時音視頻通訊還差點意思，pass
rtsp的延時能夠作到0.5s，基本知足需求，可是它不是爲雙向設計的，實現起來很複雜，並且網絡穿透能力差

RTC延時

webrtc爲例實驗室200ms之內，比較好的網絡300ms之內，遠程助手基於webrtc實現的，單向延時能夠作到300～400ms在魅族網絡
商業公司的延時基本作到在全網400ms

1.客戶端

傳輸

傳輸質量測量，智能網絡接入(就近接入)，流控(flow control)，帶寬估計，擁塞控制(congestion control)，弱網對抗
Packet loss,RTT,丟包重傳,jitter buffer

編解碼

Opus,agora solo
H26x:H264,H265
VPX:VP8,VP9
編碼的壓縮率，抗丟包，丟包隱藏，FEC，動態碼率(QP)，幀率設計，I幀間隔，動態分辨率，B幀
SVC: scalable video coding
可分級的視頻編碼(Scalable Video Coding)
出現的緣由 主要解決網絡傳輸視頻信息的時候,帶寬限制了數據的傳輸,而咱們經過某種方法使得視頻流擁有可分級性,當網絡帶寬較小的時候,只保持基本的視頻信息被傳輸,並根據實際的網絡環境決定是否傳加強的視頻信息以使得圖像質量獲得增強,以此獲得自適應性.這樣的方式能夠保持擁有網絡鏈接的大部分終端均可以以適當的碼流來使用多媒體信息,而不考慮原碼流的需求.

先後處理

回聲消除，噪聲抑制，增益控制，可懂度加強，聲音美化／變聲，空間音頻，盲源分離
美顏，濾鏡，降噪，平滑，銳化，error concealment，人臉識別

兼容性處理（Android platform mainly）

市面上幾百款手機，魅族支持遠程協助的有20多款

流控flow control

是用於控制發送方的速度，防止接收方緩存溢出，它的侷限性顯而易見，只有在特定限制條件下才有意義，如圖1
擁塞控制是在擁塞發生時控制進入網絡的數據量，相對複雜，GCC同時使用基於時延(delay-based)和基於丟包(lost-based)的兩種算法應對帶寬網絡的擁塞控制，這兩個預測控制組成了速率預測控制器如圖2
delay-based算法由數據的接收方實現，接收方須要記錄每一個數據包到達的時間和大小，並計算每一個數據分組之間（inter-group）的延遲的變化，由此判斷當前網絡的擁塞狀況，並最終輸出碼率估計值由RTCP feedback（TMMBR或 REMB）反饋給發送方；loss-based算法則由數據的發送方來實現，發送方經過從接收方週期性發來的RTCP RR（Receiver Report）中獲取丟包信息以及計算RTT，並結合TMMBR或REMB中攜帶的碼率信息算得最終的碼率值，而後由媒體引擎根據碼率來配置編碼器，從而實現碼率的自適應調整。如圖3。能夠看出，這兩個算法在系統中並非孤立存在的。

QP

降噪 & 自動增益

SVC

Agora solo

2.後臺

傳輸，骨幹網絡，時髦叫法雲

全球網絡覆蓋(跨洲，跨國，誇網，誇運行商)，CDN ，高併發，高可用(可用度，容災性)，應用專網(路由選擇)

SFU/MCU

NAT(network address translation)，STUN/TURN，ICE

SFU/MCU

Bandwidth & CPU are limited in a device

smart way

NAT

STUN/TURN

3.信令

信息數據交換，sdp，ice options
呼叫和消息系統，Websocket，SIP
信令通道在數據通道以前創建
其餘做用，好比傳遞一些設備，狀態信息

4.評價體系

指標，perfect/good/acceptable/bad/mess
測試環境／工具／資料／應用場景／人
大數據，監測統計，在實際使用環境中評估
高大上的音視頻實驗環境

評價體系 實踐

用其餘手段代替昂貴的器材
指標 測試環境 大數據，實際使用環境

實時音視頻技術，挑戰

重要或緊急的事情，第一選擇，打電話

質量，質量，質量

1.接通率 （業內先進水平失敗率<=2%）
2.音視頻體驗 （作的不錯）
卡頓，模糊，馬賽克，數據丟失

實時音視頻技術，大規模直播+連麥的解決方案

1.普通的直播RTMP能夠實現
2.須要連麥，須要實時音視頻技術的介入，主播和其餘連麥用戶經過　RTC技術實現實時音視頻互動，再經過RTMP把連麥現場直播出去

Leningrad

1.適配了20多款機型

M。。。

2.系統版本

Android5.0~Android7.1
flyme5~flyme7
【應對了Android跨版本,flyme框架,不一樣屏幕分辨率等兼容性問題的挑戰】

3.服務業務

用戶幫助
安全家庭
遠程監控

4.打通了瀏覽器端

chrome and firefox

5.欠缺

迭代不持續，不夠專一；後臺能力.

Normandie(音視頻sdk)

1.適配了meizu所有幾十款機型

2.系統版本

Android4.2~Android7.1
yunos
flyme4.5~flyme7
【應對了Android跨版本,flyme框架,不一樣屏幕分辨率等兼容性問題的挑戰】

3.服務業務

Music音樂，主題功能+定製需求好比drm，代理，副歌等，日活100萬，月活千萬
News諮訊，在線短視頻播放，cp重要有360(640x360),UC(852x480),快手(960x720)，360,UC能夠作到秒播，快手在1～2s內起播，千萬用戶
趣視頻，在線短視頻播放

4.欠缺

迭代不持續，不夠專一；部分業務沒有推廣成功.

總結，三個階段

1.從0到1，實現咱們的基本設想，知足最初的需求

【作不出來，die】

2.生存，在具體產品上應用，達到必定要求，上線運行，實現更多需求

在更多機型上落地，在穩定性,功能,性能方面達到必定的要求，知足現階段業務需求，而且部分指標不落後或不大幅落後市面上比較先進的產品
【作出來沒人用，die】

3.發展，持續迭代，升級，優化，技術上看着業內第一梯隊向業內第二梯隊靠攏

多看多想，擴展更多產品形態和場景
從業務上也對咱們提出了更高的要求，業務上會直接和競品對比，業務或用戶不會關心你的團隊或資源，只關心體驗結果，能不能有好的體驗
【用戶用起來不爽，不能與竟品競爭，die】
從目前看，咱們基本知足生存的第二個階段，努力向發展的第三階段靠攏，這個階段對咱們自身提出了更高的要求須要更深刻的學習和積累，創造機會抓住機會不停的學習

上策中策下策

平臺

產品

需求／功能

生命越長越專一價值越大

Thanks

聲明：借鑑了不少大會上大神的ppt