來源：Global Video Tech Meetup：Milan
主持人：Andrea Fassina
演講者：Behnam Kakavand, Alexey Malikov
整理：李昊勇
這次會議主要包含四個主題：WebAssembly 作為網絡播放的可能性；一個視訊 DRM 系統的工作原理；基于實時邊緣記錄和 CMCD KPI 的視訊監控面闆；OTT/IPTV 視訊内容傳輸品質的提升。本文将介紹其中的第一段和最後一段演講。
目錄
- 開場
- 展望未來：WebAssembly 或成為網頁播放的一種方式
- OTT/IPTV 視訊内容傳輸品質的提升
開場
會議由來自 videodeveloper.io 的 Andrea Fassina 主持。他首先回顧了上一期（6th Milan Meetup）中的内容：直播、資料品質、可互動體積視訊以及智能編碼，并簡介了本場會議的其他三位嘉賓：來自 Evolution 的 Behnam Kakavand、來自 Akamai 的 Luca Moglia、來自 Elecard 的 Alexey Malikov。
展望未來：WebAssembly 或成為網頁播放的一種方式
這段演講（1:37-17:21）的主講人 Behnam Kakavand 是 Evolution 公司的首席視訊工程師，從 2010 年他就開始從事視訊點播和直播行業。
實時視訊現在處于行業的核心位置，為了産生并傳遞實時視訊内容，演講者搭建了他們自己的視訊平台，來為浏覽器、安卓提供視訊内容。他使用 Websocket 來連接配接安卓和浏覽器，端到端延遲在 1.5-3s 内，并使用 MSE(Media Source Extensions) 來進行播放。而在 Iphone 平台上則使用的是 HLS，延遲在 3.5-7s 的範圍内。由于這項技術的場景是使用者與推流端的頻繁互動，延遲是十分關鍵的。
什麼是 WebAssembly
WebAssembly，也就是 WASM，是一個跨平台二進制标準的用于在任何浏覽器、裝置、平台上運作預編譯的代碼的平台。預編譯代碼也就意味着是優化過的，低延遲的代碼。相比于 JavaScript，有着 3-4 倍更好的運作速度方面的表現。同時你也可以自由地選擇它的後端語言，如 C，Rust，Go 等。這就意味着你在範圍非常龐大豐富的開源庫裡進行選擇，并将他們作為新的功能加入你的浏覽器應用裡。
為什麼使用 WASM 播放器
演講者選擇 WASM 來開發他們的播放器主要有以下原因：
- 希望在全平台上都保持流和延遲等服務内容的一緻性。
- 為了有更直接地通路到解碼函數，獲得一個全局的控制，包括緩存控制、丢包和丢幀控制等功能。
- 更直接地管理對于各種編解碼器的支援，以及對傳輸協定的選擇。
- 蘋果的 LL-HLS 可以把延遲控制在 2s 的範圍下，但僅此而已。而演講者的延遲目标在 1s。
- WebRTC 在編碼器方面受限，必須要使用基礎配置檔案，導緻了更大的品質和帶寬需求。
使用浏覽器自帶功能
演講者繼續介紹了浏覽器自帶的一些功能。HTML5<video> tag 會擷取源 URL 位址并控制整個 pipe 視訊流，然而對播放不同部分它的控制範圍卻是有限的，并且在不同的浏覽器上，HTML5 的部署都存在着一些不同，更為麻煩。MSE(Media Source Extension) 會整合輸入源并控制播放的幾乎所有部分。
使用自定義部分
演講者介紹了播放器中自定義的部分：WASM 和 WebGL。WASM 可以配置任意的視訊編解碼器、可以有自定義的緩存控制來達到低延遲播放，也可以自由選擇傳輸協定。由于 WASM 使用的是軟體編解碼，沒有硬解碼加速支援，導緻其耗電會更高一些。且由于要傳輸的是整個更大的包含編解碼的二進制代碼，是以傳輸的内容大小也會更大。WASM 還可以使用各類開源的編解碼器，如 VP9 和 AV1，這類編碼器并不是在所有浏覽器上都被支援的。而 WebGL 則可以用于個性化渲染以及色域空間管理等。
接下來演講者介紹了播放器的工作流程。首先他們使用 Emscripten 編譯的基于 C 的解碼器庫，并基于這些庫去編譯他們的播放器。JS 導入 WASM 檔案并用于同步，輸入位元組緩存并讀取像素緩存，最終通過 WebGL 渲染像素。他還展示了編譯 libav 所使用的 emscripten 的配置。
WASM 播放器組成
關于 WASM 播放器的組成部分，如上圖所示。其中主線程在運作在播放器上的 JS 的前端線程，用于給使用者進行互動操作。另一個線程裡的 WebSocket 用于操作傳輸協定，以及另一個線程 WASM Decoder 用于解碼視訊流。
目前的結果
演講者最後展示了他們的播放器延遲效果，可以看到隻有 0.9s 的端到端穩定延遲，而他們目前的産品播放器延遲有 1.8s。此外還有無縫的自适應碼率切換功能，可以在 iOS，Android 和桌面環境上運作。
演講者将來的計劃包括了使用共享向量記憶體，使用 WASM SIMD，離屏桌面和音頻類别組來進一步提升性能，也就能進一步能夠優化電池消耗。此外進一步減小播放器包大小也是一個優化方向。
OTT/IPTV 視訊内容傳輸品質的提升
本段演講（38:26起）的演講者 Alexy Malikov 是 Elecard 公司的工程師。
要提升服務品質，首先就需要監測目前的傳輸品質，是以就需要一個分布式監測方案。通常來說分布式監測包含幾個部分：一個中心伺服器和分布式的用戶端應用或者硬體。在網絡中需要這樣的監測方案是因為在 OTT/IPTV，通常（包括供應商）有多個使用者端，由于他們供應的内容常常會因為被衛星上傳或下載下傳過程中被改變品質，便需要一種方法來得知最終接收到的品質狀态。
接下來演講者介紹了幾種真實遇到的場景和對應的解決方案。
Case1: 使用者的信号被遮擋，TV 畫面在廣告插播時卡死
Case1
演講者安裝了兩個探測器，一個在轉碼拼接器之前，另一個在 DVB 調制器之前。其中在轉碼部分監測到的碼流沒有問題，而在後面的調制器監測到視訊流的參數與主視訊流參數不同。這是一種很經典的錯誤，稱為“視訊資訊變化事件”。
從他具體展示的監測畫面可以看到，是由于廣告畫面比例為 16:9，而先前播出的視訊内容為 4:3，部分使用者裝置無法直接适應這個變化，也就導緻了視訊流的卡死，影響了觀看體驗。
Case2: 視訊流完全無法被使用者進行接收
Case2
在這個案例下，内容分布式網絡包括了衛星鍊路，并且已經有探測器安裝在多處，包括解調器後和轉碼器後。通過檢測發現，衛星解調器會時不時地不正常工作。
在檢測畫面可以直覺地看到在解調子產品不工作時，會直接沒有波形的顯示。而解決方案也很簡單：直接将整個解調子產品更換即可。
Case3: 用戶端播放器停止工作
Case3
這裡是一個很大的供應商在為城市的各個區域提供業務。演講者安裝了非常多的探測器，包括在轉碼分發，以及在 CDN 前後，甚至是各個區域級的 CDN 前後都有安裝探測器。在一些區域的 CDN 邊緣，演講者探測到有些 HLS 廣播片段丢失，且下載下傳速度過低無法滿足實時需求。
在監測畫面可以直接看到規律的波形在一些片段的空白，就是 HLS 片段丢失的結果。
Case4: 電視信道不可擷取或嚴重受損
Case4
在這個場景下，演講者在轉碼前，衛星調制器前和衛星解調後，端到端都安裝了探測器，并觀察到在傳輸層上有大量的資料錯誤丢失。
在監測畫面可以看到傳輸的包到達間隔，丢包率的變化，在一天的相同時間會發生信号的丢失。在經過調查後他發現這是由于兩個衛星之間的信号幹擾導緻的，最後通過更改衛星的調制頻段解決了問題。
Case5: 使用者訂閱端沒有聲音
Case5
演講者在供應商側轉碼器的前後以及使用者端 DVB 解調器的後面設定了探測器，而在轉碼器前的信号輸入的探測器上，發現了音頻信道的 PID 丢失。
而在監控圖上可以清晰地看到音頻信号丢失，沒有它的負載包。是以這個問題回報給了供應商後便迅速得以解決了。
Case6: 一個供應商的畫面卡頓
Case6
在此演講者在轉碼器前後以及 CDN 後設定了探測器，而在轉碼器前的資料就有很大問題。
在監控圖上可以更明顯地看到轉碼器的信号沒有辦法成為輸入，導緻了畫面的當機，即使在之後信号恢複了，轉碼器還是沒有辦法回到正軌。最後直接通過更換了轉碼器子產品來解決了這個問題。
附上會議視訊：
http://mpvideo.qpic.cn/0bc3veaasaaalqamebxtvbqvbkodbguqacia.f10002.mp4?dis_k=4d0100fe20fc264759d75f81606847f6&dis_t=1645152790&vid=wxv_2244374462395793417&format_id=10002&support_redirect=0&mmversion=false