分類: 技術

Mac 加裝 Windows 小筆記

話說我的 Mac Book Air 是當初去大陸出差時, 因為 Mac Book Pro 忽然掛掉, 臨時跑去商場裡的蘋果店買的. 由於人生地不熟, 又怕有假貨, 所以買了最低規的版本, 想說這樣風險最小. 買回來後發現果然是真品, 又去淘寶買了一塊 512GB 的 SSD 來升級, 但 RAM  沒升, 還是 4GB.

隨著 Mac 和 Windows OS 不斷升級, 現在進到 Parallel 已經跑不太動了. 我最初懷疑是不是和 Mac Book Pro 一樣 SSD 掛掉? 所以買了一隻創見 JetDrive 520 來換 SSD. 換了 SSD 之後, 確實反應變快一點, 但最後效能還是卡在 CPU i5 1.4 GHz 和 4GB 的 DDR3 1600 上面.

既然花錢換 SSD 還是沒改善, 我不由得怒從心中起, 惡向膽邊生, 決定把整台重灌成 Windows! 畢竟公司的 VPN 只支援 Windows, 我用穩定的 Apple 硬體搭日漸穩定的 Windows 10 總可以再撐一陣子吧!?

不過事情並不像憨人想得那麼簡單, 有幾個奇怪的地方需要突破, 前後花了很多時間才搞定:

[Windows 10 與創見 JetDrive 520/525 相容性問題]

JetDrive 520 安裝 Windwos 10 dual boot 必定會失敗. 前面的步驟都沒問題, 等安裝完成之後, 第一次開機會卡在 “正在準備" 這個頁面. 推測是 Windows 10 多檢查了什麼? 但安裝 Windows 7 就沒有這個問題.

如果安裝 Windows 10, Bootcamp 會把輔助程式都抓下來, 流程全自動. 只是搭配創見 JetDrive 520 必死, 搭淘寶買的 SSD 沒問題.

創見 JetDrive 520 和 525 的差別是前者沒有衣服 (鋁殼外接盒) 可以穿, 官方如果能單獨賣殼讓我的 Jet825 升級, 這樣至少舊 256GB, 512GB 還可以當隨身碟. 但前幾天電話詢問創見還是沒有賣這種東西, 如果大家有需要更新 SSD, 可考慮買大陸流出的正廠 SSD, 或者至少是 JetDrive 525.

[硬碟分割問題] 

當我打算安裝 Windows 7, 會發現分割硬碟有 bug. 我沒辦法拉動分割比例, 甚至平均分配硬碟的按鈕也失效. 此時只能預設給 Windows 36 GB 且順利安裝, 但若試圖調整大小必失敗.

解決 Windows 7 分割問題的方法是, 做一隻可以安裝 Windows 10 USB 碟. 插著它去開 bootcamp, 選擇製作安裝碟後, 此時分割大小隨便怎麼拉都可以, 選好之後, 把這支碟拔掉, 插上 Windows 7 USB 安裝碟, 然後依正常流程處理. 

[分割工具問題]

分割 Dual Boot 硬碟一定要用 BootCamp, 不能用磁碟工具. 主要差在 BootCamp 最後會在 USB 安裝碟裡面做出啟動磁區.

我用磁碟工具預設 36 GB 的版本順利安裝完 Windows 7,  曾經考慮新增一個分區, 然後再把它配給 Windows. 但 Windows 無法接受硬碟分成兩塊, 所以我把這兩塊和 EFI 開機分區全殺了, 打算重來一次.

不料從此以後, Mac 只看的ˊ到留給它的那 500 GB SSD, 即使從 Command-R reboot 進去,也看不到其他分區了.  SSD 瞬間縮水一半, 感覺心好痛!! 最後想到用 Windows USB 安裝碟進行假安裝, 真砍分區的補救措施, 重開機後, Mac boot 才看得到完整 SSD 大小, 過程好恐怖! 差點就到 PCHome 24 小時網站下 Notebook 訂單.

另外, 似乎是插著多餘 USB device 的關係, 磁碟工具根本無法完整磁碟的分割. 有時是做完後 fail, 有時是一直在 “準備分割硬碟", 但過了幾個小時還在準備中. 打開活動監視器, 也沒看到有什麼 disk IO, 只有 CPU 占了 1.5% 還活著而已.

有個第三方磁碟工具 Stellar Partition Manager 說自己是 Mac 硬碟管理的第一品牌, 於是我也拿它來做實驗. Stellar 的 UI 滿炫的, 只是反應有點慢. 它說現在的硬碟是啟動硬碟, 所以要製作一個啟動 USB 裝置來開機, 然後透過啟動裝置來分割目標 SSD. 這個講法也滿合理的, 於是我把家裡各種 16 GB 以上的裝置都拿來當過開機碟, 不過呢? 開不起來! 等了幾個小時也開不起來~~

[OS X 版本和 Windows 10 相容性問題]

OS X 10.9.5 版不認識 Windows 10, 一直叫我改用 Windows 7 “以上" 的版本, 連製作安裝光碟這步都走不下去.

[Windows 7 BootCamp 與更新問題]

Windows 7 雖然安裝成功了. 但是開心地更新 Windows 系統, 可能會導致系統出現藍白畫面當機. 接著開機時選 “修復電腦 (建議選項)" 救電腦的過程中, 會跑到某個畫面需要按 enter, 但這個時候 Mouse, 內建外接鍵盤完全沒反應. 只有開機時按 F8 可以自動復原系統.

正確的流程是, 剛才做出的 USB 安裝碟裡面的 Bootcamp 輔助程式得先執行, 然後才可以更新 Windows. 進到 USB 找 BootCamp 目錄底下有一個 setup.exe, 在 Windows 下執行它就可以. 其實若不執行它, 應該會發現 WIFI 不見了, 沒聲音..等問題. 但 USB/BT 似乎直接就是好的, 所以一時可能沒察覺到執行輔助程式的重要.

至於做好的 Windows 7 要不要做滿 – 升級到 Windows 10 我還沒有決定. 畢竟 Windows 10 專業版比 Windows 7 專業版還要便宜.  我可能會冒著全部重來一次的風險試試看.

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/