在嵌入式工業設備、消費類娛樂產品和小型計算裝置等多媒體應用中,設計實現、系統效率和高質量編解碼器方面存在著許多挑戰,設計人員需要了解如何選擇正確的處理引擎以構建靈活的IP視像系統。本文討論一種基于數字信號處理器的解決方案,可以降低開發成本,同時保持較高的性能。

許多嵌入式系統面臨的設計挑戰涉及到如何降低設計成本而又不犧牲性能,一些優秀的處理器如英特爾80200或德州儀器TMS320C6205之類的DSP也存在這樣的問題。設計人員需要使用有效針對平臺的數據流模型,根據平臺選擇內部循環優化措施,降低計算的復雜程度。這樣才能在性能上得到極大改進,即使是對移動多媒體系統視像驗證模型編碼器(MoMuSys)這樣的開放源代碼視頻MPEG-4編解碼器,也不需要在視像質量方面做出犧牲,另外還可按特定用戶的要求定制編解碼器性能和質量。

PAL和NTSC電視信號分別為25幀/秒和30幀/秒,因此在一個CIF圖像中,編碼器每秒必須處理396×30個宏塊(macroblock)。在一個幀處理期間,對每個宏塊都要從4Y 8×8的塊中計算產生最小誤差MB的運動矢量,然后全誤差MB(即6個模塊)通過離散余弦轉換(DCT)后再進行量化。此外為保持與解碼器同步,編碼器要對所有模塊進行去量化和逆向DCT,以重新構建完全編解碼的視像幀。簡單運動編解碼器運算次數范圍為每秒9,700萬次至億次(表1)。

必須使用半像素運動估計以便從編解碼器中得到合適的視像質量。對于估計所需要的MIPS數來講,在軟件中實現全MPEG-4簡單類系統是非常困難的,如果要用廉價(低于30美元)的DSP實現MPEG-4編解碼器,需大幅降低計算復雜性,這類器件為可用MIPS數設定了一個界限。

將MPEG-4編解碼器用于IP視像系統時,還有一些其它的靈活性和處理要求。系統核心功能是將原始視像信號轉換到壓縮的IP數據包中,最簡單的情況是把模擬攝像頭的IP數據流傳遞到PC機上,然后解壓并向用戶回放出視頻影像。

選擇正確的處理引擎

目前市面上有幾種用于視像壓縮的處理器,它可以作為IP視像系統的一部分。這些處理器分成四類,即專用視像處理器(DVP)、多媒體協處理器(MMCP)、專用編解碼處理器(DCP)和通用信號處理器(GSP),每種都有各自的優缺點(表2)。

DVP是在DSP上擴展了專用于視像應用的部分,通常有一個DSP或RISC內核,再加上專用的視像壓縮輔助硬件,如松下的視頻信號處理器VDSP2和擴展8×8視頻通信處理器VCPex。MMCP類似于DVP,但包括聲音壓縮、圖形和其它多媒體擴展功能,如飛利浦的TM32A處理器。DCP指專用硬件,設計用于按MPEG-4之類特定壓縮標準進行編解碼。最后一種GSP是具有擴展指令集的通用DSP,指令集包括專門用于視像壓縮和解壓操作的其它功能,如德州儀器的C6xx系列及BSP-15。

DVP和MMCP專門用于視頻/多媒體,相應有一個硅片開發成本的問題。由于內部復雜,包含許多壓縮輔助協處理單元,所以這些芯片的軟件開發費用也相當高。不過它們通常結合了視像采集和轉儲能力,這樣可以去掉額外的外圍電路,降低整個IP視像系統的費用。DCP系統能夠達到很高的性能,但芯片開發費用高,且編程靈活性很低。

總的來講,我們相信GSP是所有產品中最靈活的,針對多種應用進行大批量生產,所以價格便宜,而且因為簡單,在所有編解碼器中開發費用最低。缺點是在IP系統中,依然需要視像采集和轉儲方面的硬件。

構建靈活的IP視像系統

在我們選擇的基于DSP的設計中(圖1),來自攝像頭即通過幀采集器得到的數據被送到編解碼處理器的SDRAM中。這里我們用的是德州儀器的C6205 DSP,速度為200MHz,每個時鐘周期可執行8個32位指令(高達10次運算)。

該處理器用于對幀采集器提供的原始視像數據進行編碼,主處理器是時鐘為533MHz的Intel 80200,用于執行主要任務,從DSP處理器中取得數據并打包,再經過以太網(使用IP)進行網絡發送。不過考慮到實現編解碼器所需的MIPS數量,應在早期做出決定劃分編解碼器,使主處理器完成數據的熵(即VLE)編碼。

主處理器也運行Linux內核,它的任務還有配置和控制包括DSP在內的所有外圍器件。整個系統在內部通過PCI總線進行通信,之所以用PCI作為嵌入式總線架構是因為其應用歷史悠久,公認比較穩定,而且易于使用,如果市場需要更大處理能力而增加額外的外圍器件,PCI也很容易擴展。

