用Zynq SoC 設(shè)計低時延H.264系統(tǒng)

　　小型快速的流式視頻系統(tǒng)結(jié)合采用微型H.264核和賽靈思Zynq SoC。

        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?-7000 All Programmable SoC 和小型H.264核的問世，現(xiàn)在僅用一組DRAM就可在超小型PCB板上構(gòu)建出一個具有用多條高速AXI4總線連接起來的ARM雙核和高速外設(shè)所實現(xiàn)的高性能的系統(tǒng)(見圖1)。

　　雖然針對FPGA的H.264核問世已有相當(dāng)長的一段時間，但至今仍沒有一款H.264核夠快夠小，能夠達(dá)到足以轉(zhuǎn)換1080p30幀視頻的水平，而且仍舊適用于小型低成本器件。將A2e Technologies公司的最新微型H.264核與Zynq SoC結(jié)合使用，可構(gòu)建一種低時延系統(tǒng)，該系統(tǒng)能夠以15-60fps的不同幀速率對720p-4K之間的多種視頻流進(jìn)行編/解碼。將A2e Technologies H.264核集成到Zynq SoC器件中，可大幅縮減板級空間并明顯減少組件數(shù)，同時在Zynq SoC集成ARM雙核還可避免使用單獨的微處理器及其必須連接的存儲體。

　　圖1 - 基于單芯片 Zynq SoC的視頻壓縮系統(tǒng) (上)與基于雙芯片處理器和FPGA的視頻壓縮系統(tǒng)對比

　　這樣可以構(gòu)建出一個以Linux驅(qū)動程序和實時流協(xié)議(RTSP)服務(wù)器為核心的完整流式視頻系統(tǒng)，該系統(tǒng)能夠?qū)碜詢蓚€攝像頭的1080p30幀視頻進(jìn)行壓縮，且端到端時延約為10毫秒。A2e Technologies H.264核提供純編碼版和編/解碼版兩個版本。此外，還有一款低時延版本，可將編碼時延降至5毫秒以下。1080p30純編碼版需要10000個查找表(LUT)，或者說會占用Zynq Z7020 FPGA架構(gòu)25%左右的資源，而編/解碼版則需要11,000個查找表。

　　基于SOC-FPGA的系統(tǒng)

　　基于Zynq SoC的產(chǎn)品比采用特定應(yīng)用標(biāo)準(zhǔn)產(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ù)用若干視頻流到一個輸入端。每個A2e Technologies H.264核能夠處理六個VGA分辨率攝像頭或一個1080p30分辨率攝像頭。因此，有可能構(gòu)建一個雙核系統(tǒng)，以便對來自12個VGA攝像頭輸入的視頻進(jìn)行壓縮。

　　ASSP產(chǎn)品通常僅對已解碼視頻提供屏幕視控(OSD)功能，這迫使設(shè)計人員將OSD信息作為元數(shù)據(jù)發(fā)送或使用ARM內(nèi)核測定視頻幀時間并以編程方式將OSD數(shù)據(jù)寫入視頻緩沖區(qū)。在FPGA中，在進(jìn)行視頻壓縮前添加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)?？倳r延是如下幾項的和：

　　視頻處理時間(ISP、魚眼鏡頭校正等)

　　?填充幀緩沖的延遲

　　?壓縮時間

　　?發(fā)送數(shù)據(jù)包引起的軟件延遲

　　?網(wǎng)絡(luò)延遲

　　?接收數(shù)據(jù)包引起的軟件延遲

　　?視頻解碼時間

　　許多系統(tǒng)采用硬件對視頻進(jìn)行編碼，但最終卻采用標(biāo)準(zhǔn)的視頻播放器進(jìn)行解碼，如在PC上運(yùn)行的VLC。即使媒體播放器的緩沖延遲可從一般的500-1000毫秒大幅減少，但時延仍然遠(yuǎn)遠(yuǎn)超過50毫秒。要真正控制時延并保持在絕對最低水平，就需要對已壓縮視頻流進(jìn)行硬件解碼，而且要求緩沖最小。

　　H.264編碼器時延通常以幀來表示，如一般在壓縮開始前必須緩沖一個完整幀的時間。假設(shè)編碼器速度可以提高，那么僅通過幀速率加倍即可降低編碼時延，也就是說，幀速率為30fps時每幀時延為33毫秒，而幀速率為60fps時每幀時延則為16.5毫秒。