李校林，劉海波，張 杰，劉利權(quán)

(1.重慶郵電大學(xué) 通信新技術(shù)應(yīng)用研究所，重慶 400065;2.重慶信科設(shè)計(jì)有限公司，重慶 400065)

0 引言

無線視頻監(jiān)控系統(tǒng)是以流媒體技術(shù)為核心，融合智能傳感器、3G網(wǎng)絡(luò)、計(jì)算機(jī)智能等技術(shù)為一體的新型視頻監(jiān)控系統(tǒng)。流媒體技術(shù)是指視頻、音頻等數(shù)據(jù)以實(shí)時(shí)傳輸協(xié)議RTP承載，并以連續(xù)的流形式從源端向目的端傳輸，在目的端接收到一定緩存數(shù)據(jù)后就可以播放出來的多媒體應(yīng)用。把流媒體技術(shù)應(yīng)用到移動(dòng)網(wǎng)絡(luò)上，就可以稱之為移動(dòng)流媒體技術(shù)。隨著近幾年我國(guó)3G網(wǎng)絡(luò)的大規(guī)模商用，3G帶來的最直接變化就是移動(dòng)網(wǎng)絡(luò)帶寬不再是視頻業(yè)務(wù)發(fā)展的瓶頸。移動(dòng)流媒體技術(shù)在無線網(wǎng)絡(luò)中也有了巨大的突破，無線視頻監(jiān)控系統(tǒng)已經(jīng)成為可能。

本文首先分析了RTP/RTCP［1］，RTSP流媒體協(xié)議的基本概念和原理，然后重點(diǎn)研究了RTP/RTSP功能模塊及RTCP傳輸控制模塊的設(shè)計(jì)和具體實(shí)現(xiàn)方法。

1 協(xié)議介紹

1.1 流媒體協(xié)議

流媒體協(xié)議中的RTP主要完成實(shí)時(shí)視頻數(shù)據(jù)流的傳輸，RTP協(xié)議承載視頻數(shù)據(jù)傳輸任務(wù)，但它本身不提供QoS，而需要RTCP協(xié)議為應(yīng)用層提供視頻質(zhì)量控制的手段和方法。RTP數(shù)據(jù)包主要在用戶數(shù)據(jù)報(bào)協(xié)議(UDP協(xié)議)上傳送數(shù)據(jù)。RTP和RTCP協(xié)同使用，通過實(shí)時(shí)的反饋和調(diào)整使得網(wǎng)絡(luò)傳輸效果達(dá)到最好，即RTP/RTCP協(xié)議適合用于傳輸實(shí)時(shí)視頻數(shù)據(jù)流。而控制這些RTP數(shù)據(jù)包的發(fā)送則通過RTSP協(xié)議來完成。

1.2 實(shí)時(shí)傳輸協(xié)議(RTP)［2］

RTP(Real－time Transport Protocol)協(xié)議能夠給具有實(shí)時(shí)性的視頻、音頻等流媒體數(shù)據(jù)提供端到端的傳輸。RTP協(xié)議把RTP頭加上H.264視頻的RTP負(fù)載，并把時(shí)間戳和序列號(hào)等參數(shù)寫到RTP數(shù)據(jù)包內(nèi)通過UDP組播方式發(fā)送出去。由于采用UDP協(xié)議發(fā)送數(shù)據(jù)包，所以每次發(fā)送的RTP數(shù)據(jù)包大小不得超過1 460 byte。不同的發(fā)送端和接收端可以通過RTP中的SSRC來標(biāo)識(shí)，RTP又可以利用UDP的組播來支持多點(diǎn)傳送，使得RTP可以使用在多站點(diǎn)應(yīng)用中。

1.3 實(shí)時(shí)傳輸控制協(xié)議(RTCP)

RTCP(Real－time Transport Control Protocol)［3］與 RTP一起使用可以完成網(wǎng)絡(luò)流量控制和擁塞控制。RTCP的主要工作是質(zhì)量反饋，即通過統(tǒng)計(jì)網(wǎng)絡(luò)質(zhì)量參數(shù)，然后把網(wǎng)絡(luò)狀況反饋給發(fā)送端，發(fā)送端根據(jù)這些參數(shù)作出相應(yīng)的調(diào)整，以適應(yīng)網(wǎng)絡(luò)狀況。RTCP包的發(fā)送和接收的方式與RTP包的方式一樣，也是通過UDP來完成。在RTCP數(shù)據(jù)包中，包含網(wǎng)絡(luò)質(zhì)量的參數(shù)有間隔抖動(dòng)、包丟失率、往返延遲等，通過RTCP中的RR包將這些參數(shù)反饋給發(fā)送端，從而分析得到當(dāng)前的網(wǎng)絡(luò)狀態(tài)，使其作出相應(yīng)的碼率或甚至編碼方式的調(diào)整。

