分類: 技術

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 可以透過手機來上網. 

RNDIS本圖取材自 [2].

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

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

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

sharing-network

[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 歷史圖示

Webkit-Browser-1-768x487

最早的技術擁有者應該是 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].

Chrome-768x713

那 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 的差異甚大. 

Figure_1ns_790_605_70

在 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

MSE 小筆記

MSE 是指 Media Source Extensions.

傳統的 HTML 網頁就支援 audio, video 的 tag, 然後將它送給 player 播放. Web-based 的 Jave script Applications 透過 MSE, 就能將片段的 media 送給 player, 因此可以實現 adaptive streaming, 例如 MPEG-DASH.

video-blob-768x468

既然要支援隨時變化的片源, MSE 的特色之一就是支援 multiple SourceBuffer objects. 當然, 普通 SourceBuffer 一定也支援. 以下是它的定義:

SourceBuffer

Represents a chunk of media to be passed into an HTMLMediaElement via a MediaSource object.

可以想像, 支援 multiple SourceBuffer 要有一個清單. 所以 MSE 也支援 SourceBufferList 這個 interface.

SourceBufferList

A simple container list for multiple SourceBufferobjects.

MediaSource 是一個 object [2], Sourcebuffer 是它的實體. 圖示如下 [3]:

HTML_MediaSource_SourceBuffer

由這張圖也可以看到 MediaPlayer 會負責處理播放. 由於可播放的格式相當多, 每個 browser 能支援的 audio/video formats 都有所差異. 像是 Chrome 當然要挺自家的 WebM, VP9…等等. 以 Webkit 為例, 透過 MediaPlayerPrivateInterface 就可以把 mediaSourcePrivate/SourbufferPrivate 的內容送給真正的 player.

若使用 gstreamer 來當 player, 它有特別的 WebkitMediaSrc 這個 element, 資料由這邊進去 gstreamer 的 pipeline  就可以做後續的解碼 [3].

mse3-768x530 [REF]

  1. https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API
  2. https://developer.mozilla.org/en-US/docs/Web/API/MediaSource
  3. http://eocanha.org/blog/2016/02/18/improving-media-source-extensions-on-gstreamer-based-webkit-ports/

Westeros 小註解

關於這個題目, 可以依據過去的歷史, 看出發展的軌跡.

    1. STB/OTT box 需要一個 browser.
    2. 過去常用的 qtwebkit 已經不 maintain 了. 下一代是 Blink 或是 Webkitgtk+.
    3. 將 Wbkitgtk+ 中的gtk+ 拔掉, X server 換成 Wayland, 就得到 Wayland for Webkit. 架構圖如下 [from igalia]:webkitgtkJPG
    4. X server 哪裏不好？因為它不是 client-server 的架構, 所以彈性較差.
    5. Wayland 就是 client-server 的 protocol. 下圖取材自 WIKI [1].
    6. Weston 是一種 Wayland Compositor 的架構 (reference design). 其他架構包括: Lipstick、Enlightenment、KWin、Mutter、Clayland...等等. [1]
    7. Westeros 是擴充的 Weston 版本.

    Wayland_display_server_protocol.svg_

    Westeros 有什麼不一樣呢？在 github  [2] 上說了:

    Wayland Compositor

    Westeros is a light-weight Wayland compositor library. It uses the Wayland protocols, and is designed to be compatible with applications built to use Wayland compositors. It implements a library that enables an application to create one or more Wayland displays. It supports the creation of normal, nested, and embedded wayland compositors. A normal compositor displays its composited output to the screen, while a nested compositor sends its composited output to another compositor as a client surface. An embedded compositor allows the application that has created the embedded Wayland compositor to incorporate its composited output into the applications UI. This allows for easy integration of the UI of external third party applications into an applications’s UI.

    關鍵字是可以產生多個 display. 正常的 display 就是一路 UI. nested 版本可以把一個 compositor 做出的 display 加到另外一個 compositor. embedded 版本做出的 display 可以加到 APP 的 UI, 也就是 APP 的 UI 不用完全透過 Wayland 來畫圖. 這樣看來, Westerns 比普通版的 Weston 要有彈性多了.

    [REF]

    1. https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston
    2. https://github.com/rdkcmf/westeros