新一代多媒體壓縮演算法發展出JPEG2000 與MPEG-4兩項標準。這些標準對於記憶體、傳輸以及運算等方面的要求在標準化的過程中持續演進，如今已進入實際建置的階段。近來矽元件在邏輯閘密度發展，為多媒體產業開啟許多發展的新空間。本文將介紹各種多媒體壓縮技術的需求，以及評估多媒體壓縮處理的設計複雜度。並將探索建置多媒體處理環境之設計流程所需的抽象程度。最後將分析JPEG2000與MPEG-4的各種新興壓縮標準，以及如何與FPGA技術發展結合，支援即時（Real Time）多媒體系統。

多媒體壓縮需求

數位多媒體通訊隨著各種市場的發展而迅速成長，其中包括各種無線通訊、醫學影像、一直到數位劇院等。多媒體壓縮技術扮演重要的支援角色，讓系統能有效率地運用現有的儲存與頻寬資源滿足通訊的需求。初期的技術從1980年代後期一直發展至1990年代，其中包括JPEG、MPEG-1及MPEG-2。目前，國際標準組織（ISO）持續推展標準化工作，制定完成JPEG2000與MPEG-4標準。同時，國際標準組織繼續針對3D與可延伸影片技術發展新的支援標準。但是您可能會問：為何數位音效與影片技術會不斷在演進之中？答案在於演算法底層的運算架構。新矽元件技術支援愈來愈高的運算週期、記憶體以及記憶體傳輸頻寬，為壓縮演算法開啟新的發展空間，因此許多替代方案就成為可行的技術。

最初的數位影像壓縮技術是擷取自JPEG與MPEG-1標準。數位影像壓縮的基礎結合三項主要演算演算消費，包括轉換、量子化、以及來源編碼。最普遍的JPEG標準基本上是運用一套8×8 的離散餘弦轉換（DCT）法。其量子化的步驟包括看似不重要的DCT系數歸零。若量子化的門檻過高，最後壓縮出的影像中就會出現馬賽克現象（Decompressed Image）。

在JPEG上，這種現象通常發生在壓縮比高於30比1的條件中。對於軟體進行JPEG擷取時通常會提供充裕的反應時間，以便進行壓縮與解壓縮作業。在醫學影像或視訊監視中需要每秒播放30格影像的即時運算效率。因此需要在33毫秒的時間內完成DCT、量子化以及Huffman 編碼等運算，才能維持所需要的畫格更新速度。

JPEG隨著業界採納JPEG2000標準而繼續發展。JPEG2000標準採用完全不同的技術，配合離散波長轉換（DWT）、位元面編碼以及演算編碼作為主要的演算技術。JPEG2000不像JPEG在高壓縮時會出現馬賽克現象，但在圖塊邊緣會產生所謂的蚊影效果（Mosquito Effect）。JPEG2000的壓縮比通常為50比1，且品質接近壓縮比為30比1的JPEG。JPEG2000有許多具吸引力的特色，其中包括：

在即時動作的JPEG2000畫格方面，DWT、位元編碼以及演算編碼的運算皆更為複雜，且需要更多的MOPS、記憶體以及記憶體頻寬。影片壓縮標準是由國際電信聯盟（ITU）與ISO MPEG負責制定。這些標準延伸畫格間演算法的範圍，納入暫時性畫格冗餘度縮減技術，並延用圖塊型DCT技術支援轉換以及可變長度編碼技術，進行來源編碼。這套涵蓋MPEG-1、MPEG-2（H.262）、MPEG-4 version 2以及MPEG-4 Part 10 Advanced Video Codec（AVC、H.264）的技術一般稱為動作預測－補償DCT型影片壓縮法。

在影片壓縮方面，採用固定位元率作為目標值而非壓縮比。發展出的各種影片編／解碼器透過速度扭曲曲線進行評估，量測其峰值訊號／雜訊率（PSNR）比以及位元率。影片編碼的發展目標是希望達成維持品質同時降低位元率的目的。就影片編碼器而言，須考量運算、記憶體以及記憶體頻寬等方面的因素。MPEG編／解碼器方面，編碼器的複雜度高於解碼器。這種刻意的不對稱性設計，是希望在初期的編碼設計中造就出低成本的解碼器。MPEG-4如今正擴展至雙向通訊環境，故MPEG-4的即時編碼問題亦逐漸浮上檯面。

