0 引言

    隨著3G、4G移動互聯(lián)網(wǎng)的發(fā)展，市場上利用手機等移動設(shè)備實現(xiàn)視頻會議的方案越來越多。無論哪種方案，基本都是由移動設(shè)備客戶端、服務(wù)器端、視頻播放客戶端三部分組成。而視頻播放客戶端不外乎采用客戶端/服務(wù)器端（C/S）或瀏覽器/服務(wù)器端（B/S）架構(gòu)。代表性的方案有利用WEBRTC實現(xiàn)基于谷歌瀏覽器的視頻會議系統(tǒng)^[1-2]。這種B/S架構(gòu)的用戶通過系統(tǒng)內(nèi)置的攝像頭和麥克風(fēng)采集視頻圖像和語音信號，通過谷歌瀏覽器接入Internet建立連接，在網(wǎng)絡(luò)傳輸層利用RTP/RTCP協(xié)議實時傳輸語音和視頻數(shù)據(jù)給其他客戶端。這種架構(gòu)的優(yōu)點是無需安裝插件即可在瀏覽器上打開視頻會議，但是視頻編碼采用VP8編碼方式，大部分手機不提供支持，而且在多人視頻會議時，會因帶寬不足影響會議質(zhì)量?；贑++的crtmpserver流媒體服務(wù)器^[3]使用RTMP^[4]協(xié)議，在Linux平臺下運行，支持將手機上傳的RTMP流轉(zhuǎn)發(fā)、存儲的功能。RTMP協(xié)議的客戶端是Flash，可以很好地支持B/S架構(gòu)的流媒體服務(wù)器設(shè)計。然而RTMP協(xié)議基于TCP/IP協(xié)議，不支持UDP協(xié)議，所以網(wǎng)絡(luò)負(fù)荷比UDP大，傳輸速度也要比UDP慢。

    本系統(tǒng)采用開源的Darwin流媒體服務(wù)器對實時視頻流進行處理，結(jié)合開源庫mp4v2^[5]實現(xiàn)實時視頻的轉(zhuǎn)發(fā)和錄制。Darwin服務(wù)器^[6]基于RTSP協(xié)議進行傳輸，相比RTMP協(xié)議，支持TCP/IP協(xié)議和UDP/RTP協(xié)議，具有更高的實時性。系統(tǒng)使用手機硬編碼實時采集音視頻數(shù)據(jù)。C/S播放客戶端采用開源RTSP架構(gòu)live555^[7]結(jié)合開源編解碼庫ffmpeg實現(xiàn)視頻直播、點播播放。B/S播放客戶端采用Html5^[8]技術(shù)實現(xiàn)視頻點播，由支持RTSP協(xié)議的VLC Flash插件實現(xiàn)直播。

1 多平臺播放解決方案模型

    系統(tǒng)由移動設(shè)備客戶端、服務(wù)器端、視頻播放客戶端三部分組成。本文中實驗的移動客戶端為支持安卓系統(tǒng)的手機，通過調(diào)用手機設(shè)備上的攝像頭和麥克風(fēng)，進行音視頻采集。由于在3G網(wǎng)絡(luò)下服務(wù)器訪問手機移動IP地址需要“打洞”，故采用手機主動推送的方式進行視頻傳輸。服務(wù)器端采用支持RTSP協(xié)議的Darwin Stream Server開源服務(wù)器，負(fù)責(zé)RTSP流的轉(zhuǎn)發(fā)，因不支持視頻存儲功能，所以結(jié)合開源庫mp4v2實現(xiàn)服務(wù)器端視頻流的錄制，存儲手機客戶端采集的視頻到服務(wù)器上。播放客戶端包括C/S架構(gòu)的PC播放客戶端和B/S架構(gòu)的瀏覽器客戶端，實現(xiàn)在播放列表中直播或點播文件。系統(tǒng)整體架構(gòu)如圖1所示。

2 手機端設(shè)計

2.1 手機端方案

    利用手機本身硬件的編碼功能，視頻采用H264編碼，音頻采用AAC編碼，將編碼后的音視頻數(shù)據(jù)封裝到RTP包中發(fā)送到服務(wù)器端。手機客戶端主要由音視頻采集及編碼模塊、RTP/RTCP^[9]數(shù)據(jù)壓縮及控制模塊、RTSP傳輸控制模塊三部分組成，流程框圖如圖2所示。

