關鍵詞： API , dsp , 視頻處理

數(shù)字信號處理器(DSP)具有出色的多媒體性能。一般而言，它們運行編解碼器所需的周期只有通用處理器(GPP)內(nèi)核的40%到50%。DSP還能提供比ASIC大得多的靈活性和可重配置性。但迄今為止，要在數(shù)字視頻應用中運用DSP，編程人員還不得不花費較多時間精力去學習相關專用語言。不過，隨著應用編程接口(API)的出現(xiàn)，已不再需要學習這些專用DSP語言了。在運行于GPP上的應用中，API可以輕輕松松地充分發(fā)揮DSP的優(yōu)勢。

開源多媒體構(gòu)架在GPP上一般運行在Linux操作系統(tǒng)下，是這些API的理想對象。利用API可以卸載視頻編解碼器的計算負荷，大大減小DSP編程的復雜性。這種方案只要求編程人員具備基本的DSP知識即可，無需編寫代碼來整合DSP功能與那些運行在GPP上的功能。這種優(yōu)勢，加上利用免費開源插件和構(gòu)架提供的許多功能的能力，可以大幅度縮短新視頻產(chǎn)品的上市時間。

硬件平臺的選擇

在選擇運行編解碼器(壓縮傳輸或存儲的數(shù)字流，再解壓以供查看或編輯)的硬件平臺時，開發(fā)人員有幾種可選方案。ASIC是專門為數(shù)字視頻應用而設計的，能在這類應用中提供高性能和低功耗。它的缺點流片(NRE)費用很高。此外，ASIC若有變化，比如改動以適應編解碼標準，相關實現(xiàn)費用非常高昂。

另一方面，GPP內(nèi)核的流片費用相對較低，針對變動進行重編程相當容易。但由于它們在執(zhí)行計算密集的信號處理應用時效率低下，故在應用于數(shù)字視頻處理時性能較低。例如，GPP通過一系列移位和加法運算來實現(xiàn)乘法運算，而每一個移位和加法運算需要一個以上的時鐘周期。

DSP具有集上述二者之優(yōu)勢的潛力。不同于GPP，DSP是為數(shù)字視頻應用中計算密集的信號處理應用而優(yōu)化的。它具有單周期乘法器或乘法累加單元，能夠加快編解碼算法的執(zhí)行速度。更高性能的DSP還包含有幾個可以并行操作的獨立執(zhí)行單元，這使得它們能夠每條指令執(zhí)行好幾個操作。此外，DSP還提供完全的軟件編程能力，包括現(xiàn)場重編程能力。這就讓用戶可以先推出MPEG-2產(chǎn)品，以后再升級為H.264視頻編解碼器。DSP在數(shù)字視頻應用中的主要局限是它們通常需要采用專用語言來編程，而熟悉DSP的編程人員遠沒有熟悉流行的GPP架構(gòu)的來得多。

圖1：只含解碼器的范例中的多媒體框架職責和數(shù)據(jù)流程

組件集成的挑戰(zhàn)

數(shù)字視頻系統(tǒng)的開發(fā)人員還面臨著集成的挑戰(zhàn)。數(shù)字視頻系統(tǒng)包含了多個編碼器、解碼器、編解碼器、多種算法及其它軟件，這些組件都必須集成到一個可執(zhí)行映象(image)中，然后才能在系統(tǒng)上運行內(nèi)容。集成所有這些組件并確保其運行協(xié)調(diào)是一件很困難的任務。不同的系統(tǒng)可能需要截然不同的視頻、圖像、語音、音頻和其他多媒體模塊。手工集成每一個軟件模塊或算法的開發(fā)人員就被增值功能性(比如增加創(chuàng)新性功能)搞得頭痛不已。

許多數(shù)字視頻開發(fā)人員都開始采取開源途徑來構(gòu)建軟件。一種常用的方案是從開源獲得軟件的重要部分，而在可用性和硬件集成方面充分發(fā)揮內(nèi)部專業(yè)能力。開發(fā)人員常常參與開源技術(shù)開發(fā)項目，以滿足特定要求并把內(nèi)部開發(fā)的代碼和開源代碼集成在一起來創(chuàng)建新產(chǎn)品。

新的API

為了解決上述問題，德州儀器(TI)開發(fā)出了一款API，該產(chǎn)品能夠充分發(fā)揮開源多媒體框架中的GStreamer等DSP的優(yōu)勢。這款API使多媒體編程人員可以利用熟悉環(huán)境中的DSP編解碼引擎，把數(shù)字視頻編程人員從復雜的DSP編程中解放出來，讓ARM/Linux開發(fā)人員得以輕松利用DSP編解碼器的加速功能，無需具備相關硬件知識。該接口還能自動高效地在ARM和DSP間進行工作劃分，從而不再需要為運行在DSP上和運行在GPP內(nèi)核上的功能間的協(xié)調(diào)而編寫代碼。該接口已由TI按照開源社群標準以GStreamer插件的形式開發(fā)成功。

