0 引言

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

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

1 硬件平臺選擇

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

1.1 TMS320DM8168芯片結(jié)構(gòu)

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

1.2 多通道視頻處理框架

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

2 RTSP協(xié)議分析

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

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

3 RTSP服務(wù)器系統(tǒng)實現(xiàn)

    本文軟件架構(gòu)的設(shè)計均在MCFW框架中實現(xiàn)，按照不同的功能進行劃分，系統(tǒng)主要分為視頻采集、視頻處理、視頻編碼、本地存儲以及RTSP服務(wù)器5個部分。

3.1 視頻采集處理和編碼設(shè)計

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

3.2 RTSP服務(wù)器設(shè)計

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

3.2.1 RTSP會話交互線程

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

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

3.2.2 碼流獲取線程

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

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

4 實驗結(jié)果及數(shù)據(jù)分析

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

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

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

5 結(jié)論

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

參考文獻

[1] 李軍，倪宏，陳君，等.一種應(yīng)用層協(xié)議解析加速算法[J].四川大學(xué)學(xué)報(工程科學(xué)版)，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協(xié)議網(wǎng)絡(luò)監(jiān)控系統(tǒng)的研究與實現(xiàn)[J].計算機工程與設(shè)計，2011，32(7)：2523-2526.

[4] 管慶，朱海，王凱，等.基于TMS320DM8168的視頻監(jiān)控跟蹤系統(tǒng)[J].數(shù)據(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多路視頻監(jiān)控系統(tǒng)研制[D].杭州：杭州電子科技大學(xué)，2014.

[8] 李校林，劉利權(quán)，張杰.基于RTP的H.264視頻流實時打包傳輸?shù)难芯縖J].計算機工程與科學(xué)，2012，34(5)：168-171.