黃慧精

摘要：視頻監(jiān)控是安防領(lǐng)域的重要組成部分，是當(dāng)今社會安全系統(tǒng)中相當(dāng)關(guān)鍵的一環(huán)。流媒體服務(wù)器又是其重要的設(shè)計環(huán)節(jié)，流媒體服務(wù)器的引入有效地解決了監(jiān)控系統(tǒng)的帶寬瓶頸，本文主要介紹了流媒體轉(zhuǎn)發(fā)服務(wù)器的系統(tǒng)實現(xiàn)架構(gòu)，提高轉(zhuǎn)發(fā)效率設(shè)計的實現(xiàn)，并系統(tǒng)化展示了其功能環(huán)節(jié)。

關(guān)鍵詞：流媒體轉(zhuǎn)發(fā)；RTSP； RTP；RTCP

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2017）34-0199-02

1 概述

隨著監(jiān)控系統(tǒng)的系統(tǒng)化、效率化的發(fā)展和提高，流媒體技術(shù)的引入有效地提高了監(jiān)控系統(tǒng)的傳輸機制，流媒體技術(shù)是將視頻或音頻等多媒體數(shù)據(jù)以RTP數(shù)據(jù)包的形式，將前端設(shè)備IPC數(shù)據(jù)流實時傳輸至客戶端。流媒體服務(wù)器能實現(xiàn)同時響應(yīng)多個客戶端的視頻流實時請求，從而有效地解決了帶寬的限制。

本文詳細(xì)介紹了流媒體服務(wù)器的功能架構(gòu)，具體的設(shè)計、實現(xiàn)，并以系統(tǒng)的形式展現(xiàn)其功能價值。

2 系統(tǒng)總體框架

2.1 系統(tǒng)流程設(shè)計

整個視頻監(jiān)控系統(tǒng)由多個部分構(gòu)成，前端設(shè)備IPC負(fù)責(zé)采集視頻數(shù)據(jù)，流媒體服務(wù)器負(fù)責(zé)轉(zhuǎn)發(fā)媒體視頻流數(shù)據(jù)，監(jiān)控平臺主要給客戶端提供瀏覽視頻使用。流媒體服務(wù)器起關(guān)鍵作用，當(dāng)客戶端需要某路視頻圖像時，通過RTSP協(xié)議與流媒體服務(wù)器建立通道連接，流媒體解析消息后，再與對應(yīng)的IPC建立流連接通道；IPC上傳RTP視頻數(shù)據(jù)流至流媒體服務(wù)器上，流媒體再接受到該數(shù)據(jù)包后，做相應(yīng)處理，再轉(zhuǎn)發(fā)給請求的客戶端。

2.2 軟硬件接口設(shè)計

流媒體服務(wù)器與客戶端和IPC軟件接口采用目前常用的RTP、RTSP、RTCP協(xié)議，系統(tǒng)運行前需要先配置流媒體服務(wù)器的相關(guān)信息，供客戶端調(diào)用?？蛻舳耸且环N應(yīng)用視頻軟件，提供了視頻界面，有一定的參數(shù)配置等。當(dāng)多個客戶端同時訪問同一個視頻流時，流媒體可以有效地減輕網(wǎng)絡(luò)寬帶壓力的影響。

考慮系統(tǒng)吐吞量比較大，該系統(tǒng)采用千兆雙網(wǎng)口，一個是視頻入，一個是視頻出；運行在嵌入式linux操作系統(tǒng)上。性能主要表現(xiàn)為系統(tǒng)的反應(yīng)速度和響應(yīng)時間，作為一個實時監(jiān)控系統(tǒng)，對反應(yīng)速度和響應(yīng)時間的要求要高，同時還要滿足多客戶端同時點播前端設(shè)備的情況。每個流媒體服務(wù)器最大支持64路1080p/8Mbps碼流或128路720p/4Mbps碼流。

3 流媒體服務(wù)器設(shè)計與實

3.1 流媒體點播處理過程

視頻點播過程又可分為兩個過程即請求視頻數(shù)據(jù)和停止視頻數(shù)據(jù)。具體流程如下，

請求視頻數(shù)據(jù)流程：

（1） 流媒體服務(wù)器收到由客戶端數(shù)據(jù)請求后，解析訪問者信息（IP/PORT）。

（2） 判斷客戶端請求的設(shè)備是否已經(jīng)建立過連接，如果已經(jīng)建立連接，直接給請求的客戶端轉(zhuǎn)發(fā)視頻流，并記錄訪問媒體數(shù)據(jù)流量。如果沒有建立連接，則通過RTSP與IPC交互并接受來自IPC的RTP數(shù)據(jù)流。

停止視頻數(shù)據(jù)流程：

（1） 流媒體服務(wù)器在接到客戶端發(fā)出的請求終止視頻數(shù)據(jù)的消息后，立即解析訪問者的信息數(shù)據(jù)流（IP/PORT）。

（2） 判斷視頻服務(wù)器請求的設(shè)備是否還有其他客戶端連接，如果還有其他客戶端連接，則直接斷開與客戶端連接通道即可；如果沒有其他客戶端訪問該設(shè)備，先停止相應(yīng)的轉(zhuǎn)發(fā)服務(wù)，再斷開與客戶端的連接通道。

3.2 流媒體系統(tǒng)設(shè)計

