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

胖淨在掘金發表於2019-02-26
IDE瀏覽器

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 播放器核心構架

四、技術創新與展望

基於現在的播放器核心框架，除了解決播放器核心問題之外，還可以輕易的將微創新和新技術融入到核心當中。

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

WebRTC 是什麼？

WebRTC 涉及到的模組

WebRTC client

Signaling

視訊編碼的選擇

一些建議

相關文章