微型H.264核結(jié)合賽靈思Zynq SoC在小型快速的視頻流處理系統(tǒng)的應(yīng)用。

ASSP架構(gòu)不靈活，而基于FPGA和微處理器組合的系統(tǒng)雖然尺寸大但較為靈活，一直以來設(shè)計(jì)人員為創(chuàng)建PCB占位面積小的基于IP的流式視頻系統(tǒng)，除了在這兩者之間反復(fù)權(quán)衡外別無他選。將軟核微處理器集成到FPGA,就無需單獨(dú)的處理器和DRAM，但最終系統(tǒng)的性能可能無法與以外部ARM?處理器為核心且可能還包括USB、以太網(wǎng)及其它有用外設(shè)構(gòu)建的解決方案所提供的性能相媲美。隨著賽靈思Zynq?-7000 All Programmable SoC 和小型H.264核的問世，現(xiàn)在僅用一組DRAM就可在超小型PCB板上構(gòu)建出一個(gè)具有用多條高速AXI4總線連接起來的ARM雙核和高速外設(shè)所實(shí)現(xiàn)的高性能的系統(tǒng)（見圖1）。

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

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

基于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個(gè)H.264核，并將每個(gè)攝像頭輸入端連接到FPGA，就可以很容易構(gòu)建一個(gè)支持1080p30輸入的系統(tǒng)。許多ASSP產(chǎn)品只有兩個(gè)輸入端，這讓設(shè)計(jì)人員不得不想辦法多路復(fù)用若干視頻流到一個(gè)輸入端。每個(gè)A2e Technologies H.264核能夠處理六個(gè)VGA分辨率攝像頭或一個(gè)1080p30分辨率攝像頭。因此，有可能構(gòu)建一個(gè)雙核系統(tǒng)，以便對(duì)來自12個(gè)VGA攝像頭輸入的視頻進(jìn)行壓縮。

?

ASSP產(chǎn)品通常僅對(duì)已解碼視頻提供屏幕視控(OSD)功能，這迫使設(shè)計(jì)人員將OSD信息作為元數(shù)據(jù)發(fā)送或使用ARM內(nèi)核測(cè)定視頻幀時(shí)間并以編程方式將OSD數(shù)據(jù)寫入視頻緩沖區(qū)。在FPGA中，在進(jìn)行視頻壓縮前添加OSD如同訪問IP模塊一樣簡(jiǎn)單。同時(shí)在壓縮引擎前添加魚眼鏡頭校正等其它處理模塊，也相對(duì)容易。此外，F(xiàn)PGA還支持功能的現(xiàn)場(chǎng)與未來升級(jí)，例如添加H.265 壓縮功能。圖2是帶有兩個(gè)1080p30攝像頭輸入的H.264壓縮引擎方框圖，其中OSD適用于未壓縮圖像。

如何應(yīng)對(duì)延時(shí)

某些應(yīng)用程序，如遙控飛行器（RPV）的控制，是基于遙控裝置發(fā)回的流媒體圖像反饋。為了控制遙控裝置，從傳感器發(fā)送視頻至壓縮引擎到解碼圖像顯示（稱為“玻璃對(duì)玻璃”）之間的時(shí)延通常要小于100毫秒。一些設(shè)計(jì)人員將時(shí)延規(guī)定在50毫秒內(nèi)?？倳r(shí)延是如下幾項(xiàng)的和：
? 視頻處理時(shí)間（ISP、魚眼鏡頭校正等）

?填充幀緩沖的延遲

?壓縮時(shí)間

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

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

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

?視頻解碼時(shí)間

許多系統(tǒng)采用硬件對(duì)視頻進(jìn)行編碼，但最終卻采用標(biāo)準(zhǔn)的視頻播放器

進(jìn)行解碼，如在PC上運(yùn)行的VLC。即使媒體播放器的緩沖延遲可從一般的500-1000毫秒大幅減少，但時(shí)延仍然遠(yuǎn)遠(yuǎn)超過50毫秒。要真正控制時(shí)延并保持在絕對(duì)最低水平，就需要對(duì)已壓縮視頻流進(jìn)行硬件解碼，而且要求緩沖最小。
H.264編碼器時(shí)延通常以幀來表示，如一般在壓縮開始前必須緩沖一個(gè)完整幀的時(shí)間。假設(shè)編碼器速度可以提高，那么僅通過幀速率加倍即可降低編碼時(shí)延，也就是說，幀速率為30fps時(shí)每幀時(shí)延為33毫秒，而幀速率為60fps時(shí)每幀時(shí)延則為16.5毫秒。

一種典型的流式視頻系統(tǒng)采用RTSP服務(wù)器在攝像頭與客戶端（解碼/記錄）設(shè)備之間創(chuàng)建流式視頻連接。RTSP服務(wù)器將已壓縮的視頻傳送至客戶端以供顯示或存儲(chǔ)。

