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

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

　　很多時候，由于攝像機和編碼器的性能限制該方案無法實施。因此，該解決方案是專門設(shè)計用于低延編碼器。而最新A2e Technologies低延時編碼器只有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)時延。

　　圖3  完整編/解碼系統(tǒng)方框圖

　　而就整個軟件路徑而言，要減少時延，就需要將RTSP服務(wù)器和壓縮信息轉(zhuǎn)發(fā)任務(wù)分離，從而用Linux驅(qū)動程序替代RTSP服務(wù)器執(zhí)行發(fā)送任務(wù)。

　　為了降低時延，我們對A2e Technologies低時延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.264 IP的完整編/解碼系統(tǒng)，總時延不足50毫秒。該系統(tǒng)是根據(jù)Zynq SoC、A2e Technologies低時延H.264編/解碼器與A2e Technologies 低時延RTSP服務(wù)器/客戶端而建立的。需要注意的是，從硬件角度來看，編碼與解碼系統(tǒng)之間唯一真正的區(qū)別在于，編碼側(cè)必須連接到攝像頭/傳感器，而解碼側(cè)則必須能夠為平板顯示提供驅(qū)動。您可以輕松地設(shè)計一個具備編碼與解碼所需的所有必備硬件功能的電路板。

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