我們的IP視像系統總體解決方案顯示了高度可升級性。主處理器和DSP處理器都在英特爾和德州儀器各自的長期開發產品線上,一些新型更快的設計不久就會推出。因為DSP執行大多數視像壓縮任務,所以主處理器還有多余的MIPS可供給與視像無關的特殊用戶要求。

此外,該設計在編解碼器實現方面也具有很大靈活性,相比于其它常用方案這里的編解碼器開發速度非常快,雖然性能上有所欠缺但在簡單性方面進行了彌補,即使更廉價的DSP也有能力運行全幀速率及高質量編解碼器。它可以滿足將來的新標準和更先進的特性,很容易用更高性能的型號來代替,設計更新速度比專用視像處理器快。

GSP還沒有強大到足以滿足非常高性能要求的地步,如高空間分辨率4CIF、16CIF等,不過我們的硬件在設計時已考慮了以后的擴展,現在考慮的其它方案是使用專用DCP替代編解碼器處理器以及轉儲器和采集器,這些未來方案的目標應用是IP數字視像市場上的高性能終端。

C6205 DSP處理器的內核可以并行執行8條32位指令,并能以200MHz速度在每個周期執行高達10個基本算法操作擴展指令集。具有全并行化特性的內核理論上可以達到1,600MIPS,或2,000MBOPS。但實際上目前任何軟件要達到這一點都是極其困難的,根據上面對編解碼器復雜性的討論可以看到,選擇這樣的處理器將無法執行全幀速率MPEG-4編解碼器。

市場的壓力即費用上的考慮使我們只能這樣選,但即使如此,所要求的性能標準即30幀/秒的高質量視像還是能夠達到。DSP內部有64KB程序和數據存儲器,兩者都能配置成高速緩沖存儲器或快速RAM。在我們的平臺上,DSP擴展存儲器接口(EMIF)連在16MB的SDRAM上。

為測試我們的設計,我們使用移動多媒體系統視像驗證模型編碼器。這個MPEG-4編碼器從來就不是一個高性能編碼器,但卻是由國際標準化組織(ISO)提供的,作為MPEG-4編解碼器開發和質量指導。

編解碼器代碼首先簡化為生成MoMuSys MPEG-4簡單類編碼器所需的最簡值。為了事先對任務有一個概念,先將現在更容易管理的基本代碼下載到DSP的SDRAM中并執行,并將內部數據和程序存儲器配置成高速緩沖存儲器,所產生的幀速率(MPEG-4量化器值為3,沒有速率控制)對于內部幀約為0.1幀/秒,這個數字不包括VLE處理(圖2)。

VLE之所以不包括在這一測量中是因為我們知道在最終系統中,編解碼器這一部分將在80200主處理器中執行,用以平衡總的計算負載。幀間速率沒有作估計,不過由于ME/MC是運動編解碼器一個重要計算部分,所以該性能會比較差,或許要差一個數量級。

此外,僅用一個內部幀編解碼器(負的VLE)也很容易工作,因為該特性與圖像無關,使我們能準確測量DSP的性能。在這點上請注意編解碼器性能比我們需要的30幀/秒之間相差300倍以上。

在標準PC上的MoMuSys MPEG-4簡單類編碼器性能要比上面的設計好幾個數量級,但DSP技術規范中MIPS部分并不比英特爾奔騰系列處理器差幾個數量級,所以很顯然,DSP內核的能力還沒有完全發揮出來。

帶寬制約速度

我們懷疑這主要是由于高速緩沖存儲器出現錯誤而影響到SDRAM的訪問速度。雖然除了經過TI編譯器優化外,代碼沒有再對DSP內核進行其它優化,所以可能沒有達到最優,但我們還是認為有其它異常因素導致性能降低。后來在檢查產生幀值數據的SDRAM和內部數據RAM(IDRAM)之間帶寬時才找到原因。

MoMuSys是一個基于幀的編解碼器,這表示它以全幀進行每一級編碼,與基于宏模塊的編解碼器不同,它每次都在宏模塊上進行全編碼過程。

單從這一點就可以看到,僅對幀數據一項編碼器就需要大容量SDRAM來處理視像輸入幀。此外,DCT和定量器需要12位數據(用于8位/像素的輸入圖像),因此所有幀都以16位/像素數據格式存儲,這些幀總共要數據存儲器。

對MoMuSys碼的檢查顯示,處理一個幀需要的存儲器大約是2MB,包括幀數據、ACDC預測數據和運動矢量數據。當編碼器工作于PC5時,存儲器使用情況分析顯示它需要8M字節存儲器用于正常工作。

我們預計每幀存儲器用量很可能在2到8MB之間。在正確設計的高速緩沖存儲器相關系統中,高速緩沖存儲器容量(64KB)和處理1幀所要求的存儲器容量(2～8MB)之間存在著巨大差異,但這一差異本身不會給來自SDRAM的高速緩沖存儲器線路負載性能造成問題。