很多時(shí)候，由于攝像機(jī)和編碼器的性能限制該方案無法實(shí)施。因此，該解決方案是專門設(shè)計(jì)用于低延編碼器。而最新A2e Technologies低延時(shí)編碼器只有16個(gè)視頻線才需要在壓縮開始前進(jìn)行緩沖。對(duì)于1080p30視頻流而言，時(shí)延不足500微秒（μs）。而對(duì)于480p30視頻流而言，時(shí)延則低于1毫秒。設(shè)計(jì)人員采用這種低時(shí)延編碼器可構(gòu)建出時(shí)延可預(yù)測(cè)且很低的系統(tǒng)。

為使總時(shí)延最小化，必須同時(shí)最大限度地降低編碼側(cè)和解碼側(cè)上緩沖、網(wǎng)絡(luò)協(xié)議棧、RTSP服務(wù)器/客戶端等引起的時(shí)延，因?yàn)檐浖窂綍?huì)產(chǎn)生很長(zhǎng)的時(shí)延，而在這種情況下采用低時(shí)延編碼器毫無意義。RTSP服務(wù)器通常用來在服務(wù)器（攝像頭）與客戶端（解碼/記錄）設(shè)備之間創(chuàng)建流式視頻連接。連接建立后，RTSP服務(wù)器會(huì)將壓縮的視頻傳送至客戶端以供顯示或存儲(chǔ)。

延時(shí)最小低化時(shí)延

通常情況下，服務(wù)器和客戶端的軟件組件只要求與帶寬匹配，方便傳送壓縮視頻，而不是為了最小化時(shí)延。而如Linux之類的非實(shí)時(shí)操作系統(tǒng)則很難保證時(shí)延。典型的解決方案就是為服務(wù)器和客戶端創(chuàng)建低時(shí)延自定義協(xié)議。但這種方法的不足之處就是不符合行業(yè)標(biāo)準(zhǔn)。另一種方法是采用一種類似RTSP的標(biāo)準(zhǔn)，通過對(duì)軟件的低層進(jìn)行修改來最小化時(shí)延，同時(shí)保證符合各項(xiàng)標(biāo)準(zhǔn)。

然而，也可采取措施盡量減少內(nèi)核與用戶空間之間的拷貝操作，從而減少相關(guān)時(shí)延。而就整個(gè)軟件路徑而言，要減少時(shí)延，就需要將RTSP服務(wù)器和壓縮信息轉(zhuǎn)發(fā)任務(wù)分離，從而用Linux驅(qū)動(dòng)程序替代RTSP服務(wù)器執(zhí)行發(fā)送任務(wù)。

為了降低時(shí)延，我們對(duì)A2e Technologies低時(shí)延RTSP服務(wù)器進(jìn)行了兩處修改。首先，移除轉(zhuǎn)發(fā)路徑上的RTSP服務(wù)器。RTSP服務(wù)器仍采用實(shí)時(shí)控制協(xié)議（RTCP）維護(hù)統(tǒng)計(jì)數(shù)據(jù)，并隨網(wǎng)絡(luò)目標(biāo)地址（即IP或MAC目的地地址）的變動(dòng)定期（或異步）更新內(nèi)核驅(qū)動(dòng)。第二，內(nèi)核驅(qū)動(dòng)程序附加必要數(shù)據(jù)頭（基于RTSP服務(wù)器提供的信息），通過直接輸入網(wǎng)絡(luò)驅(qū)動(dòng)程序（例如udp_send）立即轉(zhuǎn)發(fā)數(shù)據(jù)包，從而無需在內(nèi)核和用戶空間之間進(jìn)行內(nèi)存拷貝。

圖3 顯示了基于H.264 IP的完整編/解碼系統(tǒng)，總時(shí)延不足50毫秒。該系統(tǒng)是根據(jù)Zynq SoC、A2e Technologies低時(shí)延H.264編/解碼器與A2e Technologies 低時(shí)延RTSP服務(wù)器/客戶端而建立的。需要注意的是，從硬件角度來看，編碼與解碼系統(tǒng)之間唯一真正的區(qū)別在于，編碼側(cè)必須連接到攝像頭/傳感器，而解碼側(cè)則必須能夠?yàn)槠桨屣@示提供驅(qū)動(dòng)。您可以輕松地設(shè)計(jì)一個(gè)具備編碼與解碼所需的所有必備硬件功能的電路板。

為盡量減少實(shí)時(shí)控制應(yīng)用中視頻壓縮/解壓縮的時(shí)延，設(shè)計(jì)人員需要特殊編碼器和優(yōu)化的軟件。利用賽靈思的Zynq SoC和 A2e Technologies的H.264低時(shí)延編碼器與以及優(yōu)化的RTSP 服務(wù)器/客戶端，可在小型PCB板上創(chuàng)建一個(gè)時(shí)延極低、高度可配置的系統(tǒng)。.