OMAP3平臺(tái)移動(dòng)多媒體的視頻解碼方案

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

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

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

4 實(shí)驗(yàn)結(jié)果
在0MAP3530平臺(tái)上實(shí)現(xiàn)了AVS解碼，表4給出了OMAP3530上的實(shí)驗(yàn)數(shù)據(jù)。

結(jié)語
TI公司提出的0MAP體系結(jié)構(gòu)開放性好，在這種體系結(jié)構(gòu)下編寫的程序移植方便，適合于多媒體平臺(tái)的應(yīng)用。越來越多的廠商選用OMAP芯片作為移動(dòng)多媒體視頻的載體，OMAP與流行的視頻標(biāo)準(zhǔn)的結(jié)合在移動(dòng)通信與多媒體信號(hào)處理方面也將有良好的應(yīng)用前景。