1.4 實(shí)時(shí)流協(xié)議(RTSP)［4］

RTSP(Real－time Streaming Protocol，簡(jiǎn)稱 RTSP)作為實(shí)時(shí)流媒體傳輸中的控制協(xié)議，負(fù)責(zé)控制實(shí)時(shí)數(shù)據(jù)RTP包的發(fā)送。RTSP協(xié)議可以控制多個(gè)數(shù)據(jù)源連接和發(fā)送，它本身并不發(fā)送數(shù)據(jù)流，RTSP充當(dāng)流媒體服務(wù)器端和客戶端的網(wǎng)絡(luò)遠(yuǎn)程控制。RTSP可以對(duì)流媒體提供播放、暫停、快進(jìn)、慢退等操作，主要負(fù)責(zé)定義具體的控制消息。

1.5 RTP/RTCP，RTSP協(xié)議關(guān)系圖

RTP/RTCP，RTSP協(xié)議關(guān)系圖見圖1。其中，RTP/RTCP工作在傳輸層，RTSP工作在應(yīng)用層。RTP主要承擔(dān)數(shù)據(jù)傳輸任務(wù)，而RTCP為應(yīng)用層提供視頻質(zhì)量控制的手段和方法。RTSP控制RTP數(shù)據(jù)包的發(fā)送。

圖1 RTP/RTCP，RTSP協(xié)議關(guān)系圖

2 RTP/RTCP，RTSP功能模塊設(shè)計(jì)

2.1 監(jiān)控系統(tǒng)結(jié)構(gòu)圖

該系統(tǒng)分為服務(wù)器端和客戶端，此系統(tǒng)有視頻流和控制信號(hào)兩條通道，根據(jù)監(jiān)控系統(tǒng)的功能需求，深入研究了移動(dòng)流媒體技術(shù)，給出監(jiān)控系統(tǒng)結(jié)構(gòu)圖，如圖2所示。

圖2 監(jiān)控系統(tǒng)結(jié)構(gòu)圖

分析監(jiān)控系統(tǒng)結(jié)構(gòu)圖，視頻流主要依靠RTP承擔(dān)傳輸H.264的壓縮數(shù)據(jù)，即H.264視頻的RTP負(fù)載格式(RTP for H.264)，控制信號(hào)則靠RTSP完成交互任務(wù)。將設(shè)計(jì)重點(diǎn)放在兩個(gè)方面上，一是RTP/RTSP功能模塊即客戶端與服務(wù)器端的交互過程，二是RTP發(fā)送過程及RTCP傳輸控制處理過程。

2.2 RTP/RTSP 功能模塊［5］流程

本文設(shè)計(jì)了一個(gè)C/S結(jié)構(gòu)的基于RTSP協(xié)議的視頻服務(wù)器。下面給出了具體的服務(wù)器端的應(yīng)答處理過程以及客戶端的請(qǐng)求過程。

2.2.1 服務(wù)器端應(yīng)答過程

服務(wù)器端RTSP請(qǐng)求處理過程見圖3。

圖3 RTSP請(qǐng)求處理過程

服務(wù)器交互過程如下:

1)服務(wù)器端創(chuàng)建，監(jiān)聽線程開啟，等待客戶端連接;當(dāng)客戶端請(qǐng)求RTSP連接，會(huì)創(chuàng)建一個(gè)RTSP會(huì)話，保存此客戶信息。

2)媒體資源服務(wù)器收到請(qǐng)求后，如果能正確建立連接，則返回一個(gè)獨(dú)立的會(huì)話序列號(hào)，同時(shí)服務(wù)器開啟新的線程，為該客戶建立一個(gè)新的視頻服務(wù)流，客戶端需要使用此序列號(hào)與服務(wù)器端進(jìn)行進(jìn)一步的通信，省去中間過程，當(dāng)客戶端向服務(wù)端發(fā)送play請(qǐng)求，請(qǐng)求成功，則客戶變成play狀態(tài);回應(yīng)ACK。并發(fā)過程為:編碼后啟動(dòng)RTSP服務(wù)，當(dāng)客戶狀態(tài)是play，則向?qū)?yīng)的客戶端發(fā)送RTP，RTCP包。

