0 引言

    隨著信息化科技、網絡技術的不斷發展，流媒體技術已變得日趨成熟，在網絡數據傳輸中變得尤為重要，極大地方便了人們與外界的通信，成為了網絡應用的重要發展方向。傳統的傳輸方式是通過網絡將視頻或者音頻下載到本地硬盤上，而且必須等下載完成后才能播放觀看，針對這種缺點，提出了流媒體技術。流媒體技術涉及到視頻的采集、預處理、編碼、解碼、網絡傳輸等多方面,它將經過壓縮編碼后的視頻放到網絡服務器上，使用戶可以直接通過網絡IP來實時觀看視頻，適用于遠程視頻監控、在線直播、實時視頻會議等場合。

    目前，國內外對實時視頻監控都進行了深入研究，并在實際產品中進行應用，其技術方案越來越成熟。目前的主流監控系統，雖然都集成了網絡監控和本地監控功能，但由于受網絡帶寬的限制，每秒鐘只能傳輸有限的數據量，實時性較差，同時絕大多數系統都是在PC上實現，只能滿足單路的視頻傳輸。通過對一些常用的應用層協議（如RTSP、HTTP、SSDPD等）進行統計分析^[1]，本文比較了在服務器高并發條件下這些協議在系統性能和穩定性方面帶來的影響。文獻[2-3]比較了RTSP協議和HTTP協議在網絡監控系統中的性能，分析出RTSP協議在針對幀率和花屏方面的性能有很大幅度的提升，并具有較好的實時性。隨著嵌入式系統的快速發展，如何在嵌入式平臺上實現多路視頻實時監控已成為非常熱門的研究方向。為此，本文設計了一套基于TMS320DM8168嵌入式平臺的RTSP服務器系統，該系統能同時實現16路D1 30 Fps視頻的遠程實時監控并進行本地存儲，解決了常見網絡監控系統在監控畫質和視頻實時性方面的缺陷。經測試，該系統實時性好、可靠性高，具有一定的應用價值。

1 硬件平臺選擇

    本文選用TI公司推出的基于達芬奇架構的TMS320DM8168作為硬件平臺，其總體架構如圖1所示，它具有處理能力強和運算速度快等特點，能同時實現16路D1 30 Fps視頻的采集、編碼以及網絡傳輸，還支持3個60 幀/s的1080P通道，編解碼器時延低于50 ms，滿足本文多路視頻監控的需求。

1.1 TMS320DM8168芯片結構

    TMS320DM8168內部集成了ARM Cortex A8、DSP C674X+、M3 VIDEO、M3 VPSS 4個處理器。Cortex A8處理器作為系統的主控制器，時鐘頻率高達1.2 GHz，負責整個系統的運行、控制外設管理，可運行Linux、Android等操作系統，適合用于多任務多線程的操作。C674X架構的浮點型DSP處理器的最高時鐘頻率為1.0 GHz，主要運行BIOS6實時系統，用于對視頻圖像的處理。在視頻圖像方面，TMS320DM8168內部集成了兩個Cortex M3處理器，其中VPSS Cortex M3處理器主要控制HDVPSS高清視頻處理子系統，用來實現視頻的捕獲、去噪、縮放、顯示等功能。Video Cortex M3處理器主要控制3個HDVICP高清視頻圖像協處理器，用于對視頻圖像進行編解碼，如H.264、MPEG4，還有兩個Video Port輸入和輸出端口，可配置成高清或者標清模式，用于采集或輸出視頻。

1.2 多通道視頻處理框架

    由于TMS320DM8168是一款多核異構的芯片，同時擁有4個核心處理器，如何控制4個核心處理器之間的協同工作成為了一個至關重要問題。對此，本系統采用了一套多處理器軟件編程框架——多通道視頻處理框架(Multi channel framework，MCFW)。MCFW針對視頻的采集、處理和顯示等，為開發者創建了一系列的處理節點(Link)，屏蔽了底層硬件平臺的細節，為上層的應用程序開發提供了豐富的API接口[4]。Link是MCFW軟件框架中最基本的視頻數據流單元，每一個Link都是一個獨立的線程，各Link之間通過指針來實現數據流的相互傳遞，也可以并行執行。對于每一個核心處理器，在它們內部的數據處理都是由Link來實現的，典型的Link有視頻采集Link(Caputre Link)、去噪Link(Nfs Link)、編碼Link(Encoder Link)、解碼Link(Decoder Link)、顯示Link(Display Link)等，開發者可以直接利用MCFW中的Link建立需要的視頻鏈路(chain)，無需去研究每一個link的具體實現過程。

