采用OMAP3的視頻解碼器的通用解碼方案介紹
加入技術(shù)交流群
在視頻編解碼過程中，運(yùn)動(dòng)估計(jì)、DCT/IDCT和像素插值占據(jù)了大量的運(yùn)算時(shí)間，0MAP平臺(tái)提供的硬件加速單元可以高效地完成上述運(yùn)算，而幾乎不占用CPU時(shí)鐘(這里，不占用是指運(yùn)算過程，實(shí)際上數(shù)據(jù)的輸入輸出仍需要花費(fèi)少量時(shí)間);同時(shí)，優(yōu)化的軟件加速單元也可以較快地完成運(yùn)算。以DCT/IDCT為例，耗時(shí)情況如表1所列。本文引用地址：http://www.ex-cimer.com/article/148968.htm
由表1可知，硬件DCT耗時(shí)約為軟件DCT的1/7，硬件IDCT耗時(shí)約為軟件IDCT的1/4.5。因此，采用硬件加速模塊可以極大地提高運(yùn)算速度并降低功耗。
對(duì)于最新的H.264以及AVS標(biāo)準(zhǔn)，需要采用
從表2中可以看出，在H.264的解碼過程中，環(huán)路濾波、插值以及反變換反量化占據(jù)了超過70%的計(jì)算時(shí)間。因此，用0MAP3530來進(jìn)行H.264以及AVS的解碼時(shí)，如果能有效地利用0MAP3530的硬件加速資源，可以提高計(jì)算效率，實(shí)現(xiàn)實(shí)時(shí)解碼。另外，除了硬件加速器之外，0MAP3530的體系結(jié)構(gòu)比較適合于視頻處理，這主要基于以下考慮：
?、倌壳笆袌?chǎng)上推出的整合了ARM與DSP的多媒體專用芯片并不多，OMAP可以使用單一芯片實(shí)現(xiàn)嵌入式操作系統(tǒng)(Linux、WinCE等)的功能，并且可以獲得TI廣大的第三方提供的豐富的算法支持?；诓僮飨到y(tǒng)的編程更靈活方便，便于產(chǎn)品的軟件升級(jí)。相比之下，單一的DSP無法實(shí)現(xiàn)操作系統(tǒng)的功能，若額外采用ARM構(gòu)建操作系統(tǒng)，成本以及硬件軟件復(fù)雜度無疑會(huì)大于采用OMAP平臺(tái)。
?、诠牡目紤]。表3列出了OMAPl510上運(yùn)行MPEG4解碼時(shí)的功耗情況。
可以看出，在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)算速度。
評(píng)論