OMAP3平臺移動多媒體的視頻解碼方案

可以看出，在OMAPl510平臺上，對于QCIF(常用的標準化圖像格式)、15 fps的應用來說，功耗在9．9～28．5mW。對于常見的650 mAh時的手機電池，大概可以連續工作34～59小時，這對一般的應用來說顯然是夠用的。而TI的另一款專用多媒體處理芯片DM642，其功耗為1.5W，是OMAP的50～150倍。對于便攜式的多媒體終端而言，由于并不需要太高的運算處理能力，采用OMAP平臺既能滿足需要，又可以節約電池電力。
③速度的考慮。TMS320C64X+最多可以并行執行8條指令，所以理論上的最大速度是4 160 MIPS(520MHz)。這一點相比目前最快的多媒體處理芯片DM642(4 800 MIPS，600 MHz)來說稍低，但兩者的目標定位不同。DM642主要用于實時編碼等對速度要求較高的場合，而0MAP主要用于手持設備的解碼。以H．264算法的Base Profilc為例，復雜度比MPEG-4高20％～30％。對于MPEG4，在QCIF、15 fps下需要28 MIPS；對應的H．264算法的Base Profile要求40 MIPS的運算速度。
④程序結構的考慮。DSP的片內內存速度最快，但是非常有限，所以必須將片外的數據倒入內存。由于目前的編碼方式全都是采用基于宏塊的，每個宏塊至多16×16，所以比較通用的辦法是采用，DMA方式將要用到的數據提前倒入片內。DMA傳送速度很快，所以可以并行也可以串行傳送。
⑤軟件加速的考慮。可以仿照IMGLIB的編寫規則用匯編語言對耗時最多的部分進行重寫，同時結合TI公司的數據手冊進行C語言級以及匯編級的程序優化。由于TI公司編譯器的編譯效率一直在提高，從通用及可讀性的角度上講，推薦采用C語言。

3 實時視頻解碼在OMAP上的軟件實現
在OMAP上開發程序通常分為兩部分：ARM端負責控制、顯示等；DSP端負責數據處理。采用TI公司提供的DSP開發工具CCS在這兩端分別開發，視頻解碼流程如圖2所示。

ARM端：初始化整個OMAP3530芯片，包括ARM、DSP、TC等的時鐘設置，DSP的開啟關閉以及復位，LCD、定時器等各個外設的初始化。在啟動完成后，ARM內核就一直查詢共享內存中的某一標志位，當查詢到一幀解碼結束時，就啟動LCD專用DMA，在LCD上進行顯示。
DSP端：負責壓縮的解碼。將壓縮碼流放置在SDRAM中。與基于PC的解碼程序的主要區別在于，由于DSP的片內內存有限，所以不可能將當前幀以及參考幀都放在片內，所以以宏塊為單位在SDRAM與片內內存之間進行數據傳遞。另外，由于在液晶屏上顯示時需要轉換成RGB圖像，所以，在每一幀結束后都要通過YUV轉RGB來實現實時顯示。

4 實驗結果
在0MAP3530平臺上實現了AVS解碼，表4給出了OMAP3530上的實驗數據。

結語
TI公司提出的0MAP體系結構開放性好，在這種體系結構下編寫的程序移植方便，適合于多媒體平臺的應用。越來越多的廠商選用OMAP芯片作為移動多媒體視頻的載體，OMAP與流行的視頻標準的結合在移動通信與多媒體信號處理方面也將有良好的應用前景。