Linux 下的 object 與 library 檔

從客戶那邊拿到一個 Linux 下的源代碼, 例行 ./config, ./make 之後, 在我的 Cygwin 底下生出很多檔案, 但是並沒有一個執行檔, 倒是有很多 .lo 和 .la, 這是平常我們用自家開發的 embedde system tool chain 所不會遇到的. 這些是甚麼東西呢?

首先我們要瞭解為何需要 L 字頭的檔案, 而不是 .o 或 .a 就好? 原因在於要支持動態連結 (dynamic link). Libtool 就是這樣的一個工具, 以便產生出有益於 dynamic link 的 .o 與 .a, 也就是 .lo 與 .la.

.la 檔是一個文字檔, 裡面描述了此 library 的 version, name 等等, 當然也定義了 dlopen, dlpreopen 要去開哪個 library. 靜態連結與動態連結的 library 分別記錄在 old_libaray = 'libxxx.a' 與 library_names = ' ' 的條目之下. 據說 .la 檔也可以包含另一個 .la 檔, 但我沒看過實例.

.lo 檔也是文字檔, 裡面大概包含 PIC object 和 non-PIC object 的 object name. 所謂 PIC 就是 position-independent code 的意思. 如果程式碼與 position 相關, 當然就不容易動態連結囉!

既然 .la 和 .lo 都是文字檔, 因此它們只是 libtool 底下的溝通工具, 透過 libtool 做 link 的時候, 它們便擔任把真正的 .a 和 .o 傳給 gcc 給工具. 

.so 這東西就是指 shared object, 適用於動態連結, 而 .o 就適合靜態連結, .a 則是 .o 的集合, 也就是靜態的 library.

[ref]

1. http://www.eetop.cn/blog/html/40/202640-8862.html (簡體)

SIP 小檔案

SIP 是指 Session Initiation Protocol, 規格可以從 RFC 3261 查到. 它是 application layer 的 protocol, 位在 OSI [ref 2] 的最上層, 需要建立在底層的 protocol (TCP / UDP) 才能運作.

