分類: 技術

Bridge 小註解

Bridge 是很常見的名詞, 路上的木橋、石橋、糯米橋, 化學的鹽橋、物理的電橋、連三國都有大喬和小喬, 比較容易搞混的橋是下面這兩種.

第一個 bridge 是網路設備的名稱. 相較於 hub, switch, gateway 都是很常用的名詞, 網路上也有很多文章在介紹. Bridge 這個名詞就很少用多了. 一般根據 OSI 的 L1/L2/L3/L4 來區別 repeater, bridge, router, 和  gateway [ref 2], 照理說大家亮相的機會均等, [ref 2] 甚至說 router 在 1970 年以前也叫做 bridge.

Repeater 只是單純照抄封包給其他人, 又叫做 Hub. Bridge 初次見到某個 MAC address 時會先去問 router 該送哪個 port, 以後就能記住 MAC address 與 port 的對應關係. Bridge 又叫做 switch hub 或是 L2 (level 2) switch.

至於 Router 自己有 routing table, 會看某個 IP 決定往那個 port 送最佳, 又叫做 L3 (level 3) switch, IP switch 或 switch router.

由於 3C 產品不斷 cost down, 個人覺得 repeater 和 bridge 應該都沒有什麼存在的價值了. 現在在網路上搜尋 Hub, 出來的應該都是 USB hub. PCHome 的 10/100 Mbps 5 port switch 才賣 290 NTD. 它能過濾 2K 個 Mac address, 至少是 L2 switch 啦！5 port Gigabit 的 switch 也才賣 649 NTD.

第二個容易混淆的 “bridge" 是虛擬機 – virtual machine (VM) 用的. VM 軟體像是 PC 上的 VMWare 或是 Mac 上的 Parallel, 它們在原有的作業系統中, 又執行另外一個虛擬的電腦. 這個電腦通常也需要網路. 如果希望虛擬機和主機 (host) 在網路上有同樣的地位, VMWare 的網路要設定為 bridge. 此時 VM 和 host 共用 Ethernet 接口, 但各自有一個 MAC address 和 IP address. 這兩個 IP address 會在同一個網段, 比方說都是 172.21.1.X. 

Mac 上的 Parallel 的選項分成共用網路、橋接網路、Host-Only 三個選項, 在它的設定檔裡面, 選虛擬機器 → 配置 → 硬體 → 網路 → 橋接網路 → 默認適配器. 就可以達到 VMWare 中選 bridge 的效果. 如果選 vnic0 (virtual nic 0), 外面的 DHCP server 根本看不到它. Parallel 隨便給它個 10.211.x.x 當 IP 就可以透過 host 的 NAT (network address translation) 上網了. Parallel 對待虛擬機, 仍然是隨便給一個 Mac address 了事, 和 host 不同, 甚至還有 “生成" 的選項可以隨機產生新的値.

[Ref]

1. Connecting Devices – Hub, Repeater, Switch, Bridge, Router, Gateway

2. hub/switch/ip share/router 細部介绍

3. Hubs, Bridges, Switches, Routers and Gateways

4. Hubs, Bridges, Switches, Routers and Gateways

SEO 小註解

話說有本新書看到第六頁就卡住了, "..適當的使用 hgroup 元素對於 SEO 有一定的好處." 至於什麼是 SEO 倒是沒有做解釋. 原來此處的 SEO 是指 search engine optimization. 也就是如何更容易被搜尋引擎的機器人找到.

根據 "如何寫出一篇具有 seo 效果的開箱文 (三) – 鏈結的設置" 中的記載, 首先要為文章選出一個 25 字以下的標題, 3~5 個關鍵字. 關鍵字還要愈早出現愈好. 接著就是下標籤 (tag) 與分類. 如果標籤和分類給得愈恰當, 就愈容易被搜尋引擎找到.

另外要考慮錨點文字 (anchor text), 具體地說就是超鏈結文字. 跟論文一樣, 被別人引用的次數愈多, 就顯得自己的文章愈有內容. 寫得最簡明的是這篇 "日本 SEO 現狀":

在搜尋Google「Exit」的結果, 顯示排名在搜尋結果前面的是Disney和Yahoo!。但是Disney和Yahoo!的網站上並沒有「Exit」的文字,且網站內也沒有「Exit」的相關情報。其實會出現此結果的原因是Disney和Yahoo!得到如下所示的錨點文字連結。

If you are less than 18 years old, please <a href="http://www.disney.com/">EXIT</a&gt; now.

