這個 keyword 裡面有兩個單詞, 一個是 multicast (相對於 unicast), 一個是 ABR (adaptive bit rate). 有時簡稱 M-ABR, 是個用來解決網路播放問題的技術.
網路播放怕甚麼呢? 怕大家都看不同節目, 結果頻寬爆掉. 我們可以把這種況狀視為用戶和電視業者中間的一個 unicast. 看到這裡, 聰明的網友可能已經想到, “我們用 multicast 嘛, 千千萬萬用戶只不過看那兩三百台, 我們先把節目弄到中繼站, 每個中繼站都 multicast 給看這台的那群客戶不就好了, 哇哈哈, 我好聰明…" 嗯, 這第一層的想法沒錯.
第二層想法在於客戶家裡的裝置, 必須能夠像 unitcast 一樣自由地操作, 不能說別家看到影片的幾分幾秒? 我就跟著要看幾分幾秒吧! 對
參考來自 [1] 的圖示, 我們看到影片的來源主要是直播 (live content) 或是點播 (VOD) 兩種, VOD 訴求高畫質, live 訴求低延遲. 如果一群觀眾都在看直播 – 例如直播棒球賽好了, 那大家的進度都是一樣的沒錯. 但看電影就不能強求只能看 multicast 了.
因此 M-ABR 的第一個訴求就是降低頻寬, 第二個訴求是使用者不會察覺改變.
- REQ1 – Decrease network usage from ABR content consumption;
- REQ2 – Keep the ABR client devices unchanged
最簡單的方法, 就是在客戶開始操作 time shift 的時候, 把 live 的 multicast 改為 unicast. 怎麼辦到呢? 這需要在網路中加上一些新的設備, 前面提到的 Multicast server 以及 Multicast to unicast proxy.
- Multicast Server – Has 2 main purposes: creating a carrousel with the ABR segments, on a technology similar to DSM-CC (although there’s no repetition of packets) and the retransmission of missing multicast packets.
- Multicast to unicast proxy – This is a home gateway software module, which converts multicast content into ABR segments.
到目前為止, 問題好像都迎刃而解了. 但事實上又不然. 當電視觀眾心血來潮想要倒轉回去看上一局的滿壘三振的時候, multicast server 早就把封包丟出來了, 所謂 proxy 裡面也是空空的, 必須要回到頭端去要 10 秒鐘前的那個碼流.
何況這個 multicast to unicast proxy 總要一點時間比對那幾家的封包需要轉成 unicast 吧! 還有網路總是會掉封包, 假如電視供應商到機上盒中間都不掉包 (透過 DOCSIS), 機上盒到每台電視的網路總是要掉. 整體而言 IPTV 一定會因為掉封包而比 cable TV 有更大的延遲. 在看點播的時候比較不影響, 看球賽直播時, 不免會有隔壁已經放鞭炮, 我家打者還沒揮棒的窘境.
雪上加霜的是, 電視使用者逐漸轉去看網路, 因此每個 note (想像成上述 server/proxy) 對應到的觀眾減少了, 但為滿足客戶需求, 電視頻道變多了. 這表示客戶選到同一台的命中率愈來愈低, 或者說轉成 multicast 的效益愈來愈小.天生的延遲、加上成本效益愈來愈低, 讓這個規格看起來沒啥用.
話雖如此, 還是有人在用這個規格, 那就是 Comcast. 因為 “It only makes sense on legacy cable networks. [1]" 在傳統的 cable TV 上, 前述的延遲比較小, cable 的頻寬又很大 (GPON 給 64 家分, 每家可得 38 Mbps), 這公司又是老字號 S&P500 強, 客戶群夠大, 每個 node 命中率也比較高. 但對於新業者來說, 這篇 reference 的作者就不建議.
[Ref]
Cash Chou's Blog 