2 RTSP協議分析

    RTSP(Real-Time Streaming Protocol^[5])協議是由Real Networks和Netscape共同提出的一種客戶端到服務器端的多媒體描述協議，它是一個多媒體控制協議，能控制媒體流在IP網絡上的實時傳輸，同時提供視頻和音頻的遠程控制，如快進、后退、暫停/播放等。RTSP在體系結構上位于實時傳輸協議(Real-time Transport Protocol，RTP)和實時傳輸控制協議(Real-time Transport Control Protocol，RTCP)之上，它使用TCP、UDP或RTP完成數據傳輸。其體系結構圖如圖2所示。

    根據RTSP協議的工作原理^[6]，RTSP服務器與客戶端通過會話交互的方式連接。在一次完整的交互過程中，首先，客戶端需要按順序依次向RTSP服務器發送OPTIONS、DESCRIBE、SETUP、PLAY命令請求消息，并從RTSP服務器得到反饋信息。然后，客戶端再對這些信息進行分析并響應。其中，OPTIONS命令目的是得到服務器提供的可用方法，DESCRIBE命令用于得到會話描述信息(SDP)，SETUP命令提醒服務器建立會話并確定傳輸模式，PLAY命令告訴服務器開始在SETUP建立的流上傳輸數據。在播放過程中客戶端還可以發送可選命令對媒體流進行控制，比如快進、后退、暫停/播放等。最后，客戶端可發送TERADOWN命令請求關閉會話。

3 RTSP服務器系統實現

    本文軟件架構的設計均在MCFW框架中實現，按照不同的功能進行劃分，系統主要分為視頻采集、視頻處理、視頻編碼、本地存儲以及RTSP服務器5個部分。

3.1 視頻采集處理和編碼設計

    本文通過MCFW中的Link搭建了一條數據鏈路來實現RTSP服務器前端的視頻采集、預處理以及視頻編碼。該數據鏈路能完成16路D1 30 Fps的視頻采集，通過配置TVP5158視頻解碼芯片的參數，采集的模擬視頻數據經過解碼芯片轉換成YUV格式數字視頻，同時傳遞給TMS320DM8168內部的4個核心處理器分別進行相應處理，包括nfs（去噪）、dei（去隔行）、scalar（縮放）和encoder（編碼）等。視頻編碼采用H.264編碼，H.264是一種高性能的視頻編解碼技術，在具有高壓縮比率的同時還能擁有高質量流暢的圖像，并可以采用4種壓縮方式，分別是BP（基本畫質）、EP（進階畫質）、MP（主流畫質）、HP（高級畫質）。H.264編碼完成后，由ARM Cortex A8處理器完成H.264視頻數據的本地存儲和網絡傳輸，本地存儲直接采用寫文件的形式，存儲在SATA硬盤中，具體的數據鏈路如圖3所示。

3.2 RTSP服務器設計

    RTSP服務器主要實現從TMS320DM8168 Cortex A8端獲取編碼后的H.264碼流并進行RTP封包發送^[7]。當接收到客戶端的連接請求時，RTSP服務器先完成與該客戶端的會話交互，然后把封裝好的RTP包發送給客戶端。根據RTSP協議的實現原理，RTSP服務器端主要由RTSP會話交互線程和碼流獲取線程組成。

3.2.1 RTSP會話交互線程

    RTSP會話交互線程主要負責RTSP服務器的創建、初始化、關閉以及與客戶端之間的消息應答。首先進行套接字創建，建立TCP socket，綁定服務器IP，用來傳送和接收消息，同時進行RTSP端口監聽和會話處理，并完成服務器與客戶端之間的消息交互。RTSP服務器的會話控制通過TCP連接，監聽是否建立在TCP之上，使用RTSP的通用554端口號和listen（）函數進行監聽，當有客戶端發出與RTSP服務器進行連接請求時，服務器能立刻監測到，并與客戶端建立會話。

    會話成功建立后，RTSP服務器會依次接受到客戶端發送的會話命令，其中包含IP地址、端口號以及要獲取的碼流通道等信息，對這些信息進行分析處理后，將該客戶端加入會話列表中，使能RTP發送狀態并繼續監聽，查看是否有其他客戶端的連接請求并作類似處理，這樣便實現了一對多的并發功能。程序流程圖如圖4所示。