圖2：GStreamer內(nèi)數(shù)據(jù)通過GstBuffer結(jié)構(gòu)進行表征的方法與其它幾種操作系統(tǒng)及其相應多媒體框架所采取的方法相一致。

GStreamer是一種媒體處理庫，提供了某種轉(zhuǎn)換過程的抽象模型，其通過管道的概念進行工作，媒體在其中按照已定義的方向從輸入流到輸出。GStreamer能夠以一種簡化編程過程的方式來提取不同媒體的操作行為，在數(shù)字視頻編程社群中廣受歡迎。通過GStreamer，能夠編寫出一種能夠支持多種不同格式和網(wǎng)絡的通用視頻或音樂播放器。而且大部分操作由插件執(zhí)行，并非GStreamer內(nèi)核。GStreamer的基本功能性主要與注冊和加載插件有關，并可提供基類，這些基類定義了GStreamer類的基本功能。

GStreamer過濾器

源過濾器負責從從數(shù)據(jù)源獲取原始的多媒體數(shù)據(jù)以供處理，這里的數(shù)據(jù)源可以是硬盤文件(比如文件源過濾器)，或CD或DVD光盤，也可以是電視接收卡或網(wǎng)絡這種“實時”源。某些源過濾器只是簡單地把原始數(shù)據(jù)傳遞到剖析器(parser)或分離過濾器(splitter filter)，同時其它源過濾器也執(zhí)行自己的剖析步驟。變換過濾器 (Transform filter)接收原始數(shù)據(jù)或部分經(jīng)過處理的數(shù)據(jù)，進一步處理后再傳遞到下一級過濾器。

變換過濾器有多種類型，剖析器即是一例。這種過濾器把原始字節(jié)流分離為多個樣本或幀、壓縮器或解壓縮器，以及格式轉(zhuǎn)換器。呈現(xiàn)過濾器(Renderer filter)一般接收完全處理過的數(shù)據(jù)，并在系統(tǒng)顯示器上或通過揚聲器或某些外部設備進行播放。這一類過濾器還包括“file writer (文件創(chuàng)建器)”過濾器和網(wǎng)絡傳輸過濾器，前者可以把數(shù)據(jù)保存到硬盤或其它持久穩(wěn)固的存儲設備上。

數(shù)據(jù)處理在plug-in_chain() 或 plug-in_loop()函數(shù)中進行。該函數(shù)可能像元件縮放那么簡單，也可能像真實的MP3解碼器那么復雜。數(shù)據(jù)被處理后，利用一個gst_pad_push()函數(shù)從GStreamer元件(element)的源襯墊(pad)發(fā)送出去，由此把數(shù)據(jù)傳遞到管道鏈的下一個元件。

GStreamer緩沖器

在GStreamer中，緩沖器是數(shù)據(jù)傳輸?shù)幕締卧stBuffer(實例)類提供了把一個存儲區(qū)定義為流媒體的一部分所必需的全部狀態(tài)。經(jīng)由GstBuffer結(jié)構(gòu)，Gstreame內(nèi)部的數(shù)據(jù)表示遵循幾種其它操作系統(tǒng)及其各自的多媒體構(gòu)架所采用的方法(比如，Microsoft DirectShow中的媒體采樣概念)。此外，還支持次級緩沖器，允許緩沖器的一小部分成為它自己的緩沖器，利用這種處理機制確保了存儲空間不會過早釋放。

圖3：復用已分配在驅(qū)動器上且在物理上是連續(xù)的緩沖的一種有效途徑。

緩沖器通常利用gst_buffer_new()來創(chuàng)建。創(chuàng)建好一個緩沖器之后，一般是為它分配存儲器，設置緩沖器數(shù)據(jù)的大小。下面給出了一個緩沖器創(chuàng)建的例子，該緩沖器能夠保存具有給定寬度、高度和每像素位的視頻幀。

緩沖器創(chuàng)建

基于DaVinci技術(shù)的DM644x器件上ARM926的MMU(存儲器管理單元)具有虛擬/物理尋址能力。然而，C64x+DSP內(nèi)核只能夠處理物理地址。因此，用于DSP處理的輸入和輸出緩沖器必須駐存在物理上連續(xù)的存儲器中。

虛擬到物理地址的轉(zhuǎn)換由編解碼引擎處理。通過復用(指針指向)某些由驅(qū)動器分配的緩沖器，可獲得物理上連續(xù)的存儲器，這里使用了Linux中的一些技術(shù)，比如dma_alloc_coherent()，來在內(nèi)核空間中分配這類存儲器。由TI開發(fā)的庫/內(nèi)核模塊CMEM，允許從用戶空間應用來分配物理上連續(xù)的存儲器。

例如，我們利用前面提到的CMEM驅(qū)動器來分配物理上連續(xù)的“輸出”緩沖器。編解碼引擎對幀進行解碼，并把解碼后的幀放在輸出緩沖器中。