2.2 模塊設(shè)計

    (1)音視頻采集及編碼模塊

    采用MediaRecorder類，首先調(diào)用該類的setAudioSource和setVideoSource設(shè)置音視頻采集源，再通過該類的setAudioEncoder()和setVideoEncoder()設(shè)置音視頻的編碼方式。以h.264視頻編碼為例，調(diào)用該類中的SetoutputFile函數(shù)綁定LocalSocket實現(xiàn)。在編碼過程中可以使用硬編碼的方式，硬編碼是在預(yù)覽過程提前確定視頻的sps、pps、head（一般為0x00000001）。

    (2)RTP/RTCP數(shù)據(jù)壓縮及控制模塊

    RTP包傳送可以基于UDP或者TCP，采用TCP作為傳輸層協(xié)議注重可靠性而不是及時性，在RTP傳輸過程中應(yīng)用很少，大部分RTP包發(fā)送都是采用UDP方式。在RTP會話過程前，發(fā)送方需要確定接收方的目標(biāo)IP及接收端口。

    (3)RTSP傳輸控制模塊

    RTSP協(xié)議作為應(yīng)用層協(xié)議，RTSP命令的傳輸是基于TCP協(xié)議，RTSP本身不作為數(shù)據(jù)傳輸?shù)膮f(xié)議，而是作為一種流媒體傳輸過程的控制協(xié)議。

    通過RTSP與服務(wù)器進行音視頻流媒體傳輸有兩種方式：拉模式和推模式。拉模式是主從模式，拉方(例如視頻播放客戶端)需要維護各個被拉方(例如攝像頭)的狀態(tài)，如url信息、端口信息等，只有拉方主動請求被拉方告知相應(yīng)信息才能啟動。推模式主動權(quán)在推方(本文即為安卓移動設(shè)備端)，從接方(本文即為Darwin服務(wù)器)來看，只要做好標(biāo)準(zhǔn)接口即可，無需關(guān)注有多少推方會推送數(shù)據(jù)。由于移動設(shè)備在3G網(wǎng)絡(luò)下，如果選擇拉模式，同一個網(wǎng)段下還需穿透NAT，即“打洞”，不方便做遠程音視頻傳輸，所以選擇推模式下的視頻傳輸。

3 Darwin服務(wù)器端設(shè)計

    本系統(tǒng)中服務(wù)器端負(fù)責(zé)轉(zhuǎn)發(fā)和存儲音視頻數(shù)據(jù)，主要由RTSP連接建立模塊、視頻轉(zhuǎn)發(fā)模塊及視頻錄制模塊三部分構(gòu)成。視頻播放客戶端發(fā)送RTSP請求，Darwin流媒體服務(wù)器通過Modules發(fā)送數(shù)據(jù)包來回復(fù)客戶，處理相應(yīng)的RTSP請求。Darwin服務(wù)器作為流媒體客戶端的中繼代理，移動設(shè)備在RTSP協(xié)議中的ANNOUNCE命令攜帶.sdp文件到Darwin服務(wù)器接收sdp的目錄文件中。此后視頻播放客戶端就可以通過rtsp://<DSS IP>/***.sdp請求.sdp文件獲取到手機客戶端對應(yīng)地址和端口的流。由于Darwin服務(wù)器本身不支持視頻錄制，故加入開源庫mp4v2實現(xiàn)視頻錄制，具體各模塊如下：

3.1 RTSP連接建立模塊

    Darwin Streaming Server定義了RTSPListenerSocket Class，它繼承自TCPListenerSocket Class,用于對RTSP連接請求進行處理，進入RTSP狀態(tài)機。通過RTSPSession對象完成對請求類型的匹配，如果匹配成功，則注冊QTSS_RTSPPreProcessor_Role角色的模式。在這個角色模式下，進入QTSSReflectorModule類處理了每種RTSP消息，比如本次RTSP請求的Describe、Setup、Play指令。該類中針對各種請求指令都有對應(yīng)的單獨函數(shù)處理，分別對應(yīng)著DoAnnounce、DoDescribe、DoSetup和DoPlay函數(shù)。除此之外，RTSP狀態(tài)機的終結(jié)點所在位置也是在QTSSReflectorModule類中，通過Shutdown()函數(shù)實現(xiàn)RTSP會話的結(jié)束。

