LiveVideoStackCon 2017 Day 1 專場回顧 —— 多媒體與瀏覽器專場
有幸參加 LiveVideoStackCon 10 月 20 日 —— 10 月 21 日在北京麗亭華苑酒店舉行的音視訊大會，這次大會甄選多媒體開發領域最新技術實踐與應用案例，並設立了 9 大專場。這篇內容主要針對多媒體與瀏覽器專場，進行主要內容回顧。
上午是主題演講環節，已有官方回顧，內容可戳這裡 LiveVideoStackCon 2017 Day 1 精彩回顧
第一場：《高品質互動線上課堂開發實踐》 tutorabc/和君
第一場的講師是現任 tutorabc 前端負責人的和君，擁有 10 餘年前後端研發及架構經驗的他，今天主要圍繞 TuborMeet + 線上雲課堂在實際開發和上線運營過程中面臨的問題，進行分享。
一、 WebRTC 相關
首先，他圍繞 WebRTC，從內建瀏覽器（無需下載，無需裝外掛），開發成本低（簡單的 JS-API 即可實現音視訊通訊），開源安全，瀏覽器支援越來越好，Flash 將於 2020 年徹底退役等幾方面介紹了為什麼要使用 WebRTC。介紹了不同場景下的技術選型。如果是公開課，大班課場景，採用 WebRTC + 推流技術，支援 10000 人同時線上，支援 RTMP 與 HLS；如果是小班課場景，則採用 WebRTC 會議模式，智慧服務切換。
二、優化
接著圍繞線上課堂 Web 前端的特性（相較一般 SPA 互動性更強；使用者的頁面滯留時間長；需要儘可能的避免頁面重新整理；功能繁複，靜態資源體積很大），提出了相應的優化：
構建時優化
- 基於 webpack 的程式碼分割
- 按業務邏輯拆分多入口
- Code Splitting
- 本地化語言包按需載入
- 利用 Webpack3.0 的 Tree-shaking/Scope Hoisting 等特性的打包優化
執行時優化（RAIL 模型）
- 響應：100ms內做出響應
- 動畫：10ms內繪出一幀
- 空閒：最大化空閒時間
- 載入：1000s內提供內容
記一次實際的白板效能優化案例
使用者體驗優化
- 預載入/懶載入
- 響應式佈局
- 漸進式使用者提樣
- 層級管理（z-index）
- Web 安全色、安全字型（保證在不同的終端上顯示相同的字型）
四、持續交付的目的，架構圖和技術點
五、前端 APM 所做的事情
- 效能監控
- 首屏載入：針對 TTFB、Content Download 等關鍵資料的採集
- 可預期的耗時操作
- 錯誤採集
- 全量採集：”uncaught error”，資源載入失敗等
- 按需採集：”caught errors”
- 業務資料上報展示
- 週期性上報客戶端 “丟包率”，“網路延時”
Tips:
- 對上報資料分類、分級
- 儘量做到“無埋點”
- 宣告式埋點 替代 命令式埋點
- 儘量做到按需採集，最小化分析時的“噪音”
六、展望及 roadmap
第二場：《基於 Intel® CS for WebRTC 構建高效可擴充套件的 RTC 服務》英特爾/段先德
Interoperability: Participants talk in different protocols
- WebRTC,SIP,RTSP/RTMP,etc.
- Various codecs.
Adaptability: Participants through different devices
- Phones,tablets,PC,wearables,etc.
- Domain-specific devices such as class-room systems and medical devices.
Connectivity: Participants behind complex networks
- NAT traverse
- Nearby access
- Packet loss/jittering handling
Customizability: Participants accept/prefer different audio/video formats and parameters
- Audio/video transcoding
- Specifying video parameters
- Multiple-view
Reliability
- Fault of one call/conference should not impact other calls/conferences
- Fault of media processing nodes should be detected and recovered automatically
- Fault of access nodes should be detected and notified to impacted clients
Availability
Clustering deployment with redundancy backup
- Scale in/out demand
- Customizable scheduling policies
Principles in Design
- Decouple components
- Crash-oriented architecture
- Unified control primitives
- General media spreading model
Decouple Logically and Physically
- The IO parts vs. the computation-intensive parts(IO 密集型與計算密集型分開,做更精細的 Scaling)
- The signaling parts vs. the media parts
- The media-access parts vs. the media-proce
Keep Crash in Mind
Control primitives on media components
- via PRC over RabbitMQ
- Publish, Unpublish
- Subscribe,Unsubscribe
- Linkup, Cutoff
- Generate, Degenerate
The Stream Spreading Model
A scalable RTC engine
Intel Collaboration Suite for WebRTC
Case Study
- 愛奇藝
- Interactive show broadcasting —— 奇秀直播
- Internet meeting —— 愛奇藝會議
- Zealcomm PureRTC
第三場：《直播 HTML5 播放器的技術難點與架構探索》 熊貓直播/姜雨晴
一、HTML5 播放器背景
- HTML5 Video 支援
- Video 標籤支援
- MSE
- Adobe 更關注 H5
- Chrome 遮蔽 Flash
- 校長需求
- HTML5 優勢和前景
- 高效
- 相容性
- 瀏覽器新技術
二、直播領域 HTML5 播放器問題
音畫不同步
常見場景：戶外直播是音畫不同步問題發生最為頻繁的版區
問題定位：戶外主播手機效能寄網路問題導致上行不同步
問題改進：採用播放器對軌，進行問題同步
LPL藍光
清洗能量槽（清快取）
- 什麼時候清洗？
setInterval VS 新的 gop 準備好 - 清多少？（10秒前）
從上一次清楚地時間點起，到當前時刻前固定秒數 - 容易洗出什麼問題？
BufferUpdating 狀態、無法回退
累計延時
舊版本核心累計嚴重，可以延遲出 3 – 4 分鐘甚至更長
什麼時候重新拉流？ 卡頓 + 累計延時達到一定閾值
三、熊貓 HTML5 播放器核心構架
四、技術創新與展望
基於現在的播放器核心框架，除了解決播放器核心問題之外，還可以輕易的將微創新和新技術融入到核心當中。