子計畫三進度和原本的研究目標不盡相同，我們做了以下的解釋：
(1) MVC (Multi-view Video Coding) 標準已經在今年 (2009) 三月結束 制定的工作。在所有 MVC 的參照軟體 JMVC 所接受的多視角視訊壓縮工具 中，尤以視角間預估 (Inter-View Prediction)、亮度補償 (Illumination Compensation) 與運動向量省略模式 (Motion_Skip Mode) 等技術引起最多 與會者的討論。對比於 H.264/AVC 壓縮標準，JMVC 可以帶來平均約 20% 的 位元率 (Bit-Rate) 的節省，但仍舊未達當初 MVC 在 Coding Efficiency 上 制定的目標。在考慮不同工具在壓縮上所需要付出額外的複雜度，與其所能 帶來於 Coding Efficiency 的改善，因此 MVC 僅採用在 Anchor View 上進 行視角間預估。因 MVC 標準不接受 Macro-block Level 以下之 Syntax 的 改變，只接受視角間預估為標準當中的壓縮工具，有鑑於此，我們把研究發 展發向改為與 MVC 並行的 FTV 標準。
(2) MPEG-FTV 計畫主要目標在標準化以下三個子項：深度圖估測演算 法、虛擬視訊合成演算法與多視角影像與深度圖壓縮標準。其中壓縮標準目 前考慮使用 MVC，壓縮對象包含多視角視訊與其對應的深度圖。FTV 與 MVC 分別為 MPEG 與 JVT 並行的計畫，MVC 已於今年結束制定的工作；而 FTV 目 前專注在深度圖估測知正確性與虛擬視訊合成品質上的提升。FTV 為基於多 視角 DIBR (Depth-Image-Based Rendering) 的虛擬視訊合成技術，由子計 畫的研究發現，現行壓縮標準在壓縮深度圖上，對合成視訊的品質造成許多 影響，特別是影像上高對比的區域與深度值較小的區域，合成品質較容易受
到深度圖壓縮的影響。深度圖壓縮是下個階段 FTV 所要專注的重點目標，同 時也是許多國內外學者提供解決方案的重點項目，因此本子項轉向提出深度 圖對合成影響之模型，藉此模型幫助深度圖壓縮的設計。目前本子計畫已建 立壓縮深度圖對合成影像影響之模型，藉由此模型偵測壓縮後受影響的深度 像素，進而修正此像素後縮小合成之誤差。初步研究上，平均合成效能於 PSNR 表現上，相較於 FTV 標準已經產生 0.56dB 的提升，在低位元率的深度圖表 現上，更有 0.45-3.2dB (平均 1.2dB) 的改善，主觀視覺更可以有效消除影 像高頻區段的合成誤差，提升視覺上的品質。
(3) 基於 MPEG-FTV 的架構下，本子項已完成視角合成演算法的開發，目 前在順利移植到 ARM 嵌入式平台。於此平台上，在 CIF 與 QCIF 的解析度上 已經可以達到 0.54 與 1.56 fps，即時運算則是本子項下一步發展的目標。
因此，總合今年的成果，子計畫三完成下列幾點：
(1) 完成深度圖壓縮品質對合成影像影響的文獻研究。
(2) 完成檢測合成影像失真的模型。
(3) 完成修補壓縮後深度圖的演算法。
(4) 在 FPGA 上完成立體影像視訊軟體。
(5) 在人才培育方面，本計畫兩年來共有 1 個博士生、2 個碩士生參與。
(6) 在論文方面，本計畫完成了一篇期刊論文(審察中)。
子計畫四成果：嵌入式 JAVA 平台設計 五、前言
本報告將簡述本計畫前兩年之研究成果。子計畫四的研究目的是在開發一 套雙核心 Java 處理器以及最佳化的系統軟體，以提供一個高效能的 Java 執行 環境。在過去兩年，子計畫四除了完成異質雙核心的 Java 應用處理器的開 發，並完成了支援圖形介面應用程式的系統軟體開發，以用來在 FPGA 平台上 驗證我們所開發的 Java 處理器。目前我們所得到的系統執行效能大約是 Google Android 參考平台的四倍，Sun CVM 參考平台的五～八倍。而我們也 把研究的成果撰寫了一篇期刊論文（審查中），以及發表了三篇研討會論文。
六、研究目的
隨著嵌入式系統的發展，嵌入式 Java 執行環境已經變得越來越重要了。
經過一些調查，我們發現新一代的嵌入式多媒體平台有漸漸地往 Java 執行環 境收斂的趨勢。例如在 3GPP 手機上的 CLDC/MIDP 平台，Google 手機的 Android 平台，或是歐規數位電視標準的 DVB-MHP 平台都是一些實際的例子。
通常一個能夠支援複雜的使用者圖形介面的 Java 執行環境往往需要一個全功 能的作業系統。在嵌入系統的環境中,這通常是 Embedded Linux。以往在 Java 系統的設計上，大部份的研究都集中在 Java bytecode interpreter (或稱作 Bytecode Execution Engine)的效能改進。很少有研究是針對整個 Java 執行環境 的最佳化設計進行討論。
通常在設計 Java 執行環境時，為了能讓 Java 執行環境有較高的效能，會 把許多 Java 執行環境所需要的功能直接對應到低層的作業系統和硬體平台所 提供的功能。不過這樣設計的缺點有下面兩大缺點。首先，如果 Java 執行環 境是儘量利用作業系統的功能來提昇效能，那麼這個設計的移植性就不高。現 今嵌入式系統的作業系統並沒有統一的趨勢，因此在設計 Java 平台時，如果 只針對某一套作業系統最佳化，它的應用就會受到限制。第二個問題是，Java 執行環境本身就等同一套虛擬的作業系統，如果所有的應用程式都是用 Java 開發，那麼，整個系統就只會用到底下的實體作業系統的一小部份。從系設計 的角度來看，這是一個相當浪費資源的設計。一個典型的例子就是 Android。
雖然 Android 的 Java 執行環境是架構在 Linux Kernel 2.6.25 之上，但是它只利 用 Linux Kernel 提供以下幾項主要功能：
Hardware abstraction layer
Process management
Shared library dynamic loading management
事實上，一個簡化的 OS Kernel 就能提供以上三項功能。所以單從 Java 執行 環境的支援來看，並沒有理由採用 Linux。不夠 Android 並不是一個傳統的 Java 執行環境。整個 Android 系統有相當大的系功能是透過 native code 完成的，
所以 Google 選擇了在 Android 系統內嵌一個 Linux 作業系統核心。
子計畫四的研究是在開發一套雙核心 Java 處理器以及最佳化的系統軟 體，以提供一個高效能的 Java 執行環境。一般而言，為了要提升嵌入式 Java
執行環境的效能，目前系統在實作上有兩種主要作法。一個方法是採用 Just-In-Time (JIT)編譯器，另一個方法是利用 Java 協同處理器 (co-processor) 來加速 Java 執行環境。透過一些相關的研究，我們發現上述兩種方法在嵌入 式系統的應用上各有一些問題，比方法說：
a. 當使用者啟動了一個 Java 應用程式之後，JIT 編譯器會即時把部份 Java 程式碼編譯成實體處理器可執行的機器碼，因此在一開時會造成 應用程式啟動的延遲。為了要降低延遲的時間，系統需要採用一個效 能較好的處理器。但這往往會提高成本，或是增加功耗。
b. JIT 編譯器在執行時會使用到大量額外的記憶體，而且也會大幅增加 應用程式碼的大小。例如在 Intel x86 處理器上，執行 JIT 編譯之後所 產生的程式碼與原來的程式碼相比之下，程式碼的大小增加了四倍;
而在 Sun SPARC 處理器上，則是大約增加了八倍。這樣的結果對資 源有限的嵌入式系統而言，會造成相當大的負擔。
c. 如果只是單純根據 Java stack machine 的架構設計處理器（例如 JOP 計畫），那麼在處理通訊及多媒體的工作時，效率又往往不好。
d. Java 協同處理器雖然可以解決上述各種問題，但又會受限於特定的 架構。例如 ARM Jazelle 是最有名的 Java 協同處理器，但只能限於採 用 ARM 架構的系統，這對於一些想要支援 Java 環境的其它處理器開 發團隊而言並不適用。
就嵌入式系統的應用而言，利用 Java 處理器來加速應用程式的執行仍然 是比較好的做法。因此，子計畫四目的是開發適合用在嵌入式多媒體平台上的 異質雙核心 Java 應用處理器，以及支援圖型介面的 Java 執行環境。
七、結果與討論
為了能設計出一個高效能，有彈性，能跟不同的 general-purpose 處理器 和作業系統做整合的 Java 執行環境，在子計畫四，我們所開發的關鍵技術有 以下幾項：
Java 處理器核心
把 Java 處理器核心和任意 general-purpose 處理器整合成一個異質 雙核心的 Java 應用處理器所需的介面電路設計
Java 執行環境的系統軟體設計
符 合 CDC/PBP 及 DVB-MHP 規 格 的 系 統 中 介 軟 體 ( 包 含 Java classes library 及 native code library)
我們會採用異質雙核心架構的理由是，一方面可以透過 Java 核心有效率地執行 Java 程式，而且也能夠利用 RISC 核心來處理 I/O 的動作。以下，我們就針對上 述的關鍵技術的開發成果做一個大概的介紹：
在 Java 處理器核心的設計方面，我們採用了 double-issue stack
machine 的架構，每一個 clock cycle 會執行兩個 bytecode。Java 核 心是設計成一個獨立的 IP，可以和任何 general-purpose 處理器整合，
形成一個異質多核心系統。跟目前業界常用的 ARM Jazella 的 Java 核心不一樣的是，ARM 的 Jazella 是透過 ARM 的 co-processor interface 和主處理器溝通，所以一定要和 ARM 處理器合用。而我們 的 Java 處理器核心則沒有這個限制。目前我們已經成功地分別和 PowerPC 405 處理器核心以及 Microblaze 處理器核心進行整合測 試。
在異質雙核心的介面電路設計方面，因為我們的 Java 處理核心是設 計成一個獨立有 master interface 的 IP，所以可以透過標準的 shared memory 和 interrupt-driven 機制和主處理器進行 IPC。另外，我們也 針對 Java 語言的特性設計了特別的 IPC 機制，可以快速的進行 Java-to-C 的呼叫。
在 Java 執行環境的系統軟體設計方面，我們的系統不需要依賴一個 功能完整的作業系統(e.g. Linux)就可以執行圖形介面的應用程式。並 且整個系統軟體的部分可以輕易的移植到任何能做中斷程序管理的 系統內核(kernel)之中。因此不管將來目標平台是採用何種作業系 統，都可以輕易和我們的 Java 環境進行整合。目前我們己經驗證測 試過和 Linux 的整合，以及無作業系統的獨立運作驗證。
在系統中介軟體的設計方面，最關鍵的核心中介軟體如 Java 的基本 class library (如 CDC Foundation classes、Java AWT classes、Java TV classes ) 以及 native code 的軟體（如 2D graphics library、JMF media accelerator interface）我們會重新開發出能支援 DVB-MHP UI 介面的
在系統中介軟體的設計方面，最關鍵的核心中介軟體如 Java 的基本 class library (如 CDC Foundation classes、Java AWT classes、Java TV classes ) 以及 native code 的軟體（如 2D graphics library、JMF media accelerator interface）我們會重新開發出能支援 DVB-MHP UI 介面的