以上敘述可以從很多成人網站中看得到。其目的是為了讓未滿18歳的使用者退場,但是它的出口連結卻是指向Disney或Yahoo!。所以搜尋引擎在解析連結後的結果,於是顯示和關鍵字相關連的網站,即為Disney和Yahoo!了。

紅色的這段就是錨點文字. Exit 這個關鍵字就會對應到 <a href="…"></a> 的這個網站. 既然文章是給別人引用的, 好像不操之在我. 但第一篇文章中說, 只要自己多引用自己就可以了. 嗯, 寫論文好像也是如此. 不過論文只能 reference 自己以前的文章, 但部落格卻可以把本文的 URL 當作文章的開始或是結束.

好! 話說 hgroup 又關 SEO 什麼事? 所謂的 hgroup 是 HTML5 的標籤, <hgroup></hgroup> 一般包在 <header></header> 下一層. 用來夾住好幾個不同層級的標題. <h1></h1> 夾大標題, <h2></h2> 夾小一號的標題, 書上建議可以逐步用到 <h6></h6>.

搜尋引擎會去撈 <h1></h1> 裡面的字串當作關鍵字, 因此慎選 <h1></h1> 可以幫助文章被找到. 此外, HTML5 容許多個 header  和 footer, 所以這招用得好, 也比較容易被搜尋引擎找到.

Android 的 AV sync

我們播放多媒體檔案的時候, 很容易注意到 “沒有對嘴" 的情況, 這就是所謂的 lips sync (= synchronization) 或是 Audio-Video sync 的問題.

螃蟹公司怎麼做 AV sync 我不能告訴大家. 但是 Android 的世界裡就沒有太多秘密, 它又是如何做 AV sync 的呢? 

首先它不喜歡用傳統的 PTS (Presentation Time Stamp) 做單位, 而是採用 µs (微秒). 1 秒等於 90,000 PTS, 也等於 1,000,000 微秒. 即使在程式裡面還是難免用到 PTS 的概念, 不過 Android 的上層已經把它轉為時間的單位了.

在 Android 還使用 OpenCore 當播放器的時代, audio 和 video 分別和系統時間 (NPT = normal play time) 校正 [ref 1]. 由於媒體錄製的機器所使用的時鐘 (clock) 和播放器的時鐘會有一定的差異, 所以校正是必須的. 但是往往這個差異相當地小 (若干 ppm  – 百萬分之一的等級), 看完一部 MV 大概發現不了, 或許要看一部電影才會發現.

到了 StageFright 的時代, 計算好像有變複雜一點? 我只參考了兩篇網路文章 [ref 2, 3], 瞭解可能不夠全面. 不過以我對 AV sync 的瞭解, 看起來還是頗能自圓其說. 以下是我歸納的 rules.

1. 首先我們要知道依據播放器的時鐘, 我們已經播出了多少微秒. 請注意下面的 mSampleRate 其實是 frame rate. 這樣算出來的單位才會是秒, 乘上 106 就變成微秒.

2. 再來就是這個媒體的資料, 宣稱它現在是幾微秒? 其實拿 PTS 算一下就知道了, 這個值叫做 mPositionTimeMediaUs. 我們帥氣地把兩個值相減, 就知道系統時間比較快? 還是媒體時間比較快?

mTimeSourceDeltaUs = mPositionTimeRealUs – mPositionTimeMediaUs. 

3. 知道兩者差異之後, 我們就可以開始校正了. 我們想要播系統中第 N 秒 (RealTimeUs) 的資料時, 我們把這個 N 秒減去 mTimeSourceDeltaUs, 就知道該播的是媒體中第幾秒 (nowUs) 的資料.

nowUs = RealTimeUs – mTimeSourceDeltaUs.

4. 從上下文觀察, 此處的 RealTimeUs 是由 audio 所計算出來的. 於是我們知道 Video 也應該要播媒體中的第 nowUs 秒的資料了. 不過 Video 該不該播出來呢? 要看現在 video 已經準備要播出的那一張的時鐘 (timeUs) 而定. 如果 nowUs 比 timeUs 還小, 那麼表示我這張太早了, 稍微晚一點再播就 OK. 早多少可以接受呢? Android 說凡是早了 10 ms (毫秒) 以上, 都拖個 10 ms 再播!

如果 nowUs 比 timeUs 大, 表示遲到了!

lateness =  nowUs – timeUs.

5. 既然遲到還有甚麼藉口? 只要遲到 40 ms 以上, 一律趕快播! 