另一方面, SIP 又只管通訊的建立, 實際上還要再搭配 RTP (Real-time Transport Protocol; RFC 1889)、RTSP(Real-Time Straming Protocol;RFC 2326 等通訊協定. [ref 1]

SIP 的功能包括下面五件事: [ref 1]

(1) User location:透過系統可以確認目前使用者的終端設備位置,以便邀請使用者加入多媒體會議或者是與使用者建立連線。可以想像類似目前手機定位功能。

(2) User availability:決定使用者是否有權限可以加入特定多媒體會議或族群。

(3) User capabilites:決定使用時的媒體型態與媒體參數。

(4) Session setup:建立呼叫端與被呼叫端之間的多媒體連線與連線參數設定功能。

(5) Session management:包含資料傳輸與結束連線、修改連線參數與服務要求等相關功能。

至於 SIP 的指令有六個: [ref 3]

SIP 標準中定義的六種方法
方法 說明
INVITE 初始化
ACK 初始化確定
BYE 要求會議終止
OPTION 功能查詢
CANCEL 取消
REGISTER 提供 location server 使用者位置

因為 user 的位置可能不固定, 所以在查詢對方位置時 (可能透過 proxy), 必須去定位伺服器 (location server) 詢問對方的 URL.

在 [ref 3] 的表 4.2 有一個超讚的 SIP 與 H.323 比較表, 由它可以得知, 雖然 SIP 只負責建立連線, 但是具有簡單, 模組化, 與網路相容, 即時等優點, 所以在 video conference 的規格競賽中, 有日漸重要的趨勢.

[ref]

1.  http://justblogger.pixnet.net/blog/post/387757

2. OSI model

      from http://www.tomax7.com/aplus/osi_model.htm

3. http://eshare.stut.edu.tw/Etd/2005_3/etd-0407109-183704-224-001.pdf (日文, 圖表是中文)

Skype 的 audio 壓縮格式

Skype 的 video 壓縮格式是 VP6, 但是它的 audio 壓縮格式似乎沒有一個定論.  Skype 自己宣稱它的音訊壓縮演算法是和 Global IP 這家公司 license 來的, 因此不是 iLBC 就是 iSAC [ref 1], 或是在兩者中切換 [ref 2], 甚至是在三個演算法中切換 [ref 3].

iLBC 是一個公開的演算法, 可以從 IETF (RFC 3951 and 3952).  查到. 基本上是 13.3 或 15.2 Kbps 的 CBR 壓縮. 而 iSAC 則是在 10 Kbps 與 32 Kbps 中動態切換的 VBR 演算法.

[reference]

1. http://www.voip-info.org/wiki/view/Wideband+VoIP

2. http://forum.skype.com/lofiversion/index.php/t3611.html

3. http://www.autooo.net/utf8-classid89-id40217.html

TrueHD 的小筆記

TrueHD 無損壓縮是 Dolby 公司的另類產品之一, 杜 (Do) 老爺把原來的 MLP 壓縮方法略加擴充之後, 就讓 MLP 改了姓名. 所謂河海不擇細流故能成其深, 當今最厲害的有損壓縮演算法 HE-AAC 也這樣進了杜家的門, 並改名為 Dolby Pulse.

雖然 TrueHD 並非杜家嫡傳, Dolby 還是很別緻地把它的 pass through 方式變成一個產品.  如果不 license MAT 格式, 就無法傳送或接收 TrueHD 的 bit stream. 從學理上看, lossless 壓縮可能導致 bit rate 有極大的變化, 一個週期的正弦波只需要一點點 bit 就可以表示, 若是不把它包成 CBR (constant bit rate), 其實也很難在 HDMI 這樣的介面上傳輸.

TrueHD 的 DRC (dynamic range control) mode 可以用來調整音量, 如果 DRC = on, 那麼 DRC 就會永遠開, DRC = off 就是原樣的 lossless 輸出. 而 DRC = follow 就是根據 bit stream 裡面的描述來決定 DRC 開或是關. 

以 PS3 的舊版 FW 來說, 因為它的 DRC mode = off, 所以 PS3 解出的 PCM 硬是比擴大機的輸出小了 4dB. 由於客戶的抱怨, 新版 (> 2.41 版) 的 PS3 就把 TrueHD 的 DRC 給開了. 但是開 DRC 需要增加不少計算量, Sony 應該是調校過 FW, 才推出這個新版吧!?

3D 繪圖速成小筆記

我希望自己在最短的時間之內, 就把 3D 基本觀念搞懂. 最好只花一個 page 就可以複習. 以下就是我的筆記.

3D 繪圖方式有三種, 第一種是用線的觀念. 可以想像一個視線從投射面回溯到光源, 這稱之為 Ray-tracing. 第二種方式是把圖的表面 (surface) 分解成小塊 (patch). 而每個 patch 都有自己的光照圖 (light map), 並且輻射周圍的 patch. 這稱之為 Radiosity, 聽起來有 iteration 的感覺.

第三種方法,  稱之為 Rasterizing (光柵化), 也就是唯一適用於硬體加速的演算法. 簡單地說, 就是先得到頂點 (vertex), 然後把點連成網眼 (mesh), 其中的基本圖形是點, 線, 與三角形, 三者合稱為 primitive.

假設我們要畫的東西是一個剛體, 不會隨便就變得軟趴趴的, 那麼每個 vertex 都可以有一個相對座標值. 要把這個 object coordinate 轉到整張圖上的座標位置 world coordinate, 這就是第一個轉換. 轉到 world coordinate 還是不夠的, 因為觀察者視角的關係, 這個位體還要轉到 eye coordinate. 就好像一個魔術方塊, 不可能讓我們同時看到六個面, 座標位置當然與觀察者的角度有關.

轉完之後, 開始打光, 包括 R, G, B, alpha 四個值決定紅, 綠, 藍和透明的強度.

畫好之後, 剛才的魔術方塊又出現了. 被擋到的東西不用畫, 也不能畫. 所以要再次轉到裁切座標 (clip coordinate). 在最上層的東西, 才會畫到螢幕上 screen coordinate.

以上可以得知哪些 vertex 位於螢幕之內或是之外. 凡是落在螢幕之外的 vertex, 我們只需要畫到螢幕邊緣就好. 但任意多邊形並不是 primitive, 所以那些形狀不齊的四邊形會被分割成兩個三角形.

現在有了一堆轉換過的頂點, 接著就要把頂點所包圍的畫素 (pixel) 都找出來. 這個過程就是光柵化 (Rasterize). 還在 vertex 階段的處理稱為 front-end, pixel 等級的處理稱為 back-end.

在 pixel 的操作包括下面三者: texture (紋理), blending (混色), filtering (濾鏡), 總之就要給每個 pixel 最合理的顏色. 原先在 vertex 階段所配置的特性如何用在 pixel 上呢? 大致就是內插法. 所以原先幫每個 vertex 打光的工程, 就不需要詳細到 pixel 等級上那麼累! 真是聰明哪!

下一個階段就是要把畫好的圖貼進 frame buffer 了. 比方說要畫個眼睛在臉上, 眼睛總不能大過臉, 又不是海綿寶寶的蟹老闆. 因此要在可以畫眼睛的範圍以外塗上框框, 這個框就是模板 (stencil). 其次當然不脫後景不蓋前景, 需要更新的區域才更新等基本限制, 在真正畫出去之前, 要先做這類的測試. 例如 scissor test, alpha test, depth and stencil test 等等.

測完之後可能還有一點事情要做, 比方說 alpha belnding, 千辛萬苦之後, 一個點好不容易才可以進到 frame buffer.

講完硬體之後, 再講一點點軟體. 繪圖的 API 包括 OpenGL, 這是 ARB 推的. 還有 Direct3D, 這是 Microsoft 推的.

OpenGL 的指令分為兩種, 一種是給定 vertex 與顏色等等, 以產生圖像. 另外一種是設定對上述資料的操作. 甚至是先做一些 transform 以取得新 vertex 的座標.  基本就是只做 rendering.  

[reference]

http://www.ategpu.com/2009/05/29/interactivecomputergraphics.html

說 reference 也太牽強了, 我根本是濃縮再製版.

http://zh.wikipedia.org/wiki/OpenGL

因為不太懂又沒有時間, 所以我花 2 個小時, 寫了這個快速學習備忘錄. 謬誤之處, 請多多見諒. 等我有所成長, 再來修正這裡的不足.