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 也能因此降低。
