用開(kāi)源API處理DSP視頻
數(shù)字信號(hào)處理器(DSP)具有出色的多媒體性能。一般而言,它們運(yùn)行編解碼器所需的周期只有通用處理器(GPP)內(nèi)核的40%到50%。DSP還能提供比ASIC大得多的靈活性和可重配置性。但迄今為止,要在數(shù)字視頻應(yīng)用中運(yùn)用DSP,編程人員還不得不花費(fèi)較多時(shí)間精力去學(xué)習(xí)相關(guān)專(zhuān)用語(yǔ)言。不過(guò),隨著應(yīng)用編程接口(API)的出現(xiàn),已不再需要學(xué)習(xí)這些專(zhuān)用DSP語(yǔ)言了。在運(yùn)行于GPP上的應(yīng)用中,API可以輕輕松松地充分發(fā)揮DSP的優(yōu)勢(shì)。
本文引用地址:http://m.butianyuan.cn/article/257906.htm開(kāi)源多媒體構(gòu)架在GPP上一般運(yùn)行在Linux操作系統(tǒng)下,是這些API的理想對(duì)象。利用API可以卸載視頻編解碼器的計(jì)算負(fù)荷,大大減小DSP編程的復(fù)雜性。這種方案只要求編程人員具備基本的DSP知識(shí)即可,無(wú)需編寫(xiě)代碼來(lái)整合DSP功能與那些運(yùn)行在GPP上的功能。這種優(yōu)勢(shì),加上利用免費(fèi)開(kāi)源插件和構(gòu)架提供的許多功能的能力,可以大幅度縮短新視頻產(chǎn)品的上市時(shí)間。
硬件平臺(tái)的選擇
在選擇運(yùn)行編解碼器(壓縮傳輸或存儲(chǔ)的數(shù)字流,再解壓以供查看或編輯)的硬件平臺(tái)時(shí),開(kāi)發(fā)人員有幾種可選方案。ASIC是專(zhuān)門(mén)為數(shù)字視頻應(yīng)用而設(shè)計(jì)的,能在這類(lèi)應(yīng)用中提供高性能和低功耗。它的缺點(diǎn)流片(NRE)費(fèi)用很高。此外,ASIC若有變化,比如改動(dòng)以適應(yīng)編解碼標(biāo)準(zhǔn),相關(guān)實(shí)現(xiàn)費(fèi)用非常高昂。
另一方面,GPP內(nèi)核的流片費(fèi)用相對(duì)較低,針對(duì)變動(dòng)進(jìn)行重編程相當(dāng)容易。但由于它們?cè)趫?zhí)行計(jì)算密集的信號(hào)處理應(yīng)用時(shí)效率低下,故在應(yīng)用于數(shù)字視頻處理時(shí)性能較低。例如,GPP通過(guò)一系列移位和加法運(yùn)算來(lái)實(shí)現(xiàn)乘法運(yùn)算,而每一個(gè)移位和加法運(yùn)算需要一個(gè)以上的時(shí)鐘周期。
DSP具有集上述二者之優(yōu)勢(shì)的潛力。不同于GPP,DSP是為數(shù)字視頻應(yīng)用中計(jì)算密集的信號(hào)處理應(yīng)用而優(yōu)化的。它具有單周期乘法器或乘法累加單元,能夠加快編解碼算法的執(zhí)行速度。更高性能的DSP還包含有幾個(gè)可以并行操作的獨(dú)立執(zhí)行單元,這使得它們能夠每條指令執(zhí)行好幾個(gè)操作。此外,DSP還提供完全的軟件編程能力,包括現(xiàn)場(chǎng)重編程能力。這就讓用戶(hù)可以先推出MPEG-2產(chǎn)品,以后再升級(jí)為H.264視頻編解碼器。DSP在數(shù)字視頻應(yīng)用中的主要局限是它們通常需要采用專(zhuān)用語(yǔ)言來(lái)編程,而熟悉DSP的編程人員遠(yuǎn)沒(méi)有熟悉流行的GPP架構(gòu)的來(lái)得多。
圖1:只含解碼器的范例中的多媒體框架職責(zé)和數(shù)據(jù)流程
組件集成的挑戰(zhàn)
數(shù)字視頻系統(tǒng)的開(kāi)發(fā)人員還面臨著集成的挑戰(zhàn)。數(shù)字視頻系統(tǒng)包含了多個(gè)編碼器、解碼器、編解碼器、多種算法及其它軟件,這些組件都必須集成到一個(gè)可執(zhí)行映象(image)中,然后才能在系統(tǒng)上運(yùn)行內(nèi)容。集成所有這些組件并確保其運(yùn)行協(xié)調(diào)是一件很困難的任務(wù)。不同的系統(tǒng)可能需要截然不同的視頻、圖像、語(yǔ)音、音頻和其他多媒體模塊。手工集成每一個(gè)軟件模塊或算法的開(kāi)發(fā)人員就被增值功能性(比如增加創(chuàng)新性功能)搞得頭痛不已。
許多數(shù)字視頻開(kāi)發(fā)人員都開(kāi)始采取開(kāi)源途徑來(lái)構(gòu)建軟件。一種常用的方案是從開(kāi)源獲得軟件的重要部分,而在可用性和硬件集成方面充分發(fā)揮內(nèi)部專(zhuān)業(yè)能力。開(kāi)發(fā)人員常常參與開(kāi)源技術(shù)開(kāi)發(fā)項(xiàng)目,以滿(mǎn)足特定要求并把內(nèi)部開(kāi)發(fā)的代碼和開(kāi)源代碼集成在一起來(lái)創(chuàng)建新產(chǎn)品。
新的API
為了解決上述問(wèn)題,德州儀器(TI)開(kāi)發(fā)出了一款A(yù)PI,該產(chǎn)品能夠充分發(fā)揮開(kāi)源多媒體框架中的GStreamer等DSP的優(yōu)勢(shì)。這款A(yù)PI使多媒體編程人員可以利用熟悉環(huán)境中的DSP編解碼引擎,把數(shù)字視頻編程人員從復(fù)雜的DSP編程中解放出來(lái),讓ARM/Linux開(kāi)發(fā)人員得以輕松利用DSP編解碼器的加速功能,無(wú)需具備相關(guān)硬件知識(shí)。該接口還能自動(dòng)高效地在ARM和DSP間進(jìn)行工作劃分,從而不再需要為運(yùn)行在DSP上和運(yùn)行在GPP內(nèi)核上的功能間的協(xié)調(diào)而編寫(xiě)代碼。該接口已由TI按照開(kāi)源社群標(biāo)準(zhǔn)以GStreamer插件的形式開(kāi)發(fā)成功。
圖2:GStreamer內(nèi)數(shù)據(jù)通過(guò)GstBuffer結(jié)構(gòu)進(jìn)行表征的方法與其它幾種操作系統(tǒng)及其相應(yīng)多媒體框架所采取的方法相一致。
GStreamer是一種媒體處理庫(kù),提供了某種轉(zhuǎn)換過(guò)程的抽象模型,其通過(guò)管道的概念進(jìn)行工作,媒體在其中按照已定義的方向從輸入流到輸出。GStreamer能夠以一種簡(jiǎn)化編程過(guò)程的方式來(lái)提取不同媒體的操作行為,在數(shù)字視頻編程社群中廣受歡迎。通過(guò)GStreamer,能夠編寫(xiě)出一種能夠支持多種不同格式和網(wǎng)絡(luò)的通用視頻或音樂(lè)播放器。而且大部分操作由插件執(zhí)行,并非GStreamer內(nèi)核。GStreamer的基本功能性主要與注冊(cè)和加載插件有關(guān),并可提供基類(lèi),這些基類(lèi)定義了GStreamer類(lèi)的基本功能。
源過(guò)濾器負(fù)責(zé)從從數(shù)據(jù)源獲取原始的多媒體數(shù)據(jù)以供處理,這里的數(shù)據(jù)源可以是硬盤(pán)文件(比如文件源過(guò)濾器),或CD或DVD光盤(pán),也可以是電視接收卡或網(wǎng)絡(luò)這種“實(shí)時(shí)”源。某些源過(guò)濾器只是簡(jiǎn)單地把原始數(shù)據(jù)傳遞到剖析器(parser)或分離過(guò)濾器(splitter filter),同時(shí)其它源過(guò)濾器也執(zhí)行自己的剖析步驟。變換過(guò)濾器 (Transform filter)接收原始數(shù)據(jù)或部分經(jīng)過(guò)處理的數(shù)據(jù),進(jìn)一步處理后再傳遞到下一級(jí)過(guò)濾器。
變換過(guò)濾器有多種類(lèi)型,剖析器即是一例。這種過(guò)濾器把原始字節(jié)流分離為多個(gè)樣本或幀、壓縮器或解壓縮器,以及格式轉(zhuǎn)換器。呈現(xiàn)過(guò)濾器(Renderer filter)一般接收完全處理過(guò)的數(shù)據(jù),并在系統(tǒng)顯示器上或通過(guò)揚(yáng)聲器或某些外部設(shè)備進(jìn)行播放。這一類(lèi)過(guò)濾器還包括“file writer (文件創(chuàng)建器)”過(guò)濾器和網(wǎng)絡(luò)傳輸過(guò)濾器,前者可以把數(shù)據(jù)保存到硬盤(pán)或其它持久穩(wěn)固的存儲(chǔ)設(shè)備上。
數(shù)據(jù)處理在plug-in_chain() 或 plug-in_loop()函數(shù)中進(jìn)行。該函數(shù)可能像元件縮放那么簡(jiǎn)單,也可能像真實(shí)的MP3解碼器那么復(fù)雜。數(shù)據(jù)被處理后,利用一個(gè)gst_pad_push()函數(shù)從GStreamer元件(element)的源襯墊(pad)發(fā)送出去,由此把數(shù)據(jù)傳遞到管道鏈的下一個(gè)元件。
GStreamer緩沖器
在GStreamer中,緩沖器是數(shù)據(jù)傳輸?shù)幕締卧stBuffer(實(shí)例)類(lèi)提供了把一個(gè)存儲(chǔ)區(qū)定義為流媒體的一部分所必需的全部狀態(tài)。經(jīng)由GstBuffer結(jié)構(gòu),Gstreame內(nèi)部的數(shù)據(jù)表示遵循幾種其它操作系統(tǒng)及其各自的多媒體構(gòu)架所采用的方法(比如,Microsoft DirectShow中的媒體采樣概念)。此外,還支持次級(jí)緩沖器,允許緩沖器的一小部分成為它自己的緩沖器,利用這種處理機(jī)制確保了存儲(chǔ)空間不會(huì)過(guò)早釋放。
圖3:復(fù)用已分配在驅(qū)動(dòng)器上且在物理上是連續(xù)的緩沖的一種有效途徑。
緩沖器通常利用gst_buffer_new()來(lái)創(chuàng)建。創(chuàng)建好一個(gè)緩沖器之后,一般是為它分配存儲(chǔ)器,設(shè)置緩沖器數(shù)據(jù)的大小。下面給出了一個(gè)緩沖器創(chuàng)建的例子,該緩沖器能夠保存具有給定寬度、高度和每像素位的視頻幀。
緩沖器創(chuàng)建
基于DaVinci技術(shù)的DM644x器件上ARM926的MMU(存儲(chǔ)器管理單元)具有虛擬/物理尋址能力。然而,C64x+DSP內(nèi)核只能夠處理物理地址。因此,用于DSP處理的輸入和輸出緩沖器必須駐存在物理上連續(xù)的存儲(chǔ)器中。
虛擬到物理地址的轉(zhuǎn)換由編解碼引擎處理。通過(guò)復(fù)用(指針指向)某些由驅(qū)動(dòng)器分配的緩沖器,可獲得物理上連續(xù)的存儲(chǔ)器,這里使用了Linux中的一些技術(shù),比如dma_alloc_coherent(),來(lái)在內(nèi)核空間中分配這類(lèi)存儲(chǔ)器。由TI開(kāi)發(fā)的庫(kù)/內(nèi)核模塊CMEM,允許從用戶(hù)空間應(yīng)用來(lái)分配物理上連續(xù)的存儲(chǔ)器。
例如,我們利用前面提到的CMEM驅(qū)動(dòng)器來(lái)分配物理上連續(xù)的“輸出”緩沖器。編解碼引擎對(duì)幀進(jìn)行解碼,并把解碼后的幀放在輸出緩沖器中。
接下來(lái),指向輸出緩沖器的指針被傳遞給fbvideosink(通過(guò) GstBuffer)。這個(gè)videosink必須把解碼后的數(shù)據(jù)memcpy(復(fù)制)到幀緩存中,然后才能顯示。由于memcpy操作是一種成本很高的GPP使用,這種方法使得ARM 和DDR接口的負(fù)載很重,因而增加了功耗,且效率極低。
這種技術(shù)對(duì)非常小的緩沖器是可行的,但在開(kāi)發(fā)人員使用D1(和更高)大小的緩沖器時(shí),將開(kāi)始降低系統(tǒng)性能。一種更有效的方案是復(fù)用已經(jīng)驅(qū)動(dòng)器分配了的物理連續(xù)緩沖器,并在編解碼器引擎和videosink插件之間把指向這些緩沖器的指針來(lái)回傳遞。幸運(yùn)的是,GStreamer提供了一個(gè)便于這類(lèi)交互作用的API。
這個(gè)API替代方案利用gst_buffer_new()來(lái)創(chuàng)建新的緩沖器。當(dāng)元件獲知它將在哪一個(gè)源襯墊上推動(dòng)數(shù)據(jù)時(shí),就對(duì)gst_pad_alloc_buffer()函數(shù)進(jìn)行調(diào)用。這允許對(duì)應(yīng)的元件為調(diào)用元件的工作提供特殊的“硬件”緩沖器,故而減少了系統(tǒng)所需的memcpys數(shù)量。
視頻解碼器插件(變換過(guò)濾器,通過(guò)編解碼器引擎API能夠充分利用DSP的優(yōu)勢(shì))將把從視頻呈現(xiàn)過(guò)濾器獲得的緩沖器用作視頻解碼器和執(zhí)行解碼的輸出緩沖器。一旦解碼完成,這個(gè)輸出緩沖器將被推動(dòng)(即指針被傳遞)給視頻呈現(xiàn)過(guò)濾器插件。由于解碼后的圖像已經(jīng)存在于視頻驅(qū)動(dòng)存儲(chǔ)器中,就不再需要memcpy了,在幀被顯示時(shí),視頻呈現(xiàn)過(guò)濾器將只需把目前的顯示緩沖器轉(zhuǎn)換為這種特定的緩沖器就可以了。
AV同步處理
播放期間的音頻/視頻(AV)同步處理一般需要三類(lèi)決策:一是重復(fù)幀的決策。一般在媒體流的幀的顯示時(shí)間比幀間隔時(shí)間更大時(shí)采用。二是顯示幀的決策。一般在媒體流的幀的顯示時(shí)間在最小和最大閾值之間時(shí)采用。三是跳幀決策。一般在幀的顯示時(shí)間落后顯示時(shí)間至少兩個(gè)幀時(shí)采用。這樣,跳過(guò)當(dāng)前幀,處理下一個(gè)幀,以期彌補(bǔ)下一個(gè)幀間隔。持續(xù)這樣做直到下一個(gè)幀被顯示或不再剩有幀可供比較。
另外,管道中的所有元件都使用共同的時(shí)鐘,以便于這些活動(dòng)的進(jìn)行。幸運(yùn)的是,所有這些決策都由GStreamer內(nèi)核庫(kù)中的音頻視頻sink基類(lèi)來(lái)完成。這樣一來(lái),AV同步的復(fù)雜性大部分都在用戶(hù)那里被轉(zhuǎn)移了。
以插件形式開(kāi)發(fā)的接口
TI開(kāi)發(fā)了一種GStreamer變換過(guò)濾器插件,它利用DSP來(lái)進(jìn)行視頻解碼,運(yùn)行于ARM上,使用Linux操作系統(tǒng)。TI還提供有Linux外設(shè)驅(qū)動(dòng)器,在驅(qū)動(dòng)器接口和編解碼引擎API方面符合標(biāo)準(zhǔn)開(kāi)源機(jī)構(gòu)的要求,后者注意了DSP編程的相當(dāng)大部分的復(fù)雜性。由硬件制造商提供的API,事先已針對(duì)硬件實(shí)現(xiàn)做了優(yōu)化。如果改用新的硬件,無(wú)需改變應(yīng)用代碼就可直接替以新的驅(qū)動(dòng)器。這種方案大幅度降低了視頻開(kāi)發(fā)的成本和交付周期。
硬件的計(jì)算資源以一種最優(yōu)方式被執(zhí)行,無(wú)需任何匯編編程。其中包括很多復(fù)雜的操作,比如DSP資源的最佳利用,和基于硬件的加速引擎;鏈接模式(chained mode)下增強(qiáng)型直接存儲(chǔ)器訪問(wèn)(Enhanced Direct Memory Access)外設(shè)的使用,
以提高數(shù)據(jù)傳輸效率;以及中斷模式和tasklet模式的數(shù)據(jù)包處理,以靈活滿(mǎn)足不同應(yīng)用的要求。
由于GStreamer是一種非常流行、廣為人知的架構(gòu),它已成為數(shù)字視頻開(kāi)發(fā)的一種標(biāo)準(zhǔn),在這種環(huán)境中充分利用 DSP優(yōu)勢(shì)的能力使得編程人員不再需要學(xué)習(xí)專(zhuān)用DSP編程語(yǔ)言。
該方案還易于把DSP的功能和GPP內(nèi)核上運(yùn)行的典型應(yīng)用的一些其他要求集成在一起。利用其他GStreamer插件,可以把解碼編碼與數(shù)字視頻應(yīng)用所需的其他操作相結(jié)合。這種多媒體架構(gòu)通過(guò)把各種本來(lái)需要手工編碼的操作整合在一起來(lái)實(shí)現(xiàn)集成。
總而言之,這一新接口能夠利用GStreamer Linux多媒體構(gòu)架來(lái)充分發(fā)揮TI的DaVinci處理器平臺(tái)的軟件基礎(chǔ)架構(gòu)的優(yōu)勢(shì)。這種整合型的基礎(chǔ)架構(gòu)提供了靈活的構(gòu)架,能夠適應(yīng)新一代多媒體編解碼器的要求。
該軟件架構(gòu)可以實(shí)現(xiàn)各式廣泛的視頻產(chǎn)品的設(shè)計(jì)。利用這種開(kāi)源結(jié)構(gòu),能為視頻設(shè)備設(shè)計(jì)人員提供社群支持、穩(wěn)健的基礎(chǔ)架構(gòu),從而縮短上市時(shí)間。
評(píng)論