不過,存儲器訪問空間結構被認為是引起高速緩沖存儲器高失誤率的原因,并因此使性能大大降低。我們在這一級做了深入耗時的高速緩沖存儲器分析,試圖優化這一類編解碼器用于DSP。

對于存儲器要求來講,基于宏塊的編解碼器更為有效。此外編解碼器每處理一幀需要訪問大量完全不同的數據,所以設計一個好的帶高速緩沖存儲器的編解碼器是很難的,不管是基于幀還是基于宏塊。因此我們后來決定關閉高速緩沖存儲器,并用完善的DSP可編程DMA引擎來管理SDRAM和內部數據RAM(IDRAM)間數據傳遞。所有DSP內核訪問僅限于內部數據RAM,SDRAM和IDRAM間的DMA處理將與CPU內核存儲器訪問并行執行,如果我們在IDRAM上進行旋轉式緩沖器排列,可以假定不會有數據庫沖突。

同樣我們也關閉程序高速緩存操作,另外還做了一些工作保持代碼長度小于64K字節,這也給了我們另外一個理由放棄大部分MoMuSys代碼。

運動估計/運動補償算法是一個有效的專用快速運動估計算法,局限在一個16像素搜索范圍內,顯然與搜索區域大小緊密相配。所有的幀表達現在都用8比特/像素格式,代碼如果在DCT和量化時還需更進一步精確,我們將提供額外的存儲空間作為IDRAM靜態預分配區域。MB以Y1Y3Y2Y4CbCr格式存儲,即將Y3和Y2作了交換。讓DSP的4個可用DMA通道直接存儲器訪問全部MB(6個模塊),并仍保持存儲器中每個相鄰模塊像素排列不變,這樣做很有必要,它也是TI為DSP提供的必須采用的格式用于DCT庫。所有其它程序數據都留在IDRAM內,總計,幾乎沒有什么空間可以備用。較小的IDRAM需要一個稍微不同的數據模型,結果是DMA總線利用更為充分。

這個基于MB的編解碼器所用存儲器帶寬在SDRAM和IDRAM之間,很容易估計,每幀處理需要742KB DMA,5個幀值,這里一幀是352×288×1.5個字節,所以對于每秒30個NTSC幀而言,DMA引擎必須每秒傳遞大約22M字節的數據,在SDRAM和IDRAM之間的100MHz 32位總線中它將使用大約1/18的帶寬。這完全在TI DSP的DMA性能和我們使用的SDRAM界限內,我們的32位可尋址SDRAM時鐘為100MHz,每排訪問損失的SDRAM時鐘小于5個,相當于10個DSP時鐘周期。

從這一點可以看到數據模型已按IDRAM的大小作了修改,對DSP訪問進行了優化處理,但卻沒有充分利用DMA。該數據模型在速度性能上的改進如果沒有重要配置或優化條件,則相比于以前的結果是非常令人驚訝的。這一級幀內性能為20幀/秒數量級,即在非常需要存儲器的MoMuSys幀基編解碼器上性能改進了200倍。當加入我們專用的ME/MC子系統時,一般使用一個代碼仿形器,可以看到消耗了30～50%的可用時鐘周期,這時幀間性能估計最壞為10幀/秒。

技術突破

在設計編解碼器中如何獲得最好的并行效果是一個很大的挑戰,必須保證DSP內核邏輯單元得到最好應用。在多數情況下,這要留給非常強大的DSP優化器來做,但TI的編輯器也包含了用于軟件循環流水操作的算法。

編解碼器實現一般包含許多圍繞像素的循環內容,這些循環又在模塊、MB或幀中,所以它們非常適合進行優化,一個循環的流水作業意味著兩個或更多循環反復將并行執行。TI編輯器在其流水作業性能上提供反饋以便在過程中提供幫助,如果某些DSP內核邏輯單元利用不足或過度,常常可用再排列或再設計循環來糾正,并減少執行中的循環數。

用上述方法進一步優化,即使用TI仿形器和TI DSP編輯器反饋選件,可以使性能改進高達7倍,達到140幀間/秒的速率。在我們能夠發現的最具計算挑戰性的圖像方面,最優ME/MC結果在幀內處理速率可達31幀/秒。

采用上述方法獲得的性能改進非常可觀,并顯示出在DSP上對編解碼器進行編程的原始方法很可能在代碼中極少用到DSP的真正性能,好的數據流模型和對DSP內核性能的認識使我們能極大改進性能。

另外還需要做很多工作減少計算的復雜性,因為廉價DSP沒有足夠的MIPS解決編解碼器壓縮問題,不過仍有可能在圖像質量方面獲得更好性能,得到一個速度保持為30幀/秒,且具有CIF分辨率的實時商用級編解碼器。

相關鏈接

如何在嵌入式電子設備中建立多媒體文件系統

數字視頻應用分類和DSP的選擇策略

如何實現無線多媒體設備的雙向視頻流傳輸功能

作者:Barry D. McDonald

系統設計師

Indigovision有限公司