基于Zynq SoC的視頻流處理系統(tǒng)的應(yīng)用

基于ZynqSoC的視頻流處理系統(tǒng)的應(yīng)用微型H.264核結(jié)合賽靈思ZynqSoC在小型快速的視頻流處理系統(tǒng)的應(yīng)用。ASSP架構(gòu)不靈活，而基于FPGA和微處理器組合的系統(tǒng)雖然尺寸大但較為靈活，一直以來設(shè)計人員為創(chuàng)建PCB占位面積小的基于IP的流式視頻系統(tǒng)，除了在這兩者之間反復(fù)權(quán)衡外別無他選。將軟核微處理器集成到FPGA,就無需單獨的處理器和DRAM，但最終系統(tǒng)的性能可能無法與以外部ARM?處理器為核心且可能還包括USB、以太網(wǎng)及其它有用外設(shè)構(gòu)建的解決方案所提供的性能相媲美。隨著賽靈思Zynq?-7000AllProgrammableSoC和小型H.264核的問世，現(xiàn)在僅用一組DRAM就可在超小型PCB板上構(gòu)建出一個具有用多條高速AXI4總線連接起來的ARM雙核和高速外設(shè)所實現(xiàn)的高性能的系統(tǒng)（見圖1）。雖然針對FPGA的H.264核問世已有相當長的一段時間，但至今仍沒有一款H.264核夠快夠小，能夠達到足以轉(zhuǎn)換1080p30幀視頻的水平，而且仍舊適用于小型低成本器件。將A2eTechnologies公司的最新微型H.264核與ZynqSoC結(jié)合使用，可構(gòu)建一種低時延系統(tǒng)，該系統(tǒng)能夠以15-60fps的不同幀速率對720p-4K之間的多種視頻流進行編/解碼。將A2eTechnologiesH.264核集成到ZynqSoC器件中，可大幅縮減板級空間并明顯減少組件數(shù)，同時在ZynqSoC集成ARM雙核還可避免使用單獨的微處理器及其必須連接的存儲體。這樣可以構(gòu)建出一個以Linux驅(qū)動程序和實時流協(xié)議（RTSP）服務(wù)器為核心的完整流式視頻系統(tǒng)，該系統(tǒng)能夠?qū)碜詢蓚€攝像頭的1080p30幀視頻進行壓縮，且端到端時延約為10毫秒。A2eTechnologiesH.264核提供純編碼版和編/解碼版兩個版本。此外，還有一款低時延版本，可將編碼時延降至5毫秒以下。1080p30純編碼版需要10000個查找表（LUT），或者說會占用ZynqZ7020FPGA架構(gòu)25%左右的資源，而編/解碼版則需要11,000個查找表?；赟OC-FPGA的系統(tǒng)基于ZynqSoC的產(chǎn)品比采用特定應(yīng)用標準產(chǎn)品（ASSP）構(gòu)建的產(chǎn)品靈活性更高。例如，通過在FPGA架構(gòu)中內(nèi)置4個H.264核，并將每個攝像頭輸入端連接到FPGA，就可以很容易構(gòu)建一個支持1080p30輸入的系統(tǒng)。許多ASSP產(chǎn)品只有兩個輸入端，這讓設(shè)計人員不得不想辦法多路復(fù)用若干視頻流到一個輸入端。每個A2eTechnologiesH.264核能夠處理六個VGA分辨率攝像頭或一個1080p30分辨率攝像頭。因此，有可能構(gòu)建一個雙核系統(tǒng)，以便對來自12個VGA攝像頭輸入的視頻進行壓縮。

ASSP產(chǎn)品通常僅對已解碼視頻提供屏幕視控(OSD)功能，這迫使設(shè)計人員將OSD信息作為元數(shù)據(jù)發(fā)送或使用ARM內(nèi)核測定視頻幀時間并以編程方式將OSD數(shù)據(jù)寫入視頻緩沖區(qū)。在FPGA中，在進行視頻壓縮前添加OSD如同訪問IP模塊一樣簡單。同時在壓縮引擎前添加魚眼鏡頭校正等其它處理模塊，也相對容易。此外，F(xiàn)PGA還支持功能的現(xiàn)場與未來升級，例如添加H.265壓縮功能。圖2是帶有兩個1080p30攝像頭輸入的H.264壓縮引擎方框圖，其中OSD適用于未壓縮圖像。如何應(yīng)對延時某些應(yīng)用程序，如遙控飛行器（RPV）的控制，是基于遙控裝置發(fā)回的流媒體圖像反饋。為了控制遙控裝置，從傳感器發(fā)送視頻至壓縮引擎到解碼圖像顯示（稱為“玻璃對玻璃”）之間的時延通常要小于100毫秒。一些設(shè)計人員將時延規(guī)定在50毫秒內(nèi)。總時延是如下幾項的和：

