微型H.264核結合賽靈思Zynq SoC在小型快速的視頻流處理系統的應用。

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

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

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

基于SOC-FPGA的系統

基于Zynq SoC的產品比采用特定應用標準產品（ASSP）構建的產品靈活性更高。例如，通過在FPGA架構中內置4個H.264核，并將每個攝像頭輸入端連接到FPGA，就可以很容易構建一個支持1080p30輸入的系統。許多ASSP產品只有兩個輸入端，這讓設計人員不得不想辦法多路復用若干視頻流到一個輸入端。每個A2e Technologies H.264核能夠處理六個VGA分辨率攝像頭或一個1080p30分辨率攝像頭。因此，有可能構建一個雙核系統，以便對來自12個VGA攝像頭輸入的視頻進行壓縮。

?

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

如何應對延時

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

?填充幀緩沖的延遲

?壓縮時間

?發送數據包引起的軟件延遲

?網絡延遲

?接收數據包引起的軟件延遲

?視頻解碼時間

許多系統采用硬件對視頻進行編碼，但最終卻采用標準的視頻播放器

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

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

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

為使總時延最小化，必須同時最大限度地降低編碼側和解碼側上緩沖、網絡協議棧、RTSP服務器/客戶端等引起的時延，因為軟件路徑會產生很長的時延，而在這種情況下采用低時延編碼器毫無意義。RTSP服務器通常用來在服務器（攝像頭）與客戶端（解碼/記錄）設備之間創建流式視頻連接。連接建立后，RTSP服務器會將壓縮的視頻傳送至客戶端以供顯示或存儲。

延時最小低化時延

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

然而，也可采取措施盡量減少內核與用戶空間之間的拷貝操作，從而減少相關時延。而就整個軟件路徑而言，要減少時延，就需要將RTSP服務器和壓縮信息轉發任務分離，從而用Linux驅動程序替代RTSP服務器執行發送任務。

為了降低時延，我們對A2e Technologies低時延RTSP服務器進行了兩處修改。首先，移除轉發路徑上的RTSP服務器。RTSP服務器仍采用實時控制協議（RTCP）維護統計數據，并隨網絡目標地址（即IP或MAC目的地地址）的變動定期（或異步）更新內核驅動。第二，內核驅動程序附加必要數據頭（基于RTSP服務器提供的信息），通過直接輸入網絡驅動程序（例如udp_send）立即轉發數據包，從而無需在內核和用戶空間之間進行內存拷貝。

圖3 顯示了基于H.264 IP的完整編/解碼系統，總時延不足50毫秒。該系統是根據Zynq SoC、A2e Technologies低時延H.264編/解碼器與A2e Technologies 低時延RTSP服務器/客戶端而建立的。需要注意的是，從硬件角度來看，編碼與解碼系統之間唯一真正的區別在于，編碼側必須連接到攝像頭/傳感器，而解碼側則必須能夠為平板顯示提供驅動。您可以輕松地設計一個具備編碼與解碼所需的所有必備硬件功能的電路板。

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