在建置即時多媒體壓縮標準方面，要先分析有關MOPS、記憶體佔用空間以及記憶體頻寬等方面的需求。在滿足上述目標後，可以考量如何讓矽元件大小能配合應用系統。若考量運算MOPS，如(圖一)所示，現有的各種選擇對於許多DSP應用系統而言，通常有許多建置選擇，有些屬於通用型，有些則為特殊應用。在較高的運算複雜度方面包括各種多媒體應用，例如影片與音效處理。通常單一處理器可因應一種處理需求，但大多數系統都涉及許多影片處理，有些甚至須使用多種通道。在下個段落中將討論即使是在CIF解析度下的簡單編碼，若不注意採用的動作預測演算法，MPEG-4編碼很容易就會超過7000 MOPS。

《圖一　不同矽元件MOPS一覽表》

處理潛能雖然是選擇平台時的重要考量因素，但其它設計特性亦須納入考量的範圍。(表一)列出一些設計流程中的考量因素，包括：耗用的設計資源、設計架構彈性、執行階段彈性、最高速度以及能源效率。通用型處理器（GPP）、數位訊號處理器（DSP）以及特殊應用訊號處理器（ASSP）提供耗用資源較少的演算平台，但對於許多高階嵌入型應用而言，這些方案的彈性與處理效能較不充裕。

ASIC則提供優異的處理效能與省電效率，但昂貴的非重複開發成本讓其僅適合支援產量極高的產品。各種軟體／硬體協同設計平台具備極高的處理效能，例如像現場可編程邏輯閘陣列（FPGA），讓業者能同步研發軟體與硬體，開發出一套高階可編程平台。如圖一所示，若充份運用FPGA的處理效能，就會讓它成為一項極具吸引力的高階解決方案。

多媒體壓縮設計複雜度

要瞭解MPEG-4標準的壓縮設計複雜度，必須先瞭解壓縮設定與壓縮比率決定不同的運作模式。MPEG的設定檔（Profile）決定使用的技術，例如像DCT或可變長度來源編碼。MPEG中的壓縮比率（Level）決定要處理多少參數才能達到標準的規範，例如像每秒多少MacroBlocks。其它須瞭解的重要壓縮觀念，與要遵循的標準有關。嚴格說來，解碼器的位元流是根據編碼器所制定，但其需求並不是由標準所規範。

應用系統採用的設定與壓縮比影響運算MOPS。編碼器許多設計複雜度的考量因素，皆與應用的種類有直接關連。MPEG編碼器雖較複雜，但其優點是僅須建立一組符合需求的位元流，而MPEG解碼器就須配合MPEG的設定檔與壓縮比。(圖二)顯示MPEG-4標準中MPEG-4設定檔與壓縮比的相關運算MOPS。尖峰記憶體需求以及記憶體頻寬需求亦與設定檔與壓縮比有關。例如像MPEG-4編碼器中，典型的記憶體需求為3至10 MB，而解碼器則為1至3MB。此外，記憶體頻寬需求與應用系統所採用的建置架構有密切關係。

《圖二　MPEG-4設定檔與壓縮比的相關運算MOPS》

Motion JPEG2000在不同的最終應用中亦有不同程度的需求。在影像監視系統中，每秒30格、640×480解析度的影片資料流約需4200 MOPS，每秒60格、1024×1024解析度的無損耗編碼需要29000 MOPS；而每秒24格、4096×2048解析度的數位電影則須高達93000 MOPS，這些應用皆是屬於JPEG2000技術應用。更複雜的是，記憶體大小、記憶體頻寬與影像及資料序列皆有關連性。JPEG與MPEG的實際每畫格MOPS與應用種類有密切的關連。對於MPEG畫格內運算所使用的資源與畫格間動作差異所使用的運算資源完全不同。這點顯示架構含有一定程度的擴充性，能處理不同複雜度的運算。影片編／解碼器的一項重要參數就是能維持畫格率的能力。架構除了須支援平均MOPS外，亦須支援最壞狀況下尖峰MOPS的效能需求。

多媒體壓縮設計流程

為有效率地建置多媒體壓縮系統，須先從以C語言撰寫的標準程式碼著手。即使不是遵循各種壓縮標準，在初期設計中採用C程式碼也是一種設計優勢，因為演算法研發者可方便地描述運算以及進行測試。C語言程式碼缺少的是一套最佳化方式，用來描述編碼與解碼器如何達到即時運作的效率。為瞭解達到即時運作的必要步驟，可以規畫一套流程，內含演算法擷取、架構分析、實現以及建置等步驟。