?視頻處理時間（ISP、魚眼鏡頭校正等）?填充幀緩沖的延遲?壓縮時間?發(fā)送數(shù)據(jù)包引起的軟件延遲?網(wǎng)絡(luò)延遲?接收數(shù)據(jù)包引起的軟件延遲?視頻解碼時間許多系統(tǒng)采用硬件對視頻進行編碼，但最終卻采用標準的視頻播放器進行解碼，如在PC上運行的VLC。即使媒體播放器的緩沖延遲可從一般的500-1000毫秒大幅減少，但時延仍然遠遠超過50毫秒。要真正控制時延并保持在絕對最低水平，就需要對已壓縮視頻流進行硬件解碼，而且要求緩沖最小。

H.264編碼器時延通常以幀來表示，如一般在壓縮開始前必須緩沖一個完整幀的時間。假設(shè)編碼器速度可以提高，那么僅通過幀速率加倍即可降低編碼時延，也就是說，幀速率為30fps時每幀時延為33毫秒，而幀速率為60fps時每幀時延則為16.5毫秒。一種典型的流式視頻系統(tǒng)采用RTSP服務(wù)器在攝像頭與客戶端（解碼/記錄）設(shè)備之間創(chuàng)建流式視頻連接。RTSP服務(wù)器將已壓縮的視頻傳送至客戶端以供顯示或存儲。很多時候，由于攝像機和編碼器的性能限制該方案無法實施。因此，該解決方案是專門設(shè)計用于低延編碼器。而最新A2eTechnologies低延時編碼器只有16個視頻線才需要在壓縮開始前進行緩沖。對于1080p30視頻流而言，時延不足500微秒（μs）。而對于480p30視頻流而言，時延則低于1毫秒。設(shè)計人員采用這種低時延編碼器可構(gòu)建出時延可預(yù)測且很低的系統(tǒng)。為使總時延最小化，必須同時最大限度地降低編碼側(cè)和解碼側(cè)上緩沖、網(wǎng)絡(luò)協(xié)議棧、RTSP服務(wù)器/客戶端等引起的時延，因為軟件路徑會產(chǎn)生很長的時延，而在這種情況下采用低時延編碼器毫無意義。RTSP服務(wù)器通常用來在服務(wù)器（攝像頭）與客戶端（解碼/記錄）設(shè)備之間創(chuàng)建流式視頻連接。連接建立后，RTSP服務(wù)器會將壓縮的視頻傳送至客戶端以供顯示或存儲。延時最小低化時延通常情況下，服務(wù)器和客戶端的軟件組件只要求與帶寬匹配，方便傳送壓縮視頻，而不是為了最小化時延。而如Linux之類的非實時操作系統(tǒng)則很難保證時延。典型的解決方案就是為服務(wù)器和客戶端創(chuàng)建低時延自定義協(xié)議。但這種方法的不足之處就是不符合行業(yè)標準。另一種方法是采用一種類似RTSP的標準，通過對軟件的低層進行修改來最小化時延，同時保證符合各項標準。然而，也可采取措施盡量減少內(nèi)核與用戶空間之間的拷貝操作，從而減少相關(guān)時延。而就整個軟件路徑而言，要減少時延，就需要將RTSP服務(wù)器和壓縮信息轉(zhuǎn)發(fā)任務(wù)分離，從而用Linux驅(qū)動程序替代RTSP服務(wù)器執(zhí)行發(fā)送任務(wù)。為了降低時延，我們對A2eTechnologies低時延RTSP服務(wù)器進行了兩處修改。首先，移除轉(zhuǎn)發(fā)路徑上的RTSP服務(wù)器。RTSP服務(wù)器仍采用實時控制協(xié)議（RTCP）維護統(tǒng)計數(shù)據(jù)，并隨網(wǎng)絡(luò)目標地址（即IP或MAC目的地地址）的變動定期（或異步）更新內(nèi)核驅(qū)動。第二，內(nèi)核驅(qū)動程序附加必要數(shù)據(jù)頭（基于RTSP服務(wù)器提供的信息），通過直接輸入網(wǎng)絡(luò)驅(qū)動程序（例如udp_send）立即轉(zhuǎn)發(fā)數(shù)據(jù)包，從而無需在內(nèi)核和用戶空間之間進行內(nèi)存拷貝。圖3顯示了基于H.264IP的完整編/解碼系統(tǒng)，總時延不足50毫秒。該系統(tǒng)是根據(jù)ZynqSoC、A2eTechnologies低時延H.264編/解碼器與A2eTechnologies低時延RTSP服務(wù)器/客戶端而建立的。需要注意的是，從硬件角度來看，編碼與解碼系統(tǒng)之間唯一真正的區(qū)別在于，編碼側(cè)必須連接到攝像頭/傳感器，而解碼側(cè)則必須能夠為平板顯示提供驅(qū)動。您可以輕松地設(shè)計