RNDIS 小註解

RNDIS 是指  Remote Network Driver Interface Specification. 很多網站都介紹過這個技術, 此處專門整理手機和電腦以 RNDIS 連接, 誰上網給誰用的問題.

在 [1] 提到, 用 USB 介面傳 Ethernet 技術, 有兩大類技術:

  1. RNDIS – Microsoft 版的 NDIS.
  2. CDC (Communications Device Class) – 包括 Ethernet Control Model (ECM), Ethernet Emulation Model (EEM), and Network Control Model (NCM). 

對 Windows 來說, 通常它是 USB host, NoteBook 可以透過手機來上網. 

本圖取材自 [2].

在 Windows 環境, 通常下載 RNDIS driver 就可以搞定. 在 Linux 環境, 預設支援 RNDIS. 相關設定可以參考 [3].

此時都是 PC 當 host. 根據 [4], RNDIS 可以透過 WIFI, Bluetooth 上網, 特別是透過實體cable 連接 (如 USB) 的時候叫做 Tethering.

如果反過來, 手機要用電腦上網呢 [5]? 此時主要的設定在電腦上, 也就是讓已經存在電腦上的網路 (透過電腦上 Realtek PCIe GBE 網卡), 允許這個新的 (手機過來的區域連線 4) 網路的分享連線. 此時 PC 仍然是 host.

[REF]

  1. https://en.wikipedia.org/wiki/Ethernet_over_USB
  2. https://docs.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-remote-ndis–rndis-
  3. https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Enabling_USB_RNDIS_Support
  4. https://wiki.gentoo.org/wiki/Android_USB_Tethering
  5. 【分享】手機透過電腦上網~USB傳輸線

Webkit 歷史圖示

最早的技術擁有者應該是 Netscape, 但 KDE 用了一套自訂的 Javascript engine – KJS 和 webcore engine – KHTML. 其中 KHTML 做得比 Netscape Navigator 的 Gecko 還小, 所以被 Apple 相中拿來開發 Webkit. KDE 原本沒有做 webview 的部分, 所以 Webkit 的名稱是 Apple 取的.

Apple 除了開發 Webkit, 又以兩手策略開發封閉性的 Safari. 到了 2010 年, Apple 做出 multi-process 的技術, 把 main process 和 render process 分開, 因此把 Webkit 改為不相容的 Webkit 2.0.

Google 的策略是借用 Webkit 的 Webcore, 其他自己搞. 後來開發出  V8 Javacript engine, 算是有了重大突破. 接著 Google 又做出 Blink engine, 把 webcore 換掉, 這些好料都放進了 Chrome. 當然 Google 也是兩手策略, 不會平台讓 Apple 佔便宜.

QT 和 GTK 都基於 Webkit 2.0 做出新版. 同理, WPE (Wayland for Webkit) 當然也是 ‘for’ Webkit 2.0 才聰明. 

那 Chrome 有 multi-process 嗎? Chrome (Chromium) 的做法是起好幾個 Webkit [1]. 以空間換取時間. 至於沒有 mutli-process 的弱點, 據說是用 timer 來多工執行, 沒有用到多核的優點 [3].

那 Blink 比起原來的 Webcore 差多少? 根據 [2], Blink 從 Webkit 裡面刪掉 8.8 百萬行的 source code…身輕如燕, 難怪叫做 blink. 不意外地, Qt 等等上層 API 也 port 到了 Blink.

對了, Chromium 是鉻, Cobalt 是鈷, 看起來是兄弟關係. 那麼 Google 的 Cobalt 又是做甚麼的? 這個資訊很難找, keyword 下錯絕對搜尋不到, 客官要看這裡 [4]. Cobalt 的作者本來是負責維護 Chromium 裡面的一段代碼, 叫做  H5VCC (HTML5 Video Container for Consoles). 他在各種平台 porting 這段 9 百萬行的 code  好幾年後, 終於受不了了. 決定要推出符合下面特色的功能:

  • Limited Memory. 記憶體少.
  • Slow CPUs. CPU 慢.
  • Fewer cores. 更少核.
  • Sometimes No GPU. 可能沒 GPU.
  • Sometimes No JIT. 考量安全性, 也不需要支援 just in time 代碼.
  • Heterogenous Development Environments. 跨平台環境.
  • No navigation. 不用瀏覽, 只要呈現.
  • No scrolling. 不需要捲動畫面.

因為 Cobalt 弱弱地不用處理很多事情, 連 Javascript engine 都可以偷掉. We have, perhaps surprisingly, not written our own JavaScript Engine from scratch. Because of the JITing constraint, we have to be flexible with which engine(s) we work with. We have a bindings layer that interfaces with the JS Engine so that application script can interface with natively-backed objects (like DOM elements). 因此近來成為 porting Youtube 的主流.