流媒體服務(wù)器與IPC端之間數(shù)據(jù)流，有三條消息通道，一條通道是RTP協(xié)議數(shù)據(jù)鏈路，這條通道主要工作是接收前端設(shè)備IPC的視頻RTP數(shù)據(jù)流；第二條通道是RTCP協(xié)議數(shù)據(jù)鏈路，這條通道的工作是傳輸RTP鏈路協(xié)議中的QoS控制消息，然后讓服務(wù)器根據(jù)這條通路發(fā)送的消息來調(diào)整整個發(fā)送端的速率。再一條是RTSP協(xié)議數(shù)據(jù)鏈路，主要完成與IPC端的通信建立之前的交互操作，獲取所需的參數(shù)信息。

流媒體服務(wù)器與客戶端之間數(shù)據(jù)流，有兩條數(shù)據(jù)通道，一條通道是RTP協(xié)議數(shù)據(jù)鏈路，這條通道負(fù)責(zé)轉(zhuǎn)發(fā)由服務(wù)器端向客戶端傳輸?shù)囊曨l流。第二條通道是RTCP協(xié)議數(shù)據(jù)鏈路，主要完成傳輸RTP鏈路協(xié)議中的QoS控制消息，使得服務(wù)器根據(jù)這些消息調(diào)整發(fā)送端的速率。

流媒體服務(wù)器主要功能是響應(yīng)客戶端的請求，然后從IPC獲取需要的視頻流數(shù)據(jù)，最后為發(fā)出請求的客戶端轉(zhuǎn)發(fā)視頻。當(dāng)流媒體服務(wù)器接收到來自客戶端的點播或請求后，服務(wù)器啟動該線程，監(jiān)聽來自客戶端的請求。若有多個客戶端點播，則流媒體服務(wù)器需要啟動多個處理線程，為了節(jié)省資源減少操作，我們可以定義一個線程池，預(yù)先開啟多個線程，每當(dāng)接收一個客戶端請求時，直接從線程池中啟用，當(dāng)客戶端斷開后，釋放線程，再將其放入到線程池中，這樣可以減少很多關(guān)于線程創(chuàng)建和釋放的操作。同時流媒體服務(wù)器需要先創(chuàng)建一個緩沖區(qū)，用來存放來自前端IPC設(shè)備發(fā)過來的RTP報文，同時為了避免多線程同時操作數(shù)據(jù)造成數(shù)據(jù)錯亂，需要創(chuàng)建一個臨界區(qū)，用互斥量來保證數(shù)據(jù)的順序執(zhí)行。流媒體服務(wù)器主要設(shè)計流程如圖1。

從系統(tǒng)設(shè)計流程圖（圖1）可以看出，要建立的RTP會話的數(shù)量與當(dāng)前IPC流媒體服務(wù)器之間傳輸?shù)囊曨l路數(shù)相對應(yīng)。即要轉(zhuǎn)發(fā)多少路視頻，就要建立多少個相應(yīng)的RTP會話，同時每一個RTP都要有自己相應(yīng)的線程。所以要建立的RTP線程數(shù)量，與要轉(zhuǎn)發(fā)出去的視頻路數(shù)沒有必然的聯(lián)系。結(jié)果表明，一個RTP會話的一路視頻，可以轉(zhuǎn)發(fā)給多個用戶。

RTP會話的關(guān)閉取決于當(dāng)前視頻通道的轉(zhuǎn)發(fā)情況，而不是由一個客戶端的停止請求所確定。當(dāng)客戶端發(fā)出一個停止請求時，服務(wù)器先把發(fā)出請求的客戶端地址從轉(zhuǎn)發(fā)列表中刪除，然后再判斷當(dāng)期通道請求的數(shù)量。如果當(dāng)期通道請求的數(shù)量為0，就結(jié)束當(dāng)期RTP的會話，關(guān)閉線程，實時流視頻停止請求的工作。

4 系統(tǒng)運行與測試

系統(tǒng)搭建完畢后，配置設(shè)備的參數(shù)，系統(tǒng)正常啟動后，視頻流從前端設(shè)備IPC經(jīng)過轉(zhuǎn)發(fā)服務(wù)器回傳到客戶端，本系統(tǒng)中使用兩個IPC，流媒體服務(wù)器一臺，一臺筆記本主要運行客戶端軟件。具體顯示如圖2、圖3：

5 結(jié)束語

本文從系統(tǒng)設(shè)計和高效的資源管理方面提出了設(shè)計和改進(jìn)方案，實驗證明該方案有效地降低了CPU的使用率，極大提高了視頻轉(zhuǎn)發(fā)處理能力，很好提高了吐吞量。

參考文獻(xiàn)：

[1] 畢厚杰.視頻壓縮編碼標(biāo)準(zhǔn)—H.264/AVC[M].北京：人民郵電出版社，2009.

[2] TMS320DM368 digital media system-on-chip[EB/OL].[2010-07-27].

[3] RTP：a transprot protocol for real-time application[EB/OL].[2010-07-27].

[4] 王艷營. H.264中塊匹配的快速搜索算法研究.中國有線電視，2007（24）.

[5] 張曉燕，李瑞欣，劉玲霞.多媒體通信技術(shù)[M].北京：北京郵電大學(xué)出版社，2009.

[6] http：//focus.ti.com.cn/cn/docs/prod/folders/print/tms320dm368.html.endprint