Thinker 在「GStreamer 和 OpenMAX IL 的比較」一文提到：

GStreamer 是知名的 open source multimedia framework，相當於 Windows 下的 DirectShow 。而 OpenMAX IL 則是多家知名廠商參與制定的標準，其功能和 GStreamer 也有些類似。目前已有一些 multimedia framework 開始支援 OpenMAX IL，以使用 OpenMAX IL 相容的 component 。 OpenMAX IL 是一個 codec 的標準介面，實作該介面的 codec 可以被任何 OpenMAX IL client 所使用。目前 Android 使用的 opencore 所支援的 codec 實在很少，如果可以透過實作 OpenMAX IL 的 wrapper ，讓 FFmpeg 之類的 multimedia framework 所提供的 codec 能當成 OpenMAX IL 的 component 載入，那麼 opencore 瞬間就多出許多 codec 可以使用。

這個想法已經被 Prajnashi S 初步實現，雖然層面不同，但還是有很大的參考價值。下午將之前的程式碼升級到 Android cupcake (1.5 Release)，做了一些微調，在 target 上運作起來，先看看有哪些 plugin：

# gst-inspect-0.10
audiotestsrc: audiotestsrc: Audio test source
videotestsrc: videotestsrc: Video test source
omx: omx_dummy: OpenMAX IL dummy element
omx: omx_mpeg4dec: OpenMAX IL MPEG-4 video decoder
omx: omx_h263dec: OpenMAX IL H.263 video decoder
omx: omx_h264dec: OpenMAX IL H.264 video decoder
omx: omx_mp3dec: OpenMAX IL MP3 audio decoder
omx: omx_amrnbdec: OpenMAX IL AMR-NB audio decoder
omx: omx_amrwbdec: OpenMAX IL AMR-WB audio decoder
omx: omx_aacdec: OpenMAX IL AAC audio decoder
audioflingersink: audioflingersink: Audio Sink (AudioFlinger)
videoflip: videoflip: Video flipper
quicktime: qtdemux: QuickTime demuxer
coreelements: capsfilter: CapsFilter
coreelements: fakesrc: Fake Source
coreelements: fakesink: Fake Sink
coreelements: fdsrc: Filedescriptor Source
coreelements: fdsink: Filedescriptor Sink
coreelements: filesrc: File Source
coreelements: identity: Identity
coreelements: queue: Queue
coreelements: filesink: File Sink
coreelements: tee: Tee pipe fitting
coreelements: typefind: TypeFind
coreelements: multiqueue: MultiQueue
ffmpegcolorspace: ffmpegcolorspace: FFMPEG Colorspace converter
surfaceflingersink: surfaceflingersink: android's surface flinger sink
coreindexers: memindex: A index that stores entries in memory
videoscale: videoscale: Video scaler
staticelements: bin: Generic bin
staticelements: pipeline: Pipeline object

Total count: 12 plugins, 31 features

這表示，透過 GStreamer，Android 瞬間多了許多高品質的 plugin 與外加功能，也就能以 FFmpeg 或既有的 gst-plugins 來處理各式的多媒體資料。現在 video 的處理，可透過 Surface Flinger sink 來操作，測試方式：

# gst-launch-0.10 videotestsrc ! surfaceflingersink

以下是對應的螢幕輸出：

稍後，我們再來探討整合的議題。

read on

愛因斯坦說過：「對一個人來說，所斯望的不是別的，而僅僅是他能全力以赴和獻身於一種美好事業」，今天，台灣有一小群工程背景的朋友，憑恃著如此的信念，打算為台灣的資訊產業，作些事情，所以成立 0xlab。愛因斯坦又說：「信念最好能由經驗和明晰的思想來支持」，我們的成員則根基於過去參與自由軟體 / 開放原始碼專案的協同開發經驗，以及對追求理想和真善美的堅持，透過 0xlab 這個嶄新的嘗試，將原本散落各地的開發資源，集中起來一同打拼，目前為止的成員有 8 位，依序是 Erin, Jeremy, John, Jserv, Julian, Olv, Thinker, Tick。每個人各有其專擅的領域，我們希望以團隊的優勢提供完整戰力，為軟體界做出些許貢獻，以技術的方式來愛台灣！

個人一直認為，工程師若要愛台灣，最好的方式，就是強化本職學能，無論是軟硬體技術，使其累積、成長，進而提升到更高的層次。今天，2009 年 4 月 27 號，是 0xlab 的誕生日，專注於推動硬體廠商與開放軟體社群的聯繫，成為軟硬體整合方案提供者，讓更多基於開放軟體的裝置走入日常生活。

read on

過去我們很難聯想進階的編譯器 (compiler) 技術到底與移動平台何涉，但隨著基礎建設的突破，我們就該有不同的思維。

