Cash Chou's Blog

這個 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]

1. https://technedigitale.com/archives/1181

根據 WIKI, Emulator 分為 hardware [1], software [2] 兩種. Hardware Emulator 是用 hardware 去模擬 IC 硬體, software emulator 則是用軟體去模擬 IC. 後者比較單純, 以我用過的 Analogic Device 的 DSP emulator, 只要設定 SRAM 的 delay cycle, 就可以知道自己寫的程式在 IC 能否跑得動.

而在 WIKI 的定義中,  ICE (In Circuit Emulator) 算 HW emulator, 但 FPGA (Field Programmable Gate Arrays) proto-typing 不算 HW emulator. 問題不出在 FPGA 不能當 HW Emulator, 而是出在 FPGA proto-typing 和 HW Emulator 有差距.

知乎這篇 [3] 說到, FPGA proto-typing 和 HW Emulator 的本質不同

1. HW Emulator 可以處理的 gate 數較大, 即使要驗的電路變複雜, 也不像 FPGA 那樣 routing 愈複雜就跑得愈慢.
2. HW Emulator 是由 CAD 提供一整套系統. 而 FPGA 買回來之後通常是 HW SD 做一張板子, IC designer 提供特製的 RTL 跑出來的 bitfile 檔. 為了配合 FPGA 的先天限制, 連 IC 的功能都不會完整放上 FPGA. 例如實際上跑 4 核 CPU, FPGA 上只放一核.
3. “emulator可认为是软件simulator的硬件化，是虚拟世界；FPGA prototype是物理芯片流片前的原型化，是真实世界。" 這句話直接引用 [3]. 雖然兩者的 clock 都不夠真實, 但 emulator 下所有 IP 的 clock 能維持相對比例, 例如 CPU 可以模擬 1.5GHz, 並切搭配跑 700MHz 的 GPU. 但 FPGA 上的 CPU 就是和其它 IP 一樣都跑 MHz 等級.

三大 CAD 公司都有 Emulator 的產品, Cadence Palladium, Synopsys ZeBu, Mentor Veloce. 有趣的是,  Palladium 用特製的 processor 來實現, Veloce 用 ASIC 來實現, 而 Zebu 就是用 Xilinx 的 FPGA 來實現. 難怪 HW SD 會說: “你就把它想像成一個超大的 FPGA."

Emulator 還有不同的操作模式:

1. Stand-alone: 全部電路在 emulator 中單獨跑.
2. ICE: 待測電路放在 emulator, 透過  speed bridge 接到高速週邊 USB 等等.
3. Co-simulation: 和 server 上的 sw simulator co-sim. 例如模擬 Android 跑在 IC 上就有可能用到.

先筆記到這裡.

[Ref]

1. https://en.wikipedia.org/wiki/Hardware_emulation
2. https://en.wikipedia.org/wiki/Emulator
3. https://www.zhihu.com/question/47732296

上次寫了一篇 HDCP 相容性的筆記, 引起一些網友發問. 最近又浮出 Miracast 的客戶, 只好再研究一下, 順便拋磚引玉.

HDCP 分為應用於 on HDMI 以及應用於 Interface Independent (AV stream) 兩個狀況. 兩者最顯著的差異, 我認為是 encryption 就不同.

HDMI 的 HDCP cipher 在 section 3.0 HDCP encryption 中的 3.2.

AV stream 在 section 3.4 中描述的 HDCP cipher 則如下. 

兩張圖雖然都是 Figure 3.2, 但 AV stream 輸入的會以 32 bit 的  stream counter 和 64 bit 輸入的 LSB 做 XOR. HDCP TX 會針對每一個 PES 指定一個 32 bit 的 stream counter. 當然每個節目 (program) 的 stream counter 也會不一樣. 這樣切台時, 就要重新算一次新的值, 而不能跨台共用.

接下來關心 V2.3 和 V2.2 的差異. 在 Interface Independent 的部分.

V2.3 的規格書比 V2.2 多了一個 appendix 的 test vector 章節, 官網還特別放了 HDCP independent (for AV stream) 和 over HDMI 兩種 test vector 相容性測試文件. 除此之外, 最大的差異反映在 revoke 的能力, 其它的差異不大.  因此有家 Inside Secure 宣稱可以提供軟體升級 HDCP V2.3 [5].

所謂的 revoke 是說, upstream device (HDMI TX) “may" 對 downstream device (HDMI RX) 做 revoke list 的檢查. 如果這個 HDMI RX 是一個 repeater, 後面還接著一堆 HDMI device, 那麼它們的 receiver ID 也都在被檢查之列. 如果 receiver ID 出現在黑名單, 那 HDCP 的 authentication 就算失敗. 

基於這一點, V2.3 的 page 42 最前面還多了一段描述, 特別指出拔掉已經驗證過 HDCP receiver 也會觸發 RxStatus 變成不 ready.

第二大的差異是 HDCP V2.2 只提它和 HDCP2_0 的相容性, 這暗示 HDCP V2.2 和 V2.1 比較相容. 但 HDCP V2.3 常用 HDCP2_LEGACY 概括描述先前版本, 或者同時提到 V2.2 和 V2.1.

最後有個微小的差異是,  V2.3 當中, 有 18 處提到 TMDS (傳輸最小化差分訊號) 這個名詞, 而 V2.2 當中只提到 4 次 TMDS, 多出的這 14 個地方是用來釐清: TMDS 訊號未必都是 video pixel.

至於 HDCP V2.2 和 V2.3 都各自出現了 13 次 T.M.D.S. 沒有句點的 TMDS 是指訊號, T.M.D.S 是指這個技術, 常出現在方塊圖.

在 on HDMI 的部分. V2.3 和 V2.2 的差異也都是那些: test vector, revoke 之類的. 我看到唯二更不同是:

(1) 特別提到 audio 要參照 Exhibit C section 3.3.1.

(2) Page 39 的 Figure 2.16 的說明改了. State C0: Unauthenticated 多了一個 upstream side de-assert HDCP_HPD 的選項. 原本 State C0 就是 receiver 在等著進到 authentication 而已.

[Ref]

1. https://www.digital-cp.com/sites/default/files/specifications/HDCP%20Interface%20Independent%20Adaptation%20Specification%20Rev2_2_FINAL.pdf
2. https://digital-cp.com/sites/default/files/HDCP%20Interface%20Independent%20Adaptation%20Specification%20Rev2_3.pdf
3. https://www.digital-cp.com/sites/default/files/specifications/HDCP%20on%20HDMI%20Specification%20Rev2_2_Final1.pdf
4. https://www.digital-cp.com/sites/default/files/HDCP%20on%20HDMI%20Specification%20Rev2_3.pdf
5. https://advanced-television.com/2019/01/08/inside-secure-debuts-software-only-solution-for-hdcp-2-3/