接下來，指向輸出緩沖器的指針被傳遞給fbvideosink(通過 GstBuffer)。這個videosink必須把解碼后的數(shù)據(jù)memcpy(復制)到幀緩存中，然后才能顯示。由于memcpy操作是一種成本很高的GPP使用，這種方法使得ARM 和DDR接口的負載很重，因而增加了功耗，且效率極低。

這種技術(shù)對非常小的緩沖器是可行的，但在開發(fā)人員使用D1(和更高)大小的緩沖器時，將開始降低系統(tǒng)性能。一種更有效的方案是復用已經(jīng)驅(qū)動器分配了的物理連續(xù)緩沖器，并在編解碼器引擎和videosink插件之間把指向這些緩沖器的指針來回傳遞。幸運的是，GStreamer提供了一個便于這類交互作用的API。

這個API替代方案利用gst_buffer_new()來創(chuàng)建新的緩沖器。當元件獲知它將在哪一個源襯墊上推動數(shù)據(jù)時，就對gst_pad_alloc_buffer()函數(shù)進行調(diào)用。這允許對應的元件為調(diào)用元件的工作提供特殊的“硬件”緩沖器，故而減少了系統(tǒng)所需的memcpys數(shù)量。

視頻解碼器插件(變換過濾器，通過編解碼器引擎API能夠充分利用DSP的優(yōu)勢)將把從視頻呈現(xiàn)過濾器獲得的緩沖器用作視頻解碼器和執(zhí)行解碼的輸出緩沖器。一旦解碼完成，這個輸出緩沖器將被推動(即指針被傳遞)給視頻呈現(xiàn)過濾器插件。由于解碼后的圖像已經(jīng)存在于視頻驅(qū)動存儲器中，就不再需要memcpy了，在幀被顯示時，視頻呈現(xiàn)過濾器將只需把目前的顯示緩沖器轉(zhuǎn)換為這種特定的緩沖器就可以了。

AV同步處理

播放期間的音頻/視頻(AV)同步處理一般需要三類決策：一是重復幀的決策。一般在媒體流的幀的顯示時間比幀間隔時間更大時采用。二是顯示幀的決策。一般在媒體流的幀的顯示時間在最小和最大閾值之間時采用。三是跳幀決策。一般在幀的顯示時間落后顯示時間至少兩個幀時采用。這樣，跳過當前幀，處理下一個幀，以期彌補下一個幀間隔。持續(xù)這樣做直到下一個幀被顯示或不再剩有幀可供比較。

另外，管道中的所有元件都使用共同的時鐘，以便于這些活動的進行。幸運的是，所有這些決策都由GStreamer內(nèi)核庫中的音頻視頻sink基類來完成。這樣一來，AV同步的復雜性大部分都在用戶那里被轉(zhuǎn)移了。

以插件形式開發(fā)的接口

TI開發(fā)了一種GStreamer變換過濾器插件，它利用DSP來進行視頻解碼，運行于ARM上，使用Linux操作系統(tǒng)。TI還提供有Linux外設驅(qū)動器，在驅(qū)動器接口和編解碼引擎API方面符合標準開源機構(gòu)的要求，后者注意了DSP編程的相當大部分的復雜性。由硬件制造商提供的API，事先已針對硬件實現(xiàn)做了優(yōu)化。如果改用新的硬件，無需改變應用代碼就可直接替以新的驅(qū)動器。這種方案大幅度降低了視頻開發(fā)的成本和交付周期。

硬件的計算資源以一種最優(yōu)方式被執(zhí)行，無需任何匯編編程。其中包括很多復雜的操作，比如DSP資源的最佳利用，和基于硬件的加速引擎；鏈接模式(chained mode)下增強型直接存儲器訪問(Enhanced Direct Memory Access)外設的使用，以提高數(shù)據(jù)傳輸效率；以及中斷模式和tasklet模式的數(shù)據(jù)包處理，以靈活滿足不同應用的要求。

由于GStreamer是一種非常流行、廣為人知的架構(gòu)，它已成為數(shù)字視頻開發(fā)的一種標準，在這種環(huán)境中充分利用 DSP優(yōu)勢的能力使得編程人員不再需要學習專用DSP編程語言。

該方案還易于把DSP的功能和GPP內(nèi)核上運行的典型應用的一些其他要求集成在一起。利用其他GStreamer插件，可以把解碼編碼與數(shù)字視頻應用所需的其他操作相結(jié)合。這種多媒體架構(gòu)通過把各種本來需要手工編碼的操作整合在一起來實現(xiàn)集成。

總而言之，這一新接口能夠利用GStreamer Linux多媒體構(gòu)架來充分發(fā)揮TI的DaVinci處理器平臺的軟件基礎架構(gòu)的優(yōu)勢。這種整合型的基礎架構(gòu)提供了靈活的構(gòu)架，能夠適應新一代多媒體編解碼器的要求。

該軟件架構(gòu)可以實現(xiàn)各式廣泛的視頻產(chǎn)品的設計。利用這種開源結(jié)構(gòu)，能為視頻設備設計人員提供社群支持、穩(wěn)健的基礎架構(gòu)，從而縮短上市時間。