6. 如果竟然遲到超過半秒, 說不定 audio 都有問題了!? 所以會強制去 call 一次 AudioPlayer→getMediaTimeMapping(&realTimeUs, &mediaTimeUs) 重新取得 realTimUs 和 mediaTimeUs.

以上就是我粗淺的心得, 還請路過的大神幫忙糾正, 順便去救一下 [ref 3] 呼救的那位. 謝謝!

[ref]

1. Android多媒体之OpenCore的A/V同步机制

2. Audio Mutlimedia Framework

3. understanding the logic behind the AV sync in Android 2.2

[後記]

雖然我應該去洗澡睡覺了, 但是還是忍不住講一下八卦. 上面用到微秒和毫秒的地方, 我檢查了一下, 大概沒寫錯. 我記得我大二考電子學第一次期中考的時候, 錯把微秒寫成 10-9, 結果被老師扣了 25 分. 整題計算都對, 只是在 Ans: 後面寫錯單位, 老師還是一分都不給我. 他 (當時還是讀博班的講師) 說: 如果你考博士班資格考 (俗稱 qualify), 錯任何一點點就沒分了. 等我自己考完 qualify, 我確認他是唬爛的…哈! 何況, 己所不欲勿施於人嘛.

Android APP 對 memory 的要求

剛剛在 Android 4.2 CDD (Compatibility Definition Document) 裡面看到 Android 對 APP 指定了可以給予多少 memory 的參考數字.

不過該表格使用的單位很不直覺, 它定義了 small, normal, large, xlarge 四種螢幕尺寸; 又定義了 ldpi, mdpi, tvdpi, hdpi, xhdpi, xxhdpi 等六種解析度 (DPI = dot per inch).

雖然我們可以顧名思義地推測, xlarge 就是 extra large. hdpi 就是 high DPI 等等. 還是做一張沒有特殊名詞, 直接看數字的表格來參考比較方便.

Screen Size Screen Density (DPI) Application Memory (MB)
426×320/480×320/640×480 120~160 16
213~240 32
320 64
960×720 160 32
213~240 64
320 128

據說真正的視網膜解析度是 477 DPI, 而 iphone 4 超越的視網膜 326 DPI 是指直線的方向而已.

總而言之, 在 Android APP 的世界裡, 還沒有 1080P, 4K2K, 或是超越視網膜這回事. 不然每個 APP 應該可以要個 256 MB 也不為過. 那 PM 就不用再想 "cost down 到一顆 256 MB DRR 有沒有可能?" 這種事了.

不過 Android 的確定義了兩種螢幕類型 (screen types). 一種是固定螢幕解析度 (Fixed-Pixel Device), 例如手機和平版. 所有的視訊都要縮放到它預設的解析度. 另一種類型 (Variable-Pixel Device) 是沒有螢幕, 或是有視訊輸出接口的. 對於後者, Android 就有 HD video 的觀念. 而且它很固執地規定只能有 720P 和 1080P 兩種解析度, 不准支援其它的輸出解析度.

Variable-pixel device implementations MUST support one or both of 1280×720, or 1920×1080 (that is, 720p or 1080p).

UIBC 小註解

UIBC 是指 User Input Back Channel, 用在 WIFI Display 的情境之下. 由於顯示裝置 (AV sink device) 和發送裝置 (AV source device) 只能透過無線傳輸, 所以從顯示裝置反過來操作發送裝置的話, 就叫做 UIBC.

上圖中的示意圖, 左邊的 310 可以換成平板或是手機 (410), 右邊可以換成筆電 (420). 不過手機一定是拿在手上, 自己控制自己就好啦！哪需要用到 UIBC？非也! Samsung 申請了個討厭的專利, 連筆電控制手機都納入了專利的範圍, 還好它在 2010/11/2 申請到現在還沒過.

UIBC Patent2

這個專利的摘要說：A method and apparatus for providing a user input back channel (UIBC) in an audio/video (AV) source device and an AV sink device communicating according to a wireless fidelity (Wi-Fi) display (WFD) standard is provided. The method includes: setting up an AV control session and an AV data session between the AV source devices according to the WFD standards; enabling the UIBC from the AV sink device to the AV source device by using the AV control session; and transmitting a user input from the AV sink device to the AV source device through the UIBC.

讓我們拭目以待, 看看拿了 20 個美國專利的 LEE; Jae-min, 和 11 個專利的 NA; Il-ju 這次是否能夠得逞.