3)當(dāng)客戶端向服務(wù)端發(fā)送pause請(qǐng)求，請(qǐng)求成功，則客戶變成pause狀態(tài);回應(yīng)ACK。并發(fā)過程為:編碼后啟動(dòng)RTSP服務(wù)，當(dāng)客戶狀態(tài)是pause，則向?qū)?yīng)的客戶端暫停發(fā)送RTP，RTCP包。

4)當(dāng)客戶端向服務(wù)端發(fā)送TEARDOWN請(qǐng)求，請(qǐng)求成功，則刪除對(duì)應(yīng)客戶的信息;回應(yīng)ACK。

5)撤銷RTSP會(huì)話。

2.2.2 客戶端請(qǐng)求過程

客戶端RTSP請(qǐng)求過程如圖4所示。

客戶端交互過程為:

圖4 RTSP請(qǐng)求過程

1)請(qǐng)求得到回應(yīng)后，創(chuàng)建一個(gè)服務(wù)信息，同時(shí)創(chuàng)建一個(gè)并發(fā)過程即RTP包接收過程，等待接收服務(wù)器發(fā)送的RTP包，將RTP包放入buffer中待解碼。

2)當(dāng)播發(fā)請(qǐng)求發(fā)送時(shí)，服務(wù)器端開始發(fā)送RTP數(shù)據(jù)包，RTP包接收線程被啟動(dòng)，開始接收RTP數(shù)據(jù)包。

3)當(dāng)暫停請(qǐng)求發(fā)送時(shí)，服務(wù)器端暫停發(fā)送RTP數(shù)據(jù)包，RTP包接收線程被睡眠，暫停接收RTP數(shù)據(jù)包。

4)當(dāng)斷開連接請(qǐng)求發(fā)送成功并得到回應(yīng)時(shí)，則刪除服務(wù)信息，并刪除并發(fā)過程。

2.3 RTP發(fā)送過程及RTCP傳輸控制處理過程［6］

首先，在服務(wù)器端經(jīng)過數(shù)據(jù)采集得到的視頻流進(jìn)入編碼器編碼壓縮成H.264碼流，然后，把視頻流封裝成H.264視頻的RTP負(fù)載格式，并把時(shí)間戳和序列號(hào)等參數(shù)寫到RTP數(shù)據(jù)包內(nèi)，再放到RTP包緩沖區(qū)，交給下層UDP處理，UDP再對(duì)RTP包進(jìn)行封裝，UDP和RTP共同完成傳輸層協(xié)議的任務(wù)，UDP包交給IP網(wǎng)絡(luò)層處理，IP網(wǎng)絡(luò)層對(duì)UDP包再封裝，最后IP數(shù)據(jù)包經(jīng)由網(wǎng)絡(luò)向接收端發(fā)送。在客戶端接收到RTP包，再進(jìn)行RTP包頭處理，去除RTP頭，把RTP負(fù)載放入包列表中，排序并判斷是否為一幀，為一幀則解碼、顯示。在同時(shí)服務(wù)器端周期性的發(fā)送RTCP(SR)包，接收RTCP(RR)包，客戶端則接收RTCP(SR)，反饋RTCP(RR)，服務(wù)器端根據(jù)RR包中的丟包率以了解當(dāng)前網(wǎng)絡(luò)狀況，動(dòng)態(tài)調(diào)整流媒體編碼速率，從而進(jìn)一步調(diào)整RTP發(fā)送速率。服務(wù)器端與客戶端的傳輸控制過程見圖5。

圖5 服務(wù)器端與客戶端的傳輸控制過程

在服務(wù)器端進(jìn)行擁塞控制，除了動(dòng)態(tài)改變發(fā)送速率，還有就是對(duì)發(fā)送buffer進(jìn)行處理，被動(dòng)丟棄buffer中過期的RTP包，buffer大小設(shè)定為60×1 024 byte，當(dāng)buffer中滿1460 byte時(shí)，組成1個(gè)RTP包，并添上時(shí)間標(biāo)簽。因?yàn)榫W(wǎng)絡(luò)擁塞，那么此buffer中的RTP包可能有一定的發(fā)送時(shí)延，如果當(dāng)此RTP包的時(shí)間標(biāo)簽加上發(fā)送時(shí)延大于當(dāng)前的時(shí)間標(biāo)簽，則判斷此RTP包失去實(shí)時(shí)性，考慮丟棄此包，以此來降低網(wǎng)絡(luò)擁塞。