從1960 年代發展至今，編譯器技術已是電腦科學最成熟的基礎之一，不斷地成長與蛻變，而透過 open source，GNU GCC 與 LLVM (Low Level Virtual Machine) 計畫獲得空前的成功，累積了驚人的編譯器技術。儘管 parser 仍是 compiler 的關鍵技術，但今日，我們會著重於打通任督二脈的技術展現，過去耳熟能詳卻貌似獨立的項目，比方說 virtual machine, binary translator, JIT compiler, HotSpot JVM, 等等，如今好似整合了金庸書中的武功精髓、淬湅出武術菁華，形成一套獨到的武功系統，透過 LLVM 一類的整合性技術而一瀉千里。

幾年前，知名的遊戲設計公司 id Software 在該公司靈魂人物 John Carmack 的主導下，將 Doom (毀滅戰士) 核心的遊戲引擎以 GNU GPL 開放授權釋出，自此開啟廣泛的平台移植與功能強化的的濫觴。早期的 Doom GPL 程式碼被 Sam Lantinga 移植到 SDL 圖形函式庫，藉由 SDL 優異的可攜性，眾多硬體環境得以運行 Doom 遊戲，儘管遊戲的資料檔並非自由軟體。另一方面，現在最火熱的移動平台，就屬 Google Android 開放源碼平台，為了迴避 Sun Microsystems 對 Java 的控制權 (logo + patent)，該平台整合大部分 Apache Harmony 專案的成果，建立了一套貌似 Java 語言但執行環境大異於 Java 的嶄新虛擬機器 -- Dalvik，將原本 stack-based VM (JVM) 轉換為 register-based VM (Dalvik VM)，而無論這裡頭有多少玄機，就 Android 的程式設計來說，Java 是唯一可用的程式語言，要不得搭配 Android framework / class library，不然就是透過 JNI 去呼叫 C/C++ 撰寫的動態函式庫。作為一個「慣 C 魔人」， 筆者反覆思考，是否能將以 C 語言搭配 SDL 函式庫撰寫的 Doom，透過編譯器轉換為 Android 平台可運作的 Dalvik bytecode 呢？此舉不僅讓 C/C++ 程式跨平台執行，還為移動平台提供了新的附加價值，於是，筆者就開始一系列的 hacking，現在有初步的成果，日前已發表於 OSDC.tw 2009 的「窮得只剩下 Compiler」議程中，請參考以下螢幕快照：
這可不是紙老虎或單純貼圖，電動玩具當然是設計來玩的：
詳細的資訊可參閱發表於 OSDC.tw 的議程簡報：

View more presentations from Jim Huang.

筆者同事 luse 嘗言：「現在是一個充滿編譯器的世界，身為一個工程師，每次聽到編譯器技術，覺得深不可測 (或是腦海忽然浮現起自動機的回憶) 而輕言放棄，實著可惜」。許多人印象中艱澀的 (dynamic) Compiler 技術，其實廣泛應用於我們電腦資訊產業中，以「到處都是 Compiler」來闡述現實，一點也不為過。如此的案例多如牛毛，比方說，現在 Web 2.0 與 Mobile web browser 正火熱，為了要能改善 Web 應用程式的效能，Google 與 Apple 兩家公司的工程團隊，各自推出 V8 與 SquirrelFish Extreme 等 Just-In-Time compiler for JavaScript，而 Mozilla Foundation 更是將高速的 JavaScript 引擎當作 Mozilla 2 的重要賣點，知名的自由軟體開發者 Jim Blandy 甚至離開專業 GNU Toolchain 開發公司 CodeSourcery，加入 Mozilla Corporation，就為了致力開發 ActionMonkey (整合 Mozilla 原有 SpiderMonkey 與 Adobe 貢獻的 Tamarin)。自此，這個在瀏覽器平台的戰役，從桌面系統延續到手機，又將從手機移轉到各種不同的資訊裝置上。

而，撇開 JavaScript 執行引擎不論，實際上，連 Firefox/Mozilla 底層的向量繪圖函式庫 Cairo，也透過 JIT compiler 技術，去提昇整體繪圖的效能與使用者體驗。日前，Dan Amelang 揭露他的開發成果，可參見郵件論壇的訊息 "JIT for pixman"。pixman 是提供給 X Window System 與 Cairo 使用的 pixel-manipulation 函式庫，顧名思義，就是處理 image compositing 與 trapezoid rasterization 等操作，而在 Dan Amelang 的論文 "Jitblt: Efficient Run-time Code Generation for Digital Compositing" 給予令人振奮的突破，無疑是個極佳的突破點，我們也可預見 (dynamic) compiler 技術在更多資訊領域的廣泛應用。

當編譯器技術走入新的層次時，就需要更強大且多元的 Toolkit，LLVM 專案的出現，在整個電腦技術典範移轉 (paradigm shift) 的衝擊下，以嶄新編譯器架構、自由軟體協同開發模式，給予我們突破限制的可能性，顯然，我們可確定 LLVM 應用於 Android 應用程式開發，僅是一個牛刀小試，好戲才要登場呢。

read on