3.2 視頻轉(zhuǎn)發(fā)建立模塊

    當(dāng)收到一路RTSP連接請求時，在DSS中為RTSPSession類對象，首先需要解析請求頭部是否為轉(zhuǎn)發(fā)請求，進而解析其請求的后續(xù)部分。進行查詢字符串的解析，得到需要轉(zhuǎn)發(fā)的具體url，建立一路面向url源的會話，通過Describe命令獲取到sdp信息進行保存，再轉(zhuǎn)發(fā)到請求Describe的客戶端，而且Setup、Play分別將對應(yīng)的響應(yīng)碼返回給客戶端，在轉(zhuǎn)發(fā)具體的數(shù)據(jù)時，建立一路ReflectorSession，將獲取到的rtp數(shù)據(jù)轉(zhuǎn)發(fā)到添加進ReflectorSession轉(zhuǎn)發(fā)列表的客戶端中。

3.3 視頻錄制模塊

    要實現(xiàn)視頻錄制，首先需要找到音視頻RTP數(shù)據(jù)包，然后將編碼過后的H264視頻和AAC音頻數(shù)據(jù)從RTP包中按續(xù)提取出來，并以MP4文件格式封裝，最后存成文件。在Darwin服務(wù)器中的ProcessRTPData()函數(shù)內(nèi)部處理處理接收到的RTP包，提取char*  packetData數(shù)據(jù)傳遞到MP4文件生成函數(shù)中。具體通過創(chuàng)建MP4文件句柄、設(shè)置時間標(biāo)度、添加h264視頻軌道及aac音頻軌道^[10]、添加序列參數(shù)集和圖像參數(shù)集，最后再寫入文件的方式生成MP4文件。具體視頻存儲步驟如下：

    (1)通過MP4Create創(chuàng)建MP4文件句柄。

    (2)通過MP4SetTimeScale設(shè)置時間標(biāo)度，即每秒的時鐘ticks數(shù)。

    (3)通過MP4AddH264VideoTrack添加h264視頻track，MP4AddAudioTrack添加aac音頻track。

    (4)通過MP4AddH264SequenceParameterSet和MP4AddH264PictureParameterSet添加序列參數(shù)集和圖像參數(shù)集。

    (5)通過MP4WriteSample寫一幀視頻數(shù)據(jù)或?qū)懸欢我纛l數(shù)據(jù)。

    其中duration這個參數(shù)是用來實現(xiàn)音視頻同步用的，如果設(shè)置錯了會造成音視頻不同步，甚至?xí)霈F(xiàn)crash現(xiàn)象。對于視頻流MP4WriteSample函數(shù)，每次調(diào)用是錄制前一幀數(shù)據(jù)，用當(dāng)前幀的時間戳和前一幀的時間戳計算duration值，然后把當(dāng)前幀保存下來在下次調(diào)用MP4WriteSample時用，寫音頻數(shù)據(jù)一樣。

    (6)通過MP4Close關(guān)閉打開的MP4文件。

4 B/S架構(gòu)及C/S架構(gòu)客戶端設(shè)計