[REF]

  1. https://www.chromium.org/developers/design-documents/multi-process-architecture
  2. http://browserg.nom.es/
  3. https://www.zhihu.com/question/20930880
  4. https://cobalt.googlesource.com/cobalt/+/refs/heads/master/src/README.md

ATSC 3.0 小整理

ATSC 3.0 的消息愈來愈多, 在此整理一下. 首先補充 ATSC 2.0 發生了什麼事? 由於 2.0 的主旨只在於提升解析度, 因此還來不及推廣就被格局更大的 ATSC 3.0 取代了.

參考下圖 (取自 [2]), ATSC 3.0 除了可以走 broadcast (廣播), 也可以走 broadband (寬頻). Broadband 意味著可以用 USB 或是 HDMI dongle 透過 WIFI 路由器播放 ATSC 3.0 而不用換電視或是 tuner. 當然, 我們可以看到若走 broadcast 這路, 3.0 和 1.0 的差異甚大. 

在 IP 層以上, broadband 和 broadcast 只有 TCP 和 UDP 的不同. 再往上, 就沒有分別了. 這裡有幾個縮寫要注意. ROUTE 不是路由器那個 route, 而是 Real-Time Object Delivery over Unidirectional Transport (那 E 呢? 去哪裡了?), MMTP 是指 MPEG Media Transport Protocol, HTTP 是 hypertext transfer protocol; 後兩者沒有搞怪, 就是大家平常知道的那個. 資料路徑如下:

MPEG-DASH –> IP –> ROUTE –> HTTP Proxy –>  MPU (Media Processing Unit)

MPU 負責解碼 (decode) 和播放. 上圖的 MPU 兩層之中有個 EME, 負責解密 (decrypt) 的部分. 播放當中可能頭端還會推送一些資料, 它們會走上圖的 NRT (Non-Real-Time) file delivery. 基本的 ATSC 播放規格如下:

  • Transfer rate: Up to 57 Megabits per second on a 6 MHz channel (up from ATSC 1.0 19.4 Mbit/s)
  • Video Codec: HEVC/H.265 (ATSC 1.0 used MPEG-2)
  • Progressive Video: Up to 4K UHD or 3840 X 2160 resolution at 120 FPS
  • High Dynamic Range (HDR) imaging
  • 3D TV compatible – just in case it makes a comeback
  • Dolby AC-4 & MPEG-H 3D Audio
  • Multi-audio track by program
  • Dynamic range control
  • Audio / video water mark
  • Adaptable single frequency network transmission systems for improved over-air reception from ATSC 1.0

顯而易見地, 音視頻的水準都大幅提高了. 另外值得一提的是, ATSC 號稱改善了 AV sync. 對嘴的效果會比以前更好. ( ATSC improves lip-sync so that in any kind of delivery scenario lip-sync is maintained to a very tight tolerance.)

既然可以透過網路, 當然就可以支援手機播放 (multi-screen). 所有的內容都廣播出去之後, 接受者若在不同的區域收看, 就可以根據地理資訊 (如 GPS) 或個人喜好篩選其內容, 比方說天氣、交通資訊等等. 當然, 大家也可以對廣告投票, 反映自己的意見. 

當然, broadcast 這路也不是什麼事都沒做. 據稱 ATSC 改善了訊號強度. 我想這一部分是 OFDM (Orthogonal frequency division multiplexing) 所貢獻的. 它的目標是像手機一樣在室內也可以收到訊號 ( allowing signals to travel further and to penetrate deeper into buildings and basements within range) [1].

最後提一下 ATSC 賺錢模式, 前面講到會播廣告. 但他們更想做的是 on line shopping, 看到電視上有什麼好東西都可以直接點下去就下單. 這個夢想在 BD (藍光光碟) 已經提過一次, 但 BD 不普及, 這想法就沒有發展成功.  Netflix 的商業模式也被討論到 [1], 不過我對 Netflix 的模式除了包月之外, 認識不多.

[REF]

  1. http://www.audioholics.com/editorials/atsc-3.0-cord-cutter2019s-dream-to-tiered-internet-nightmare
  2. https://www.thebroadcastbridge.com/content/entry/6229/atsc-3.0-details-explained-part-4
  3. https://www.thebroadcastbridge.com/home/category/transmission-encoding-mux/entry/6139/atsc-3.0-mysteries-explained-part-1
  4. https://www.thebroadcastbridge.com/home/category/distribution-and-delivery/entry/6200/atsc-3.0-explained-part-2
  5. https://www.thebroadcastbridge.com/home/category/transmitters-and-rf-components/entry/6275/atsc-3-0-details-explained-part-3