再像是通用型處理器、DSP處理器以及媒體處理器等矽元件上建置媒體壓縮功能的資料碼與編譯技術，其優點是：設計流程明確易懂，開始投入所需的技巧僅是一套簡易的編程作業。但是其問題在於：如何運用處理器矽元件技術建置即時的串流媒體系統。不論處理器內含一組或多組處理單元，問題在於即時運算資料流在壓縮演算過程中須經過處理單元數次。要克服串流處理的瓶頸，設計業者須瞭解與運用專為解決串流問題所量身訂製的特殊指令，充份發揮少數處理單元的效能。

《圖三　規畫中的多媒體工具流程》

另一方面，市面上有FPGA與ASIC的設計流程，支援業者所需的平行處理機制，達到即時運作的目標。透過平行機制達到更高效能，所付出的代價就是效率較低的設計流程。傳統的FPGA與ASIC設計流程要求研發業者設計一套硬體描述語言（HDL），配合矽元件的合成作業。由於目標不是馮若曼（von Neumann ）或哈佛（Harvard）的電腦架構，故仍保有一定之彈性。首先使用者須決定一套架構，第二，使用者須決定如何在架構之間讓演算法進行通訊。這種架構所需的設計技巧，高於基礎的編程技巧，且通常需要特定的專業知識。近年來愈來愈多FPGA與ASIC嵌入至矽裝置的處理器中，讓問題更為複雜。這讓業者能合併兩種設計模式，而不必運用各種設計工具達到易用性或分隔的目標。

初期擷取階段的多媒體設計流程，包含擷取串流資料的演算法以及探查階段的演算法。瞭解目標是達到即時運作（每秒30格，每秒5940 個Macroblocks），故初期擷取序列的C語言程式碼須配合資料流的設計目標。在探查階段，設計流程須能針對擷取到的資料碼預測其處理效能。在許多案例中，JPEG2000的演算程式碼須達到20000 MOPS的執行效率，並融入部份的平行處理機制，以達到系統層級參數目標。

在設計流程的實行階段，能針對運算矽元件與記憶體元件根據完整的資料擬定決策。在這個階段，須改進功能單元之間的通訊，以達到更高的預測效能。這時可能發現選擇的動作預測演算法因隨機定址的特性，故不適合搭配自行選用的記憶體。在設計的最後階段，也就是建置階段，應確認矽元件的預測使用資源，並針對處理元件進行細部調整，以達到即時處理的效能。

多媒體壓縮的實際建置

在即時系統中建置各種壓縮演算法，須瞭解演算法本身以及所建置的矽元件技術。業者希望能自行修改動態預測演算法，以便在畫質以及成本之間取得最佳的平衡點。這個領域的應用包括兩種類型：處理器（通用型、DSP、以及媒體），FPGA與ASIC皆是建置的選擇方案；或僅有FPGA與ASIC兩者是選擇方案。在第一個類型中，設計流程的考量因素經常扮演重要的角色，業者通常傾向於採用最具成本與功耗效率的處理器，以達到即時運作的目標。

FPGA解決方案確實能提供一套低成本的解決方案，但由於建置FPGA所需的技術，加上目前FPGA的設計流程，促使業者因產品上市時程的因素而不願採用。ASIC的考量因素主要為大量產量與非重複研發成本。綜合以上因素，若能解決設計流程的問題，業者會選擇採用FPGA建置高階應用系統與中階產品。要建構一套完善的FPGA多媒體設計流程，採用的架構應讓串流媒體能流經FPGA架構，處理元素（PE）須分佈於整個資料通道。

《圖四　規畫中的多媒體軟體架構》

(圖四)顯示一組影片管線範例，內含各種功能性處理元件以及由一組通用處理單元所控制的記憶體。通用處理單元能控制資料流經管線的動向，並能針對每個畫格修改參數設定值。例如，若需要加入即時位元率控制機制，軟體或Orchestrator可透過處理網路的要求來變更位元率，並將處理元件修改成適當的參數。這種架構並非固定不變，而是可程式化，可自由調整記憶體處理元件以及軟體控制。在通用型FPGA架構中加入部份架構與限制，能將系統層級的研發工作與從FPGA的規格中分離，然後在後段的設計流程中再加以整合。

結論

本文討論多媒體壓縮，探討在建置即時媒體壓縮系統所可能遇見的相關問題。包括各種多媒體壓縮的需求、設計的複雜度、並規畫一套設計流程。最後筆者推測業界將更為需要運用矽元件的抽象技術，以便能有效率地運用百萬邏輯閘的矽元件技術。（作者任職於Xilinx研發實驗室）