4.1 C/S架構(gòu)客戶端原理

    C/S架構(gòu)的播放客戶端通過支持RTSP的開源live555構(gòu)建與手機移動客戶端的RTSP通信，通過開源編解碼框架ffmpeg的解碼功能進行解碼。

    通過live555構(gòu)建RTSP的過程為：首先創(chuàng)建BasicTaskScheduler和BasicUsageEnvironment對象，用于調(diào)度不同事件。創(chuàng)建RTSPClient對象，由RTSPClient對象向服務(wù)器發(fā)送RTSP中的OPTION消息命令并等待接受回應(yīng)，返回SDPDescription字符串即sdp文件內(nèi)容。在任務(wù)調(diào)度while循環(huán)中配置所有子會話對象，為每個子會話創(chuàng)建RTPSource和RTCPInstance對象，并創(chuàng)建兩個GroupSock對象。將每個GroupSock對象中創(chuàng)建的socket描述符置入 BasicTaskScheduler::fReadSet中，RTPSource對象的創(chuàng)建的依據(jù)是SDPDescription。由RTSPClient對象向服務(wù)器發(fā)送SETUP消息并接受回應(yīng)，while循環(huán)中為每個子會話創(chuàng)建接收器FileSink對象，由RTSPClient對象向服務(wù)器發(fā)送PLAY消息并接受回應(yīng)，F(xiàn)ileSink的緩沖區(qū)和包含寫入文件操作的一個函數(shù)指針配置給RTPSource對象，這個緩沖區(qū)將會在networkReadHandler中接收來自網(wǎng)絡(luò)的視音頻數(shù)據(jù)。

    獲取到音視頻數(shù)據(jù)后，通過ffmpeg[11]的解碼功能進行解碼處理，流程如圖3所示。

    avformat_open_input函數(shù)對輸入的文件名進行解析，并發(fā)起與Darwin服務(wù)器的RTSP交互。在數(shù)據(jù)讀取線程中，使用rtsp_read_packet函數(shù)用于每個RTP包的讀取和第一次排序解析。首先調(diào)用rtp_read函數(shù)從緩沖區(qū)獲取數(shù)據(jù)，然后通過包隊列交給RTP解析函數(shù)rtp_parse_packet進行第一次解析。第一次解析的目的是對包進行重新排序，解決因為網(wǎng)絡(luò)抖動導(dǎo)致接收到的包序列號不連續(xù)的問題。具體是根據(jù)RTP協(xié)議解析RTP包頭信息，對RTP包頭的包序列號按遞增順序重新排序。然后調(diào)用av_parser_parse2函數(shù)對RTP包進行第二次重組幀解析，目的是將包中的數(shù)據(jù)重新按幀進行組合，組成一幀數(shù)據(jù)的avpacket。

4.2 B/S架構(gòu)的實現(xiàn)

    B/S架構(gòu)的服務(wù)器端采用Apache服務(wù)器，Web客戶端采用HTML5的技術(shù)直接播放緩存在Darwin服務(wù)器下的MP4^[12]視頻。Web客戶端通過訪問Darwin服務(wù)器下錄制視頻存放的文件夾，獲取mp4后綴的文件名，輸出到Web客戶端播放列表中。Web客戶端實現(xiàn)圖片保存及視頻大小控制等功能。注冊VLC的ActiveX^[13]嵌入到網(wǎng)頁中，實現(xiàn)直播功能。B/S架構(gòu)播放客戶端如圖4所示。

5 測試及分析

    根據(jù)上述設(shè)計，客戶端采用B/S架構(gòu)的Web客戶端及C/S架構(gòu)的PC客戶端均可正常觀看直播視頻，通過mp4v2可實現(xiàn)視頻存儲功能。本系統(tǒng)服務(wù)器使用中國電信100M光纖網(wǎng)絡(luò)，用60個B/S架構(gòu)及C/S架構(gòu)客戶端分3組同時請求3路手機推送視頻。3路手機視頻端碼率均設(shè)為為500 kb/s，視頻采集分辨率分別為320×240、640×480、720×1 280，并在720p分辨率的條件下分3次在中國聯(lián)通3G網(wǎng)絡(luò)、中國電信3G網(wǎng)絡(luò)及無線WiFi網(wǎng)絡(luò)下分別統(tǒng)計手機移動客戶端的視頻播放延遲時間。其中服務(wù)器所用的硬件環(huán)境為：中央處理器：Inter Core I5-2 450 M 2.5 GHz雙核四線程；內(nèi)存：4 GB DDR3 1 333 MHz；硬盤：5 400 rad/min；操作系統(tǒng)：32位 Windows7 操作系統(tǒng)。

    播放客戶端通過RTSP請求觀看直播，請求如：rtsp:// 202.193.53.103/teststream.sdp，由sdp文件名區(qū)分不同推送視頻源。表1統(tǒng)計了在中國聯(lián)通3G網(wǎng)絡(luò)、中國電信3G網(wǎng)絡(luò)及無線WiFi網(wǎng)絡(luò)下分別統(tǒng)計手機移動客戶端的視頻播放延遲時間。

    通過60個客戶端同時請求服務(wù)器連接，表明服務(wù)器在帶寬為100M光纖網(wǎng)絡(luò)的條件下，可以同時滿足60個用戶同時請求連接?？蛻舳送瑫r請求的數(shù)量由服務(wù)器網(wǎng)絡(luò)帶寬決定。通過分別在中國聯(lián)通3G網(wǎng)絡(luò)、中國電信3G網(wǎng)絡(luò)及無線WiFi網(wǎng)絡(luò)下推送視頻的播放延遲區(qū)別表明，系統(tǒng)整體滿足不同網(wǎng)絡(luò)條件下的需求，具有較好的實時性。

