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

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

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

　　延時最小低化時延

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

　　然而，也可采取措施盡量減少內核與用戶空間之間的拷貝操作，從而減少相關時延。

　　圖3  完整編/解碼系統方框圖

　　而就整個軟件路徑而言，要減少時延，就需要將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板上創建一個時延極低、高度可配置的系統。