3.2.2 碼流獲取線程

    碼流獲取線程主要實現H.264碼流的實時獲取、RTP封包及發送。如圖5所示，由于TMS320DM8168最多能同時支持16路視頻輸入，因此該線程包含了16個子線程，每一個子線程分別對應TMS320DM8168的16路視頻通道號。首先，利用MCFW中的IpcBitsInLink_getFull-VideoBitStreamBufs（）函數從TMS320DM8168 Cortex A8端獲取H.264視頻數據，分析視頻數據的輸入通道號，并送入對應的子線程，按照RTP封包策略進行RTP封包。通過標記正確的時間戳以及序列號等信息封裝成RTP數據包，然后判斷有無客戶端存在，若存在客戶端且RTP發送狀態使能，則利用sendto()函數發送視頻數據，發送完后釋放資源并返回準備接受下一幀數據；若不存在客戶端，則釋放資源后返回繼續獲取碼流進行RTP封包。

    RTSP的數據流發送基于RTP/UDP協議，因此，無論是否有客戶端發出連接請求，數據都會持續發送。按照RTP數據傳輸協議的封包格式^[8]，RTSP服務器接收到H.264視頻數據后，首先過濾出每一幀視頻數據的NAL單元，將其裝入RTP 報文數據負載段進行RTP封包，配置12 B的RTP報文頭，包括版本號、標志位、填充位、時間戳、序列號等信息，然后經傳輸層封裝UDP報頭，在IP層封裝IP報頭，最后發送到網絡上。由于每一個網絡抽象層單元（NALU）包含的數據量不同，其大小也會不一樣，因此，當要傳輸的NALU超過最大傳輸單元MTU（Maximum Transmission Unit）時，為了減少丟包率，需要進行NALU分片，在以太網中默認的MTU為1 500 B。本系統選擇以1 400 B作為最大傳輸單元，如果一幀視頻數據小于1 400 B，一般采用單個NAL單元模式，直接將視頻數據進行RTP封包并發送出去，若大于1 400 B，則需要對視頻數據進行分割，把NALU單元進行分片RTP封包發送。

4 實驗結果及數據分析

    本文設計的RTSP服務器流媒體系統運行在TMS320DM8168嵌入式開發平臺上，RTSP服務器端通過實時監聽網絡上的請求，在與客戶端進行RTSP交互認證后，把視頻數據發送給客戶端，客戶端通過IP地址網絡訪問RTSP服務器，就能實時接收到服務器端發送的視頻數據。這里以4路視頻為例，圖6為利用ffmpeg播放器實時接收RTSP服務器端的4路視頻。

    視頻的延時大小直接體現了服務器端性能的好壞，造成視頻延時的原因主要包括以下幾部分：視頻采集時間、H.264編碼時間、RTP打包時間、網絡傳輸時間以及ffmpeg播放器的解碼時間。本文分別用H.264的4種畫質級別在局域網環境下進行測試，由于ffmpeg播放器的網絡緩存時間會對視頻的延時產生影響，這里我們采用ffmpeg播放器默認的網絡緩存時間，延時情況如表1所示。

    通過數據分析表明，在穩定的網絡環境下，視頻畫質越高和視頻通道數越多，最終的視頻延時就越大。經測試，在采集16路D1 30 Fps視頻和采用H.264高級畫質(HP)編碼的情況下，最大的延時為0.84 s，監控視頻具有較好的實時性，可以實現流暢、清晰的多路遠程視頻監控。

5 結論

    本文設計并實現了一套基于TMS320DM8168嵌入式平臺的RTSP服務器系統。首先以TMS320DM8168為核心實現了16路D1 30 Fps視頻的采集、預處理、H.264編碼以及本地存儲。其次，在遠程視頻監控方面，以RTSP流媒體協議為基礎，設計并實現了RTSP服務器系統。最后，測試結果表明該服務器工作穩定，具有較好的實時性和可靠性。

參考文獻

[1] 李軍，倪宏，陳君，等.一種應用層協議解析加速算法[J].四川大學學報(工程科學版)，2014(4)：014.

[2] CAI X，OUYANG G，ZHANG X.The design of streaming media video terminal based on embedded linux[C].Future Generation Communication and Networking(FGCN)，2014 8th International Conference on IEEE，2014：68-71.

[3] 茅炎菲，黃忠東.基于RTSP協議網絡監控系統的研究與實現[J].計算機工程與設計，2011，32(7)：2523-2526.

[4] 管慶，朱海，王凱，等.基于TMS320DM8168的視頻監控跟蹤系統[J].數據采集與處理，2013(6)：652-657.

[5] RFC2326.Realtimestreamingprotocol(RTSP)[S].

[6] CHU D，JIANG C，HAO Z，et al.The design and implementation of video surveillance system based on H.264，SIP，RTP/RTCP and RTSP[C].Computational Intelligence and Design(ISCID)，2013 Sixth International Symposium on.IEEE，2013，2：39-43.

[7] 鄭亮.基于DM8168多路視頻監控系統研制[D].杭州：杭州電子科技大學，2014.

[8] 李校林，劉利權，張杰.基于RTP的H.264視頻流實時打包傳輸的研究[J].計算機工程與科學，2012，34(5)：168-171.