6 結(jié)束語

    本文通過移動設(shè)備客戶端、服務(wù)器端、視頻播放客戶端組成的系統(tǒng)架構(gòu)闡述了一個新的視頻直播、錄制及多平臺播放的解決方案。詳細討論了移動設(shè)備客戶端音視頻采集及傳輸方案、服務(wù)器端的轉(zhuǎn)發(fā)及存儲方案，以及視頻播放客戶端的兩種架構(gòu)，分析了基于live555的RTSP通信過程及基于mp4v2的視頻存儲過程，開發(fā)出了整套直播、點播系統(tǒng)。同時，設(shè)計了相應(yīng)的測試實驗，為實現(xiàn)高可靠、高實時性的視頻直播系統(tǒng)提供了一種較為可行的方法。

參考文獻

[1] ELLEUCH W.Models for multimedia conference between browsers based on WebRTC[C].Wireless and Mobile Computing，Networking and Communications(WiMob)，2013 IEEE 9th International Conference on，IEEE，2013：279-284.

[2] RHINOW F，VELOSO P P，PUYELO C，et al.P2P live video streaming in WebRTC[C].2014 World Congress on WCCAIS，2014：1-6.

[3] 丁杰，潘晨光，田源.基于crtmpserver的手機直播系統(tǒng)[J].計算機工程與設(shè)計，2014，35(9):3173-3178.

[4] 姜浩然，徐林.基于RTMP的流媒體服務(wù)器的研究[J].計算機與數(shù)字工程，2011，39(10)：104-108.

[5] 史紅周，黃晁.一種基于MP4文件的視頻流關(guān)鍵幀索引播放方法[J].微電子學(xué)與計算機，2002，19(7)：44-47.

[6] 李新樂，蘇鴻根.流媒體搜索和發(fā)布技術(shù)在移動設(shè)備上的應(yīng)用[J].計算機工程與設(shè)計，2009，30(6)：1428-1431.

[7] 茅炎菲，黃忠東.基于RTSP協(xié)議網(wǎng)絡(luò)監(jiān)控系統(tǒng)的研究與實現(xiàn)[J].計算機工程與設(shè)計，2011，32(7)：2523-2526.

[8] 羅大暉，陳娟.基于HTML5的Web離線應(yīng)用研究與實現(xiàn)[J].計算機應(yīng)用與軟件，2012，29(12)：262-264.

[9] 李校林，劉海波，張杰，等.RTP/RTCP，RTSP在無線視頻監(jiān)控系統(tǒng)的設(shè)計與實現(xiàn)[J].電視技術(shù)，2011，35(19)：89-92.

[10] 韋崇嶺，裴海龍.基于無人機平臺H264視頻傳輸系統(tǒng)的設(shè)計與實現(xiàn)[J].計算機測量與控制，2012，20(1)：209-211.

[11] 劉麗霞，邊金松，張琍，等.基于FFMPEG解碼的音視頻同步實現(xiàn)[J].計算機工程與設(shè)計，2013，34(6)：2087-2092.

[12] 李興華，楊天奇.MP4共享FLV數(shù)據(jù)研究與實現(xiàn)[J].微型機與應(yīng)用，2014(3)：31-34.

[13] ZHU G，ZHANG F，ZHU W，et al.HTML5 based media player for real-time video surveillance[C].Image and Signal Processing(CISP)，2012 5th International Congress on.IEEE，2012：245-248.