LiveVideoStackCon 2017 Day 1 專場回顧 —— 多媒體與瀏覽器專場

LiveVideoStackCon 2017 Day 1 專場回顧 —— 多媒體與瀏覽器專場

有幸參加 LiveVideoStackCon 10 月 20 日 —— 10 月 21 日在北京麗亭華苑酒店舉行的音視頻大會，此次大會甄選多媒體開發領域最新技術實踐與應用案例，並設立了 9 大專場。這篇內容主要針對多媒體與瀏覽器專場，進行主要內容回顧。
上午是主題演講環節，已有官方回顧，內容可戳這裏 LiveVideoStackCon 2017 Day 1 精彩回顧

第一場：《高品質互動在線課堂開發實踐》 tutorabc/和君

第一場的講師是現任 tutorabc 前端負責人的和君，擁有 10 餘年先後端研發及架構經驗的他，今天主要圍繞 TuborMeet + 在線雲課堂在實際開發和上線運營過程當中面臨的問題，進行分享。

1、 WebRTC 相關

首先，他圍繞 WebRTC，從內置瀏覽器（無需下載，無需裝插件），開發成本低（簡單的 JS-API 便可實現音視頻通信），開源安全，瀏覽器支持愈來愈好，Flash 將於 2020 年完全退役等幾方面介紹了爲何要使用 WebRTC。介紹了不一樣場景下的技術選型。若是是公開課，大班課場景，採用 WebRTC + 推流技術，支持 10000 人同時在線，支持 RTMP 與 HLS；若是是小班課場景，則採用 WebRTC 會議模式，智能服務切換。

2、優化

接着圍繞在線課堂 Web 前端的特性（相較通常 SPA 交互性更強；用戶的頁面滯留時間長；須要儘量的避免頁面刷新；功能繁複，靜態資源體積很大），提出了相應的優化：

構建時優化

• 基於 webpack 的代碼分割
  • 按業務邏輯拆分多入口
  • Code Splitting
  • 本地化語言包按需加載
• 利用 Webpack3.0 的 Tree-shaking/Scope Hoisting 等特性的打包優化

運行時優化（RAIL 模型）

• 響應：100ms內作出響應
• 動畫：10ms內繪出一幀
• 空閒：最大化空閒時間
• 加載：1000s內提供內容

記一次實際的白板性能優化案例

用戶體驗優化

• 預加載/懶加載
• 響應式佈局
• 漸進式用戶提樣
• 層級管理（z-index）
• Web 安全色、安全字體（保證在不一樣的終端上顯示相同的字體）

4、持續交付的目的，架構圖和技術點

5、前端 APM 所作的事情

• 性能監控
  • 首屏加載：針對 TTFB、Content Download 等關鍵數據的採集
  • 可預期的耗時操做
• 錯誤採集
  • 全量採集："uncaught error"，資源加載失敗等
  • 按需採集："caught errors"
• 業務數據上報展現
  • 週期性上報客戶端 「丟包率」，「網絡延時」

Tips:

• 對上報數據分類、分級
• 儘可能作到「無埋點」
• 聲明式埋點 替代 命令式埋點
• 儘可能作到按需採集，最小化分析時的「噪音」

6、展望及 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 播放器的技術難點與架構探索》 熊貓直播/姜雨晴

1、HTML5 播放器背景

• HTML5 Video 支持
  • Video 標籤支持
  • MSE
  • Adobe 更關注 H5
  • Chrome 屏蔽 Flash
• 校長需求
• HTML5 優點和前景
  • 高效
  • 兼容性
  • 瀏覽器新技術

2、直播領域 HTML5 播放器問題

音畫不一樣步

常見場景：戶外直播是音畫不一樣步問題發生最爲頻繁的版區
問題定位：戶外主播手機性能寄網絡問題致使上行不一樣步
問題改進：採用播放器對軌，進行問題同步

LPL藍光

清洗能量槽（清緩存）

• 何時清洗？
  setInterval VS 新的 gop 準備好
• 清多少？（10秒前）
  從上一次清楚地時間點起，到當前時刻前固定秒數
• 容易洗出什麼問題？
  BufferUpdating 狀態、沒法回退

累計延時

舊版本內核累計嚴重，能夠延遲出 3 - 4 分鐘甚至更長
何時從新拉流？ 卡頓 + 累計延時達到必定閾值

3、熊貓 HTML5 播放器內核構架

4、技術創新與展望

基於如今的播放器內核框架，除了解決播放器內核問題以外，還能夠輕易的將微創新和新技術融入到內核當中。

第四場：《音視頻通話 WebRTC 那些坑》 dotEngine/劉連響

WebRTC 是什麼？

WebRTC 涉及到的模塊

WebRTC client

Signaling

視頻編碼的選擇

一些建議