Demuxed 2019|低延遲串流大戰開打,現階段你不可不知的關鍵技術!
前言:
這次 Demuxed 除了一如往常的技術議題外,還特別強調 “Re-Union of Video Tech Meetup”,會前一個月左右主辦方就主動寄信告知,表明希望可以幫各個結盟社群製作貼紙,活動期間更是熱情介紹每位來自不同城市的主辦人,甚至在會後聚集全球的主辦代表一起合照。
我們可以很驕傲地說,在亞洲區 Taipei Video Tech 是唯二 (with Tokyo) 與世界串連在 Video Streaming Industry 的城市呢! :D
一到活動現場,就看見主辦方為全部 Video Tech Meetup 製作的貼紙,目前約有來自 20 個城市的結盟社群。
會後全球各地主辦代表大合照,眼尖的人是否覺得正中間那位有點眼熟呢?他是美劇 Silicon Valley (矽谷群瞎傳) 主角之一,這部美劇是用搞笑的方式來 kuso 影音串流的創業,相當符合 Demuxed 的主題,看到張照片,你是不是也覺得主辦方相當用心,連大牌演員都找來了!
2019 串流技術重點主題:Low Latency Live
承前記所提,今年 Demuxed 充滿 Live 的氛圍,有將近 1/3 的 Talk 都圍繞在Live主題,其中 Low Latency 更是話題性最高的重點,如果說 Low Latency 是繼 Video Codec 後最為混亂的局面,一點也不為過。我們來盤點一下目前的技術有哪些:
- CMAF and DASH/HLS Ingest
- LL-HLS
- LHLS
- DASH-LL
- WebRTC
- SRT (Secure Reliable Transfer)
- HTTP over QUIC (HTTP/3)
是不是覺得眼花撩亂,看起來很像又好像不一樣呢?事實上裡面很多是近一兩年才剛正式發表,我覺得其中一個很大的驅動力是歐美球賽轉播需求持續攀升,傳統延遲 (30~40 秒) 根本無法滿足使用者,於是在串流技術逐漸成熟後大家便投入研究延遲優化,才會在今年開始爆發,從網路層到 Streaming Protocol 討論都很熱烈!
此次活動分享主要在介紹1~4 項技術 (這一兩年發表的):
CMAF and DASH-IF Live ingest protocol
有在做 Live/Linear Streaming 的人對 RTP/RTMP 這兩個 streaming protocol 一定不會陌生,這兩個 protocol 一般會用在 On-premise Encoder (俗稱的地端) 到 Live Encoder (Cloud 雲端)。
- RTP: 基於 UDP 上做傳輸,優點在絕對即時 (realtime),缺點是會有 packet loss 的問題,一般會建議搭配 FEC (Forward Error Correction) 使用,但是需要額外的頻寬。
- RTMP: 基於 TCP 做傳輸,在一開始的 handshake 做完後,Server 即可一直推送內容到用戶端 (Client),優點是維持 realtime 外,且能保證傳輸的畫質,因為不會有 packet loss,缺點是會造成 accumulate latency,一旦中間傳輸遇到頻寬問題,就有可能增加 latency,而且會持續性的增加。
在 End-to-End 低延遲的需求下,地端到 Live Encoder 的延遲會是第一考量,因為如果在這環節上產生延遲那就沒救了,也因此 RTP/RTMP 即使是舊時代的產物也還是持續用到現在,但在今年,也許大家可以稍微轉移目光,關注一下 DASH-IF 組織正在研擬的一份 SPEC (Specification of Live Media Ingest),要透過 HTTP Push (HTTP/2) 的方式,結合 CMAF ingest 和DASH/HLS ingest 技術,同時做到有 RTP/RTMP 一樣的即時性,並解決這兩個 protocols 上的缺點。
簡單架構圖大致如下:
CMAF Ingest 一般會應用在需要 Live Transcoder 的案例上,將 CMAF 來的 source 重新轉碼成新的 ABR ladder (1080p+720p+480p+…) 而後再放到 Origin server 做 Streaming out,而 DASH/HLS Ingest 的應用案例則是沒有 Live Transcoder 直接 Ingest Source (已經是壓好的 ABR profiles)到 Origin server 上做 Streaming out。
使用此種方式將能直接應用原先在 CMAF/DASH/HLS 上定義好的 subtitle、SCTE-35 (廣告 cue tone)、timed metadata,甚至是 Encryption (DRM),直接擴增 Live ingestion 所需的功能。
然而,這個做法遇到的挑戰會有兩項:
- 1.) 主副訊號的 Failover,如何確保兩邊時間是一致的,以及需要地端的 Encoder 支援這個格式並使用。
- 2.) 在目前大多數已經設置好的機器下,要變更會需要好長一段時間,畢竟沒問題沒有人會想去動它,除非有類似 Migration 破壞式的更新發生。
直播串流三大技術分析摘要
“Three Roads to Jerusalem” Talk 的講者為 Akamai 的 Chief Architect, Will Law (他同時也是 DASH-IF 的 Vice President,在社群中相當活躍),他把目前檯面上的三個 low latency protocols (Origin server -> CDN -> Player),做了技術上的介紹與比較:
- LL-HLS: Apple 在 2019 WWDC 大會上發表的新 Specification,在 iOS 13 會有官方支援。
- LHLS: 由社群 JW, Wowza, Mux, Elemental, Akamai and etc… 協同開發。
- DASH-LL: 由官方 DASH-IF 提出。
比較如下:
- LL-HLS: 走的是 HTTP/2,可以透過 HTTP/2 Push 的機制在同一個 connection 上做傳輸,能降低一定程度的 RTT time (Difference #4),但是因為不走 Chunked Transfer,可預期 HTTP request 量會很大。同時在 spec 設計上多了一些 LHLS/DASH-LL 沒有的 Description,比如說 Internal Segment Description,能降低 startup delay。
- LHLS and DASH-LL: 走的是 HTTP/1.1 搭配 Chunked Transfer,相容性較高,且因為使用 Chunked Transfer 能有效降低 request rate (Difference #3),然而走 chunked transfer 也不見得沒有問題,講者提到最大的困難是 “Bandwidth Estimation” 會遇到挑戰,意思是不容易做好 Adaptive algorithm,雖然有解決方案,不過可能會遇到專利問題。
結論:低延遲直播技術大戰正式開戰!
可以明顯感受到 Low Latency Live 正進入面對面的交鋒大戰,三種格式有其各自的優勢及缺點,如果你要在不同的環境下有最好的結果,可能需要同時支援這三種格式,但要是你沒有壓力需要立即導入 Low Latency Live 的話,不妨再觀察一下,在白熱戰後也許格式會整合統一或是某種程度的收斂,支援的 effort 也能因此降低。