文獻標識碼: A
DOI:10.16157/j.issn.0258-7998.2015.08.035
中文引用格式: 張彤,蘆愛余,莫建文. 基于Darwin的多平臺多用戶直播、點播系統設計[J].電子技術應用,2015,41(8):124-127.
英文引用格式: Zhang Tong,Lu Aiyu,Mo Jianwen. Design of live video streaming, video-on-demand system based on Darwin[J].Application of Electronic Technique,2015,41(8):124-127.
0 引言
隨著3G、4G移動互聯網的發展,市場上利用手機等移動設備實現視頻會議的方案越來越多。無論哪種方案,基本都是由移動設備客戶端、服務器端、視頻播放客戶端三部分組成。而視頻播放客戶端不外乎采用客戶端/服務器端(C/S)或瀏覽器/服務器端(B/S)架構。代表性的方案有利用WEBRTC實現基于谷歌瀏覽器的視頻會議系統[1-2]。這種B/S架構的用戶通過系統內置的攝像頭和麥克風采集視頻圖像和語音信號,通過谷歌瀏覽器接入Internet建立連接,在網絡傳輸層利用RTP/RTCP協議實時傳輸語音和視頻數據給其他客戶端。這種架構的優點是無需安裝插件即可在瀏覽器上打開視頻會議,但是視頻編碼采用VP8編碼方式,大部分手機不提供支持,而且在多人視頻會議時,會因帶寬不足影響會議質量。基于C++的crtmpserver流媒體服務器[3]使用RTMP[4]協議,在Linux平臺下運行,支持將手機上傳的RTMP流轉發、存儲的功能。RTMP協議的客戶端是Flash,可以很好地支持B/S架構的流媒體服務器設計。然而RTMP協議基于TCP/IP協議,不支持UDP協議,所以網絡負荷比UDP大,傳輸速度也要比UDP慢。
本系統采用開源的Darwin流媒體服務器對實時視頻流進行處理,結合開源庫mp4v2[5]實現實時視頻的轉發和錄制。Darwin服務器[6]基于RTSP協議進行傳輸,相比RTMP協議,支持TCP/IP協議和UDP/RTP協議,具有更高的實時性。系統使用手機硬編碼實時采集音視頻數據。C/S播放客戶端采用開源RTSP架構live555[7]結合開源編解碼庫ffmpeg實現視頻直播、點播播放。B/S播放客戶端采用Html5[8]技術實現視頻點播,由支持RTSP協議的VLC Flash插件實現直播。
1 多平臺播放解決方案模型
系統由移動設備客戶端、服務器端、視頻播放客戶端三部分組成。本文中實驗的移動客戶端為支持安卓系統的手機,通過調用手機設備上的攝像頭和麥克風,進行音視頻采集。由于在3G網絡下服務器訪問手機移動IP地址需要“打洞”,故采用手機主動推送的方式進行視頻傳輸。服務器端采用支持RTSP協議的Darwin Stream Server開源服務器,負責RTSP流的轉發,因不支持視頻存儲功能,所以結合開源庫mp4v2實現服務器端視頻流的錄制,存儲手機客戶端采集的視頻到服務器上。播放客戶端包括C/S架構的PC播放客戶端和B/S架構的瀏覽器客戶端,實現在播放列表中直播或點播文件。系統整體架構如圖1所示。
2 手機端設計
2.1 手機端方案
利用手機本身硬件的編碼功能,視頻采用H264編碼,音頻采用AAC編碼,將編碼后的音視頻數據封裝到RTP包中發送到服務器端。手機客戶端主要由音視頻采集及編碼模塊、RTP/RTCP[9]數據壓縮及控制模塊、RTSP傳輸控制模塊三部分組成,流程框圖如圖2所示。
2.2 模塊設計
(1)音視頻采集及編碼模塊
采用MediaRecorder類,首先調用該類的setAudioSource和setVideoSource設置音視頻采集源,再通過該類的setAudioEncoder()和setVideoEncoder()設置音視頻的編碼方式。以h.264視頻編碼為例,調用該類中的SetoutputFile函數綁定LocalSocket實現。在編碼過程中可以使用硬編碼的方式,硬編碼是在預覽過程提前確定視頻的sps、pps、head(一般為0x00000001)。
(2)RTP/RTCP數據壓縮及控制模塊
RTP包傳送可以基于UDP或者TCP,采用TCP作為傳輸層協議注重可靠性而不是及時性,在RTP傳輸過程中應用很少,大部分RTP包發送都是采用UDP方式。在RTP會話過程前,發送方需要確定接收方的目標IP及接收端口。
(3)RTSP傳輸控制模塊
RTSP協議作為應用層協議,RTSP命令的傳輸是基于TCP協議,RTSP本身不作為數據傳輸的協議,而是作為一種流媒體傳輸過程的控制協議。
通過RTSP與服務器進行音視頻流媒體傳輸有兩種方式:拉模式和推模式。拉模式是主從模式,拉方(例如視頻播放客戶端)需要維護各個被拉方(例如攝像頭)的狀態,如url信息、端口信息等,只有拉方主動請求被拉方告知相應信息才能啟動。推模式主動權在推方(本文即為安卓移動設備端),從接方(本文即為Darwin服務器)來看,只要做好標準接口即可,無需關注有多少推方會推送數據。由于移動設備在3G網絡下,如果選擇拉模式,同一個網段下還需穿透NAT,即“打洞”,不方便做遠程音視頻傳輸,所以選擇推模式下的視頻傳輸。
3 Darwin服務器端設計
本系統中服務器端負責轉發和存儲音視頻數據,主要由RTSP連接建立模塊、視頻轉發模塊及視頻錄制模塊三部分構成。視頻播放客戶端發送RTSP請求,Darwin流媒體服務器通過Modules發送數據包來回復客戶,處理相應的RTSP請求。Darwin服務器作為流媒體客戶端的中繼代理,移動設備在RTSP協議中的ANNOUNCE命令攜帶.sdp文件到Darwin服務器接收sdp的目錄文件中。此后視頻播放客戶端就可以通過rtsp://<DSS IP>/***.sdp請求.sdp文件獲取到手機客戶端對應地址和端口的流。由于Darwin服務器本身不支持視頻錄制,故加入開源庫mp4v2實現視頻錄制,具體各模塊如下:
3.1 RTSP連接建立模塊
Darwin Streaming Server定義了RTSPListenerSocket Class,它繼承自TCPListenerSocket Class,用于對RTSP連接請求進行處理,進入RTSP狀態機。通過RTSPSession對象完成對請求類型的匹配,如果匹配成功,則注冊QTSS_RTSPPreProcessor_Role角色的模式。在這個角色模式下,進入QTSSReflectorModule類處理了每種RTSP消息,比如本次RTSP請求的Describe、Setup、Play指令。該類中針對各種請求指令都有對應的單獨函數處理,分別對應著DoAnnounce、DoDescribe、DoSetup和DoPlay函數。除此之外,RTSP狀態機的終結點所在位置也是在QTSSReflectorModule類中,通過Shutdown()函數實現RTSP會話的結束。
3.2 視頻轉發建立模塊
當收到一路RTSP連接請求時,在DSS中為RTSPSession類對象,首先需要解析請求頭部是否為轉發請求,進而解析其請求的后續部分。進行查詢字符串的解析,得到需要轉發的具體url,建立一路面向url源的會話,通過Describe命令獲取到sdp信息進行保存,再轉發到請求Describe的客戶端,而且Setup、Play分別將對應的響應碼返回給客戶端,在轉發具體的數據時,建立一路ReflectorSession,將獲取到的rtp數據轉發到添加進ReflectorSession轉發列表的客戶端中。
3.3 視頻錄制模塊
要實現視頻錄制,首先需要找到音視頻RTP數據包,然后將編碼過后的H264視頻和AAC音頻數據從RTP包中按續提取出來,并以MP4文件格式封裝,最后存成文件。在Darwin服務器中的ProcessRTPData()函數內部處理處理接收到的RTP包,提取char* packetData數據傳遞到MP4文件生成函數中。具體通過創建MP4文件句柄、設置時間標度、添加h264視頻軌道及aac音頻軌道[10]、添加序列參數集和圖像參數集,最后再寫入文件的方式生成MP4文件。具體視頻存儲步驟如下:
(1)通過MP4Create創建MP4文件句柄。
(2)通過MP4SetTimeScale設置時間標度,即每秒的時鐘ticks數。
(3)通過MP4AddH264VideoTrack添加h264視頻track,MP4AddAudioTrack添加aac音頻track。
(4)通過MP4AddH264SequenceParameterSet和MP4AddH264PictureParameterSet添加序列參數集和圖像參數集。
(5)通過MP4WriteSample寫一幀視頻數據或寫一段音頻數據。
其中duration這個參數是用來實現音視頻同步用的,如果設置錯了會造成音視頻不同步,甚至會出現crash現象。對于視頻流MP4WriteSample函數,每次調用是錄制前一幀數據,用當前幀的時間戳和前一幀的時間戳計算duration值,然后把當前幀保存下來在下次調用MP4WriteSample時用,寫音頻數據一樣。
(6)通過MP4Close關閉打開的MP4文件。
4 B/S架構及C/S架構客戶端設計
4.1 C/S架構客戶端原理
C/S架構的播放客戶端通過支持RTSP的開源live555構建與手機移動客戶端的RTSP通信,通過開源編解碼框架ffmpeg的解碼功能進行解碼。
通過live555構建RTSP的過程為:首先創建BasicTaskScheduler和BasicUsageEnvironment對象,用于調度不同事件。創建RTSPClient對象,由RTSPClient對象向服務器發送RTSP中的OPTION消息命令并等待接受回應,返回SDPDescription字符串即sdp文件內容。在任務調度while循環中配置所有子會話對象,為每個子會話創建RTPSource和RTCPInstance對象,并創建兩個GroupSock對象。將每個GroupSock對象中創建的socket描述符置入 BasicTaskScheduler::fReadSet中,RTPSource對象的創建的依據是SDPDescription。由RTSPClient對象向服務器發送SETUP消息并接受回應,while循環中為每個子會話創建接收器FileSink對象,由RTSPClient對象向服務器發送PLAY消息并接受回應,FileSink的緩沖區和包含寫入文件操作的一個函數指針配置給RTPSource對象,這個緩沖區將會在networkReadHandler中接收來自網絡的視音頻數據。
獲取到音視頻數據后,通過ffmpeg[11]的解碼功能進行解碼處理,流程如圖3所示。
avformat_open_input函數對輸入的文件名進行解析,并發起與Darwin服務器的RTSP交互。在數據讀取線程中,使用rtsp_read_packet函數用于每個RTP包的讀取和第一次排序解析。首先調用rtp_read函數從緩沖區獲取數據,然后通過包隊列交給RTP解析函數rtp_parse_packet進行第一次解析。第一次解析的目的是對包進行重新排序,解決因為網絡抖動導致接收到的包序列號不連續的問題。具體是根據RTP協議解析RTP包頭信息,對RTP包頭的包序列號按遞增順序重新排序。然后調用av_parser_parse2函數對RTP包進行第二次重組幀解析,目的是將包中的數據重新按幀進行組合,組成一幀數據的avpacket。
4.2 B/S架構的實現
B/S架構的服務器端采用Apache服務器,Web客戶端采用HTML5的技術直接播放緩存在Darwin服務器下的MP4[12]視頻。Web客戶端通過訪問Darwin服務器下錄制視頻存放的文件夾,獲取mp4后綴的文件名,輸出到Web客戶端播放列表中。Web客戶端實現圖片保存及視頻大小控制等功能。注冊VLC的ActiveX[13]嵌入到網頁中,實現直播功能。B/S架構播放客戶端如圖4所示。
5 測試及分析
根據上述設計,客戶端采用B/S架構的Web客戶端及C/S架構的PC客戶端均可正常觀看直播視頻,通過mp4v2可實現視頻存儲功能。本系統服務器使用中國電信100M光纖網絡,用60個B/S架構及C/S架構客戶端分3組同時請求3路手機推送視頻。3路手機視頻端碼率均設為為500 kb/s,視頻采集分辨率分別為320×240、640×480、720×1 280,并在720p分辨率的條件下分3次在中國聯通3G網絡、中國電信3G網絡及無線WiFi網絡下分別統計手機移動客戶端的視頻播放延遲時間。其中服務器所用的硬件環境為:中央處理器:Inter Core I5-2 450 M 2.5 GHz雙核四線程;內存:4 GB DDR3 1 333 MHz;硬盤:5 400 rad/min;操作系統:32位 Windows7 操作系統。
播放客戶端通過RTSP請求觀看直播,請求如:rtsp:// 202.193.53.103/teststream.sdp,由sdp文件名區分不同推送視頻源。表1統計了在中國聯通3G網絡、中國電信3G網絡及無線WiFi網絡下分別統計手機移動客戶端的視頻播放延遲時間。
通過60個客戶端同時請求服務器連接,表明服務器在帶寬為100M光纖網絡的條件下,可以同時滿足60個用戶同時請求連接。客戶端同時請求的數量由服務器網絡帶寬決定。通過分別在中國聯通3G網絡、中國電信3G網絡及無線WiFi網絡下推送視頻的播放延遲區別表明,系統整體滿足不同網絡條件下的需求,具有較好的實時性。
6 結束語
本文通過移動設備客戶端、服務器端、視頻播放客戶端組成的系統架構闡述了一個新的視頻直播、錄制及多平臺播放的解決方案。詳細討論了移動設備客戶端音視頻采集及傳輸方案、服務器端的轉發及存儲方案,以及視頻播放客戶端的兩種架構,分析了基于live555的RTSP通信過程及基于mp4v2的視頻存儲過程,開發出了整套直播、點播系統。同時,設計了相應的測試實驗,為實現高可靠、高實時性的視頻直播系統提供了一種較為可行的方法。
參考文獻
[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的手機直播系統[J].計算機工程與設計,2014,35(9):3173-3178.
[4] 姜浩然,徐林.基于RTMP的流媒體服務器的研究[J].計算機與數字工程,2011,39(10):104-108.
[5] 史紅周,黃晁.一種基于MP4文件的視頻流關鍵幀索引播放方法[J].微電子學與計算機,2002,19(7):44-47.
[6] 李新樂,蘇鴻根.流媒體搜索和發布技術在移動設備上的應用[J].計算機工程與設計,2009,30(6):1428-1431.
[7] 茅炎菲,黃忠東.基于RTSP協議網絡監控系統的研究與實現[J].計算機工程與設計,2011,32(7):2523-2526.
[8] 羅大暉,陳娟.基于HTML5的Web離線應用研究與實現[J].計算機應用與軟件,2012,29(12):262-264.
[9] 李校林,劉海波,張杰,等.RTP/RTCP,RTSP在無線視頻監控系統的設計與實現[J].電視技術,2011,35(19):89-92.
[10] 韋崇嶺,裴海龍.基于無人機平臺H264視頻傳輸系統的設計與實現[J].計算機測量與控制,2012,20(1):209-211.
[11] 劉麗霞,邊金松,張琍,等.基于FFMPEG解碼的音視頻同步實現[J].計算機工程與設計,2013,34(6):2087-2092.
[12] 李興華,楊天奇.MP4共享FLV數據研究與實現[J].微型機與應用,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.