3 RTSP，RTP/RTCP服務(wù)器端的實(shí)現(xiàn)

首先創(chuàng)建RTSP服務(wù)器，在創(chuàng)建過程中，先建立套接字Socket在TCP的554端口進(jìn)行監(jiān)聽，然后把連接處理函數(shù)句柄和Socket句柄傳給任務(wù)調(diào)度器。當(dāng)RTSP客戶端輸入U(xiǎn)RL連接服務(wù)器時(shí)，select返回對(duì)應(yīng)的Socket，進(jìn)而根據(jù)前面保存的對(duì)應(yīng)關(guān)系，可找到對(duì)應(yīng)處理函數(shù)句柄。RTSP服務(wù)器收到客戶端的DESCRIBE請(qǐng)求后，根據(jù)請(qǐng)求URL，找到對(duì)應(yīng)的流媒體資源，返回響應(yīng)消息。RTSPCSession類用于處理單獨(dú)的客戶會(huì)話，其類成員函數(shù)handle_SETUP()處理客戶端的SETUP請(qǐng)求。對(duì)SETUP請(qǐng)求的傳輸頭解析，獲取流媒體發(fā)送傳輸參數(shù)。將這些參數(shù)組裝成響應(yīng)消息，返回給客戶端。RTSPCSession類成員函數(shù)handle_PLAY()處理客戶端的播放請(qǐng)求。

播放請(qǐng)求成功后發(fā)送端開始發(fā)送RTP包，首先是設(shè)置RTP包頭，再填充H.264編碼幀數(shù)據(jù)，最后就發(fā)送RTP數(shù)據(jù)包［7］。然后是計(jì)算下一個(gè)數(shù)據(jù)包發(fā)送時(shí)間，把句柄傳給任務(wù)調(diào)度器，作為一個(gè)延時(shí)事件調(diào)度。在主循環(huán)中，當(dāng)任務(wù)調(diào)度器被調(diào)度時(shí)，又開始組包然后發(fā)送新的數(shù)據(jù)包，這樣客戶端可以源源不斷地收到服務(wù)器傳來的RTP包了。在發(fā)送RTP包時(shí)，同時(shí)發(fā)送RTCP(SR)包，其就是根據(jù)收到客戶端發(fā)送過來的RTCP(RR)包，提取其中的內(nèi)容組成RTCP(SR)包，然后根據(jù)時(shí)間調(diào)度發(fā)送SR包。

下面列出部分函數(shù):

在客戶端請(qǐng)求視頻播放效果圖如圖6所示。

4 小結(jié)

運(yùn)行客戶端程序，在客戶端通過RTSP請(qǐng)求服務(wù)器端的視頻，請(qǐng)求成功后，服務(wù)端開始發(fā)送視頻流，在客戶端穩(wěn)定接收碼流，在視頻顯示區(qū)播放比較流暢，圖像清晰。

圖6 視頻播放效果圖(截圖)

［1］潘鵬，杜旭，葉婷，等.RTP/RTCP實(shí)時(shí)傳輸協(xié)議的研究與Linux實(shí)現(xiàn)［J］. 計(jì)算機(jī)工程與應(yīng)用，2005，24:105－107.

［2］RFC 3550，RTP:a transport protocol for real－time application［S］.2003.

［3］王彥麗，陳明，陳華，等.基于RTP/RTCP的數(shù)字視頻監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)［J］. 計(jì)算機(jī)工程與科學(xué)，2009，31(3):58－60.

［4］SCHULZRINNE H，RAO A，LANPHIER R.RFC 2326，Real time streaming protocol［S］.1998.

［5］章民融，徐亞峰.基于RTSP的流媒體視頻服務(wù)器的設(shè)計(jì)與實(shí)現(xiàn)［J］.計(jì)算機(jī)應(yīng)用與軟件，2006，23(7):93－95.

［6］劉國(guó)柱，王洪林.RTCP反饋和緩沖區(qū)的傳輸控制算法研究［J］.計(jì)算機(jī)工程與設(shè)計(jì)，2010，31(12):2704.

［7］王軍，呂海寶，許國(guó)梁.基于RTP/RTCP的遠(yuǎn)程視頻傳輸軟件的設(shè)計(jì)［J］. 電視技術(shù)，2002，26(12):19－21.