1、-目錄摘要I關(guān)鍵詞IAbstractIKey wordsI1 系統(tǒng)的可行性研究概述11.1 系統(tǒng)研究的意義11.2 系統(tǒng)研究的目的11.3 國外研究現(xiàn)狀11.4 課題研究容22 主要技術(shù)分析與簡(jiǎn)介22.1 DSS分析22.1.1 DSS概要及主體框架22.1.2 核心流媒體框架32.1.3 DSS效勞器調(diào)用模塊的主要流程42.2 開發(fā)平臺(tái)的軟件介紹42.3 TS流簡(jiǎn)介52.4 流媒體系統(tǒng)構(gòu)造圖52.5 H.264編解碼規(guī)62.6 Darwin支持的兩種視頻轉(zhuǎn)發(fā)模式72.6.1 先拉后推72.6.2 先偵聽后推送72.7 流媒體技術(shù)概述83 攝像機(jī)推送器的設(shè)計(jì)與實(shí)現(xiàn)83.1 攝像機(jī)主要模塊83.

2、2 攝像機(jī)各模塊的設(shè)計(jì)與實(shí)現(xiàn)93.2.1 語音對(duì)講模塊的設(shè)計(jì)與實(shí)現(xiàn)93.2.2 參數(shù)配置模塊的設(shè)計(jì)與實(shí)現(xiàn)103.2.3 報(bào)警模塊的設(shè)計(jì)與實(shí)現(xiàn)113.2.4 實(shí)時(shí)數(shù)據(jù)流模塊的設(shè)計(jì)與實(shí)現(xiàn)113.2.5 云臺(tái)控制模塊的設(shè)計(jì)與實(shí)現(xiàn)123.3 模塊的加載過程133.3.1 采集模塊143.3.2 推送模塊143.4 推送模塊的設(shè)計(jì)與實(shí)現(xiàn)細(xì)節(jié)153.5 RTSP請(qǐng)求的處理153.6 EasyPusher函數(shù)153.7 攝像機(jī)配置163.8 推送音視頻數(shù)據(jù)的緩存設(shè)計(jì)174 系統(tǒng)測(cè)試184.1 測(cè)試方法184.2 TS推送測(cè)試184.3 攝像機(jī)功能測(cè)試205 總結(jié)22參考文獻(xiàn)23致24. z-摘 要本課題是基

3、于蘋果公司的Darwin Streaming Server，這是蘋果公司的一個(gè)開源工程，對(duì)它做一些功能擴(kuò)展，以滿足系統(tǒng)的需求。首先我們對(duì)DSS的源代碼進(jìn)展了分析，然后著手將TS流推送模塊添加到這個(gè)系統(tǒng)中?？紤]到RTP/RTCP協(xié)議相比較與UDP協(xié)議對(duì)效勞器的壓力，最后決定使用UDP協(xié)議，并且系統(tǒng)支持了H.264 TS流。本課題最后測(cè)試的效果表現(xiàn)出畫面清晰、無卡頓、無馬賽克等優(yōu)點(diǎn)，并且實(shí)現(xiàn)了對(duì)MPEG-2和H.264的支持。并且因?yàn)楸菊n題嚴(yán)格的按照了TS流的理想碼率進(jìn)展推送，所以誤差非常小，平均在5毫秒下，并且不會(huì)隨系統(tǒng)工作時(shí)間增加而增長(zhǎng)。而且，本課題設(shè)計(jì)的攝像機(jī)客戶端推送器是徹底符合ISMA標(biāo)

4、準(zhǔn)的，所以它也使用于所有基于IP網(wǎng)絡(luò)的環(huán)境，接收終端可以是DVB、IP和PC。所以本系統(tǒng)對(duì)DSS進(jìn)展擴(kuò)展后，是具有多適應(yīng)性的。關(guān)鍵詞達(dá)爾文流媒體效勞器；TS流；推送器；攝像機(jī)；AbstractThe project is based on Apple's Darwin Streaming Server, which is an open source project of Apple. We will do some functional e*pansion to meet the needs of the system. First of all we have the DSS so

5、urce code analysis, and then proceed to add TS stream Module to this system. Taking into account the pressure made by RTP / RTCP protocol and the UDP protocol, we finally decided to use the UDP protocol, and the system supports the H.264 TS stream.The results of the final test of this subject show t

6、he advantages of clear picture, no standstill, no mosaic and so on, and realize the support of MPEG-2 and H.264. Because the subject is push in accordance with the TS stream ideal rate, so the error is very small, with an average of 5 milliseconds, and will not increase with the system working hours

7、. At the same time, the camera system design of the push function is fully in line with the ISMA standard, so it is also used in all IP-based network environment. Its receiving terminal can be DVB STB, IP STB and PC. So after the e*pansion of DSS, the system is more adaptable.Key wordsDarwin Streami

8、ng Server;TS Streaming;Pusher;Camera;. z-1 系統(tǒng)的可行性研究概述1.1系統(tǒng)研究的意義隨著互聯(lián)網(wǎng)越來越多的應(yīng)用于現(xiàn)代人的生活當(dāng)中，音視頻通過網(wǎng)絡(luò)傳輸?shù)那闆r也越來越多，導(dǎo)致傳輸量也越來越大。現(xiàn)在很多的互聯(lián)網(wǎng)公司都希望通過互聯(lián)網(wǎng)流媒體技術(shù)推送給用戶來獲取更多的用戶量。但是音視頻數(shù)據(jù)的數(shù)據(jù)量是很大的，如果要下載下來會(huì)消耗很大的網(wǎng)絡(luò)帶寬和流量。目前網(wǎng)絡(luò)帶寬平均情況下還不算很大，在這種情況下，流媒體技術(shù)的出現(xiàn)就讓這種情況有了很大的改善。現(xiàn)在網(wǎng)絡(luò)的帶寬雖然越來越大，但是對(duì)于日益增加的音視頻傳輸量，顯然還需要更為優(yōu)秀的流媒體技術(shù)進(jìn)展傳輸。由于流媒體技術(shù)為互聯(lián)網(wǎng)傳統(tǒng)的媒

9、體播放上帶來了更多的時(shí)機(jī)現(xiàn)在網(wǎng)絡(luò)用戶對(duì)媒體的需求越來越大，用戶也更喜歡在網(wǎng)絡(luò)上選擇自己需要的音視頻。過去，傳統(tǒng)媒體更多的是使用“推式傳播，而流媒體技術(shù)將其變?yōu)椤袄絺鞑?，而受眾也不再是只被?dòng)的接收播送電視等節(jié)目，而是通過網(wǎng)絡(luò)尋找自己需要的容，隨時(shí)隨地的就可以播放。這將在一定程度上提高了用戶的選擇空間，使他們?cè)诟鞣N媒體云集的今天占據(jù)著主動(dòng)，也由于這種變化的產(chǎn)生導(dǎo)致媒體行業(yè)積極的改變來迎合用戶的需求。本系統(tǒng)做的就是關(guān)于基于Apple Darwin流媒體效勞器的一整套效勞，而本課題負(fù)責(zé)的局部就是攝像機(jī)客戶端推送器。1.2系統(tǒng)研究的目的本課題是基于攝像機(jī)方案商提供的SDK根底上，在Windows平臺(tái)上

10、與攝像機(jī)的主效勞進(jìn)展交互，功能包括實(shí)時(shí)視頻、語音對(duì)講、云臺(tái)控制等功能，攝像機(jī)客戶端推送器一邊通過SDK和攝像機(jī)的主進(jìn)程進(jìn)展交互獲取音視頻數(shù)據(jù)，控制云臺(tái)，聯(lián)動(dòng)報(bào)警等交互，一邊和Darwin效勞器、CMS效勞器和RMS效勞器進(jìn)展對(duì)接，上傳數(shù)據(jù)、承受指令的控制，形成一整套的音視頻攝像機(jī)方案，為了能夠適用于更多的不同的場(chǎng)景和設(shè)備，在本系統(tǒng)中添加了RTSPClient模塊，可以設(shè)置為通過RTSP協(xié)議推送H.264視頻流到流媒體效勞器。整個(gè)系統(tǒng)可以應(yīng)用于生活中的方方面面，包括了遠(yuǎn)程監(jiān)控、視頻直播、網(wǎng)上點(diǎn)播、遠(yuǎn)程教育等等。從現(xiàn)在互聯(lián)網(wǎng)行業(yè)的趨勢(shì)來看，音視頻業(yè)務(wù)以及流媒體效勞肯定會(huì)越來越重要。所以本課題的研究

11、不管在生活中，還是在技術(shù)層面上，都是很有意義和價(jià)值的。1.3 國外研究現(xiàn)狀目前有一些廠商已經(jīng)擁有基于IPQAM的VOD業(yè)務(wù)的解決方案，國有SiHua和華為，國外有Motorola、挪威泰德、Cisco等。然而SiHua的產(chǎn)品即便不是基于ISA規(guī)，但是則昂貴的價(jià)格還是國企業(yè)所不能承受的。Video Sever是VOD系統(tǒng)的核心局部，并且使用UDP協(xié)議傳送TS流。為了降低系統(tǒng)的本錢，首先應(yīng)該考慮如何降低Video Sever的開發(fā)本錢。因而，本文通過擴(kuò)展DSS的功能，使其支持TS流推送功能，以滿足一些小型運(yùn)營(yíng)商的需求。網(wǎng)絡(luò)監(jiān)控系統(tǒng)已經(jīng)滲透到日常生活中的各個(gè)行業(yè)：在商場(chǎng)超市里，視頻監(jiān)控系統(tǒng)可以對(duì)顧客

12、以及市場(chǎng)實(shí)時(shí)場(chǎng)景進(jìn)展監(jiān)控。通信運(yùn)營(yíng)商可以利用網(wǎng)絡(luò)監(jiān)控系統(tǒng)對(duì)位置偏僻的通信基站進(jìn)展監(jiān)控。城市道路公交系統(tǒng)中，監(jiān)控系統(tǒng)實(shí)時(shí)獲取路況車流信息，便于交管部門交通流量調(diào)度。此類系統(tǒng)的最新應(yīng)用模式是，幼兒園里面安裝了這一類的系統(tǒng)以后，家長(zhǎng)就能夠?qū)處煹慕逃闆r和孩子的情況進(jìn)展隨時(shí)的了解。總的來說，在各行各業(yè)中網(wǎng)絡(luò)監(jiān)控系統(tǒng)都得到了非常廣泛的應(yīng)用。網(wǎng)絡(luò)實(shí)時(shí)視頻系統(tǒng)主要是使用網(wǎng)絡(luò)來把不同地點(diǎn)的，甚至相隔了數(shù)千里的一些圖像采集點(diǎn)和采集圖像的播放終端之間形成一種互聯(lián)的多對(duì)多關(guān)系，同時(shí)在這樣的根底之上提供了一個(gè)開發(fā)平臺(tái)，專門用于對(duì)視頻音頻擴(kuò)展應(yīng)用進(jìn)展開發(fā)。而網(wǎng)絡(luò)實(shí)時(shí)視頻監(jiān)控系統(tǒng)則屬于一種全新的互聯(lián)網(wǎng)應(yīng)用型系統(tǒng)，這種系

13、統(tǒng)融合了非常多的新型信息技術(shù)，包括了互聯(lián)網(wǎng)傳輸應(yīng)用技術(shù)、音視頻數(shù)據(jù)采集和編解碼、流媒體應(yīng)用技術(shù)等等。網(wǎng)絡(luò)實(shí)時(shí)視頻監(jiān)控系統(tǒng)的特點(diǎn)主要有三點(diǎn)，第一是網(wǎng)絡(luò)監(jiān)控，因?yàn)榛ヂ?lián)網(wǎng)絡(luò)的連通性，系統(tǒng)監(jiān)控硬件設(shè)備的布設(shè)不再受到彼此物理位置的局限。網(wǎng)絡(luò)監(jiān)控打破了原本監(jiān)控系統(tǒng)對(duì)接入設(shè)備數(shù)量方面的限制和對(duì)距離方面的限制，對(duì)相關(guān)的網(wǎng)絡(luò)資源進(jìn)展了最大程度的利用。第二是數(shù)字化信息，目前音視頻所采集得到的數(shù)據(jù)使用的是數(shù)字信號(hào)，目前已經(jīng)出現(xiàn)了性能非常高的音視頻編解碼技術(shù)，因此對(duì)于數(shù)據(jù)的傳輸來說，其效率有了明顯的提升，這一技術(shù)可以確保那些低帶寬的播放終端同樣能夠得到非常好的采集圖像。第三是支持無線網(wǎng)絡(luò)，目前無線網(wǎng)技術(shù)開展的速度很快

14、，而且無線網(wǎng)相關(guān)應(yīng)用也得到了普及，新一代互聯(lián)網(wǎng)的開展已經(jīng)開場(chǎng)轉(zhuǎn)向了移動(dòng)互聯(lián)網(wǎng)，這個(gè)時(shí)候，手機(jī)就變成了移動(dòng)播放終端。這種移動(dòng)播放終端的實(shí)時(shí)性非常好，同時(shí)能夠支持流媒體視頻數(shù)據(jù)，也就是說其圖像播放效果可以和計(jì)算機(jī)相比，并且能夠隨時(shí)隨地對(duì)監(jiān)控區(qū)域所采集到的圖像進(jìn)展實(shí)時(shí)地獲取。1.4 課題研究容本課題并不是要做攝像機(jī)的硬件方案，或者說本課題是與硬件芯片無關(guān)的一套對(duì)于云平臺(tái)對(duì)接方案，本系統(tǒng)在攝像機(jī)方案商提供的功能接口的根底上，通過攝像機(jī)提供的SDK，在攝像機(jī)ARM系統(tǒng)部和攝像機(jī)的主效勞進(jìn)展交互，包括了攝像機(jī)提供的實(shí)時(shí)音視頻、聯(lián)動(dòng)報(bào)警、云臺(tái)控制等功能，Darwin開源流媒體解決方案整體采用的是行業(yè)通用的R

15、TSP、RTP、RTCP、HTTP、RTMP、RESTful協(xié)議和標(biāo)準(zhǔn)，對(duì)于開發(fā)者和企業(yè)來說，通用性和可讀性都極強(qiáng)。能夠廣泛的用于安防監(jiān)控、智能家居、教育直播、幼兒園直播等工程，尤其是在安防行業(yè)結(jié)合移勱互聯(lián)網(wǎng)方面，Darwin開源流媒體解決方案提供了非常完善的實(shí)現(xiàn)方案。我們?cè)跀z像機(jī)的部植入程序，攝像機(jī)客戶端推送器一邊通過SDK和攝像機(jī)的主進(jìn)程進(jìn)展交互獲取音視頻數(shù)據(jù)，控制云臺(tái)，聯(lián)動(dòng)報(bào)警等交互，一邊和Darwin效勞器、CMS效勞器和RMS效勞器進(jìn)展對(duì)接，上傳數(shù)據(jù)、承受指令的控制，形成一整套的視頻攝像機(jī)方案。2主要技術(shù)分析與簡(jiǎn)介2.1DSS分析DSS概要及主體框架Darwin Streaming

16、Server是蘋果公司的一個(gè)開源實(shí)時(shí)流媒體效勞器程序。整個(gè)系統(tǒng)由C+開發(fā)，在設(shè)計(jì)上它遵循高效的性能、簡(jiǎn)單的設(shè)計(jì)、模塊化開發(fā)等設(shè)計(jì)原則，要求程序做到高效的同時(shí)，可擴(kuò)大性也要很好。并且DSS是一個(gè)開發(fā)源代碼的流媒體效勞器，可以在Windows，UNI*，MAC OS *，Linu*，F(xiàn)ree BSD，Solaris等操作系統(tǒng)上運(yùn)行。DSS的核心效勞器的局部是由一個(gè)父進(jìn)程和一個(gè)子進(jìn)程構(gòu)成，這個(gè)子進(jìn)程是由父進(jìn)程fork構(gòu)成的，該父進(jìn)程就成為了整合的流媒體效勞器。在運(yùn)行時(shí)，主要由子進(jìn)程完成，如果在子進(jìn)程運(yùn)行期間產(chǎn)生了錯(cuò)誤就會(huì)退出該進(jìn)程，并且fork出一個(gè)新的子進(jìn)程。網(wǎng)絡(luò)客戶和效勞器的對(duì)接是靠Darwin

17、效勞器來直接對(duì)接的。通過RTSP over RTP來發(fā)送或者承受請(qǐng)求。接收到請(qǐng)求后效勞器就通過相應(yīng)的模塊來處理這個(gè)請(qǐng)求并且向客戶端發(fā)送數(shù)據(jù)流。核心流媒體效勞器是由四種不同類型的線程來處理事務(wù)的，每個(gè)線程的類型具體如下：效勞器主線程，當(dāng)效勞器處理在關(guān)閉檢查以及在檢查之前需要記錄相關(guān)狀態(tài)打印和統(tǒng)計(jì)相關(guān)信息等任務(wù)時(shí)，就由這個(gè)線程來處理。事件線程，對(duì)接口以及和接口相關(guān)的事件都是由這個(gè)線程監(jiān)聽的，當(dāng)有RTSP請(qǐng)求或者RPT數(shù)據(jù)包請(qǐng)求時(shí)，事件線程就會(huì)把這些任務(wù)就給任務(wù)線程來處理。任務(wù)線程，任務(wù)線程在事件線程處理事務(wù)時(shí)會(huì)把事件從事件線程中取出來，并把事件傳遞到需要處理的相應(yīng)的效勞器模塊進(jìn)展處理，在一般情況下

18、，每一個(gè)處理器核都會(huì)有一個(gè)任務(wù)線程由核心效勞器創(chuàng)立?？臻e任務(wù)線程，空閑任務(wù)線程，該線程負(fù)責(zé)對(duì)一個(gè)周期的任務(wù)隊(duì)列進(jìn)展管理，主要有兩種任務(wù)管理，超時(shí)任務(wù)和Socket任務(wù)。如圖2-1效勞器架構(gòu)所示。圖2-1效勞器架構(gòu)2.1.2核心流媒體框架如圖2-2核心流媒體框架，首先由客戶端發(fā)起視頻請(qǐng)求到接入效勞器，效勞器處理完畢請(qǐng)求之后發(fā)送將請(qǐng)求發(fā)送到前端設(shè)備，前端設(shè)備收到請(qǐng)求后進(jìn)展響應(yīng)，接入效勞器收到設(shè)備響應(yīng)后向分發(fā)效勞器發(fā)送視頻通知，同時(shí)前端設(shè)備向分發(fā)效勞器發(fā)送數(shù)據(jù)流推送請(qǐng)求，分發(fā)效勞器收到前端請(qǐng)求后給前端設(shè)備與接入效勞器響應(yīng)，前端設(shè)備收到分發(fā)效勞器的響應(yīng)后向分發(fā)效勞器推送RTP數(shù)據(jù)流，同時(shí)接入效勞器收到

19、分發(fā)效勞器的響應(yīng)后給客戶端發(fā)送響應(yīng)信息并進(jìn)展重定向操作。分發(fā)效勞器向客戶端發(fā)送RTSP視頻請(qǐng)求，客戶端響應(yīng)RTSP視頻請(qǐng)求，分發(fā)效勞器向客戶端推送實(shí)時(shí)視頻流。圖2-2DSS核心流媒體框架DSS效勞器調(diào)用模塊的主要流程在DSS中的模塊分為兩種，一種是動(dòng)態(tài)模塊，一種是靜態(tài)模塊。動(dòng)態(tài)模塊在效勞器啟動(dòng)伊始就會(huì)加載，而靜態(tài)模塊在這之后才會(huì)加載。所以建議將寫好的功能模塊全部編譯為動(dòng)態(tài)模塊來替換以及擴(kuò)展DSS原有的效勞器模塊，則我們自己的功能模塊就會(huì)首先被加載。Register是每個(gè)模塊中必須支持的一個(gè)角色，效勞器會(huì)在每個(gè)模塊被裝載后，就調(diào)用這些模塊的Register角色。Register角色的主要工作就是

20、初始化，例如對(duì)數(shù)據(jù)構(gòu)造的初始化和存分配的初始化等。它會(huì)調(diào)用QTSS Add Role來記錄這個(gè)模塊支持的其他角色，之后效勞器就會(huì)初始化角色并且調(diào)用每個(gè)擁有這個(gè)角色的模塊。在關(guān)閉效勞器時(shí)，Shutdown角色就會(huì)被各個(gè)模塊調(diào)用，然后這些模塊就會(huì)釋放存完成完畢工作的處理。通過這些角色流媒體效勞器就可以完成它的任務(wù)了。圖2-3效勞器啟動(dòng)和關(guān)閉的流程顯示的是效勞器在啟動(dòng)和關(guān)閉的時(shí)候如何和Register登記，Initialize初始化，和Shutdown關(guān)閉這些角色協(xié)同工作的。圖2-3 效勞器啟動(dòng)和關(guān)閉流程2.2 開發(fā)平臺(tái)的軟件介紹DSS是支持多個(gè)操作系統(tǒng)的。其中包括Windows，而且Darwin流

21、媒體效勞器源代碼完全采用標(biāo)準(zhǔn)的C+語言寫成，所以本課題采用的開發(fā)平臺(tái)軟件是在Windows平臺(tái)上的Microsoft Visual Studio 2021 。Visual Studio是一套基于組件的軟件開發(fā)工具和其他技術(shù)，可用于構(gòu)建功能強(qiáng)大、性能出眾的應(yīng)用程序。并且它繼承了對(duì)構(gòu)建跨設(shè)備應(yīng)用的支持，以及用于跨平臺(tái)開發(fā)的功能。所以本課題使用它作為開發(fā)工具是十分適宜的。由于Darwin采用標(biāo)準(zhǔn)C+語言來完成，所以它的編程風(fēng)格是十分優(yōu)秀的，它的每以個(gè)C+類都對(duì)應(yīng)一對(duì)和類同名的.h和.cpp文件。但是也因?yàn)樗罅康牟捎昧嗣嫦驅(qū)ο蟮母拍?，其中繼承，多態(tài)等，因此它的代碼復(fù)雜性還是很高的。圖2-4就是開發(fā)環(huán)

22、境界面。圖2-4 開發(fā)環(huán)境界面2.3 TS流簡(jiǎn)介TS一般我們認(rèn)為是MPEG-2 TS標(biāo)準(zhǔn)，它是一種非常成熟的數(shù)據(jù)傳輸技術(shù)，它是對(duì)音視頻數(shù)據(jù)復(fù)用的一種說明，音視頻數(shù)據(jù)經(jīng)過TS封裝之后，再通過網(wǎng)絡(luò)IP協(xié)議棧進(jìn)展二次封裝，然后就可以傳輸了。但如果需要進(jìn)展一些互動(dòng)性的容，就需要對(duì)它進(jìn)展擴(kuò)展。這種傳輸方式同樣采用了C/S的方式，另外由于應(yīng)用在IPTV領(lǐng)域，控制層可以使用RTSP協(xié)議或者HTTP協(xié)議。在DSS效勞器中，為了減少網(wǎng)絡(luò)抖動(dòng)更好地控制傳輸流量，我們對(duì)UDP協(xié)議數(shù)據(jù)包又增加了關(guān)于RTP協(xié)議數(shù)據(jù)封裝。這樣系統(tǒng)就能夠有效的減少網(wǎng)絡(luò)丟包，視頻卡頓等影響客戶體驗(yàn)的現(xiàn)象。TS over IP的傳輸過程如圖2

23、-5所示。圖2-5TS over IP的傳輸過程2.4 流媒體系統(tǒng)構(gòu)造圖Darwin開源流媒體解決方案可分為流媒體數(shù)據(jù)流、信令控制流兩大局部，接入管理接口效勞器CMS、流媒體效勞器Darwin、存儲(chǔ)不回放效勞器RMS可直接運(yùn)行在阿里云主機(jī)ECS上，CMS效勞器負(fù)責(zé)進(jìn)展設(shè)備和客戶端的接入不管理，Darwin效勞器負(fù)責(zé)進(jìn)展流媒體音視頻的分發(fā)和HLS切片，RMS效勞器負(fù)責(zé)對(duì)直播流進(jìn)展實(shí)時(shí)存儲(chǔ)和錄像檢索，還有其他功能模塊。CMS效勞器設(shè)備管理與接入效勞器，Darwin流媒體效勞器，RMS錄像存儲(chǔ)效勞器，都能夠分布式、平行部署、無限擴(kuò)容，云端各個(gè)節(jié)點(diǎn)的效勞單元都將負(fù)載信息寫到共享的Redis中進(jìn)展數(shù)據(jù)共

24、享，CMS將在線設(shè)備相關(guān)信息寫入到Redis，Darwin效勞器將負(fù)載信息和流媒體直播相關(guān)信息寫入Redis，這樣在多個(gè)CMS效勞器、Darwin效勞器之間就可以進(jìn)展直播級(jí)聯(lián)，Session共享，Token驗(yàn)證等功能。本課題負(fù)責(zé)的Camera攝像機(jī)硬件啟動(dòng)后，啟動(dòng)Camera進(jìn)程。Camera向CMS效勞器發(fā)送注冊(cè)報(bào)文，并定期發(fā)送報(bào)活報(bào)文，維持?jǐn)z像機(jī)與CMS效勞器的TCP連接。CMS效勞器會(huì)對(duì)Camera發(fā)送注冊(cè)報(bào)文進(jìn)展權(quán)限驗(yàn)證，通過驗(yàn)證后的設(shè)備信息寫入Redis中，也會(huì)將CMS效勞器的信息一起寫入。Client向CMS效勞器請(qǐng)求直播視頻流，CMS效勞器會(huì)在Redis中查找設(shè)備是否在線，第二步

25、會(huì)查找該設(shè)備是否存在流媒體轉(zhuǎn)發(fā)消息。如果存在，則直接將改直播流信息響應(yīng)給Client，如果不存在，CMS效勞器需要向Camera發(fā)送啟動(dòng)直播流推送的命令，CMS效勞器再將Camera反響的結(jié)果響應(yīng)給Client，Client根據(jù)收到的結(jié)果進(jìn)展播放。如圖2-6流媒體系統(tǒng)構(gòu)造圖。圖2-6流媒體系統(tǒng)構(gòu)造圖2.5H.264編解碼規(guī)正是由于標(biāo)準(zhǔn)化的視頻壓縮技術(shù)的出現(xiàn)使得圖像技術(shù)得到了更為廣泛的應(yīng)用，例如DVD視頻和數(shù)字電視徹底改變了家庭娛樂以及播送電視的傳統(tǒng)模式。圖像視頻在互聯(lián)網(wǎng)中的應(yīng)用與MPEG標(biāo)準(zhǔn)中的MPEG-4有密不可分的聯(lián)系，ITU-T H.263標(biāo)準(zhǔn)是當(dāng)前大多數(shù)視頻會(huì)議使用的視頻壓縮標(biāo)準(zhǔn)。MP

26、EG-4視覺標(biāo)準(zhǔn)和H.263標(biāo)準(zhǔn)是在1995年開場(chǎng)制定的，視頻編碼以及視頻壓縮技術(shù)是這兩種標(biāo)準(zhǔn)建立的技術(shù)根底，對(duì)此類標(biāo)準(zhǔn)進(jìn)展負(fù)責(zé)的是電影專家集團(tuán)以及視頻編碼專家組。在這兩種標(biāo)準(zhǔn)的開發(fā)進(jìn)展到后期的時(shí)候，出現(xiàn)了一套更加優(yōu)秀的新的標(biāo)準(zhǔn)，也就是H.264高級(jí)視頻編碼標(biāo)準(zhǔn)，這套標(biāo)準(zhǔn)所提供的圖像視頻壓縮效果更加優(yōu)秀，同時(shí)其在保證比特率非常低的同時(shí)還保證了高品質(zhì)。H.264編解碼協(xié)議規(guī)可以用四個(gè)方面概括其技術(shù)特點(diǎn)，第一個(gè)方面是關(guān)注實(shí)用性問題，摒棄了原本這類編解碼技術(shù)里面的一些存在著缺陷的編碼方案，如機(jī)遇容的編碼等，以更加簡(jiǎn)潔的格式，以提升編碼效率為目的，從而運(yùn)用適宜的技術(shù)。第二方面則是使用了多種的新算法和新

27、技術(shù)，在混合編碼的根底上，新增了4*4整數(shù)變換技術(shù)、基于容的變長(zhǎng)編碼技術(shù)及多幀預(yù)測(cè)和幀預(yù)測(cè)技術(shù)等。第三方面，對(duì)于算法而言，突出了信道的特點(diǎn)。從分層的角度來看，信道編碼和信源編碼在形式上采取了別離。第四方面則是使用了針對(duì)IP以及無線網(wǎng)絡(luò)的相關(guān)策略，為了方便那些經(jīng)過壓縮之后的視頻在丟包率較高和誤碼率較高的網(wǎng)絡(luò)環(huán)境之中進(jìn)展傳輸，使用了一些用來對(duì)過失進(jìn)展消除的工具。所具有的主要優(yōu)點(diǎn)如下：圖像質(zhì)量非常高。H.264標(biāo)準(zhǔn)想要實(shí)現(xiàn)的是在對(duì)圖像進(jìn)展復(fù)原的過程之中能夠保持較高質(zhì)量，同時(shí)還為此采用了一系列的算法，其目的為實(shí)現(xiàn)圖像的高質(zhì)量；為了能夠和不同的信道相適應(yīng)，以及各種應(yīng)用形式，區(qū)分各種圖像層次從而采用相應(yīng)的

28、算法；在熵編碼等步驟中，為到達(dá)較低比特率的目標(biāo)從而采用節(jié)約碼流的算法；系統(tǒng)的強(qiáng)健性增加，H.264提供了掩蓋錯(cuò)誤的組件并應(yīng)用了環(huán)路濾波構(gòu)造。2.6 Darwin支持的兩種視頻轉(zhuǎn)發(fā)模式Darwin支持兩種自動(dòng)播送的場(chǎng)景：先拉后推。為了發(fā)起自動(dòng)播送，RTSP客戶會(huì)發(fā)送標(biāo)準(zhǔn)的RTSP請(qǐng)求來向效勞器請(qǐng)求一個(gè)流，然后效勞器將該流中繼到一個(gè)或者多個(gè)流媒體效勞器。這種場(chǎng)景在“先拉后推局部中加以描述。先偵聽后推送。在這個(gè)場(chǎng)景中，自動(dòng)播送在流媒體效勞器接收到ANNOUNCE請(qǐng)求時(shí)被發(fā)起。這個(gè)場(chǎng)景在“先偵聽后推送局部中進(jìn)展描述。2.6.1 先拉后推用戶可以通過發(fā)送標(biāo)準(zhǔn)的DESCRIBE/SETUP/PLAY請(qǐng)求來

29、向遠(yuǎn)程的源中請(qǐng)求一個(gè)流，然后將它中繼轉(zhuǎn)發(fā)到一個(gè)或者多個(gè)目的地。當(dāng)只希望讓外部流的一份拷貝占用其部連接的帶寬時(shí)，這個(gè)功能可能有用。中繼轉(zhuǎn)發(fā)獲取一份拷貝進(jìn)展多份的復(fù)制和轉(zhuǎn)發(fā)、分發(fā)到請(qǐng)求的客戶端。圖2-7提供了一個(gè)先拉后推pull-then-push場(chǎng)景的實(shí)例。圖2-7 先拉后推場(chǎng)景實(shí)例流媒體效勞器A轉(zhuǎn)發(fā)效勞器發(fā)送標(biāo)準(zhǔn)的RTSP客戶DESCRIBE/SETUP/PLAY請(qǐng)求給遠(yuǎn)程效勞器，即流媒體效勞器B。發(fā)起請(qǐng)求的中繼“客戶端流媒體效勞器A開場(chǎng)承受流，然后向該輸入流的中繼配置中列出的所有目的地發(fā)送ANNOUNCE推送請(qǐng)求。 先偵聽后推送流媒體效勞器可以被配置為將ANNOUNCE請(qǐng)求創(chuàng)立的輸入流自動(dòng)發(fā)

30、送到一個(gè)或者多個(gè)目的地。這可能可以用于配制自動(dòng)播送網(wǎng)絡(luò)。圖2-8提供了一個(gè)先偵聽后推送的場(chǎng)景的實(shí)例。圖2-8 先偵聽后推送場(chǎng)景實(shí)例先偵聽后推送場(chǎng)景的步驟如下：遠(yuǎn)程機(jī)器IpCamera等前端設(shè)備或者中繼效勞器向流媒體效勞器A發(fā)送一個(gè)ANNOUNCE請(qǐng)求。流媒體效勞器可以承受或者否認(rèn)這個(gè)請(qǐng)求。如果它承受了請(qǐng)求，則流媒體效勞器會(huì)檢查其中繼配置，以確定這個(gè)流是否應(yīng)該被中繼。如果該流應(yīng)該被中繼，則流媒體效勞器將向自身發(fā)送標(biāo)準(zhǔn)的RTSP客戶DESCRIBE/SETUP/PLAY請(qǐng)求。發(fā)出請(qǐng)求的中繼“客戶流媒體效勞器A開場(chǎng)接收流，然后向相應(yīng)的輸入流的中繼配置中列出的所有目的地發(fā)送一個(gè)ANNOUCE請(qǐng)求。2.

31、7 流媒體技術(shù)概述隨著互聯(lián)網(wǎng)越來越多的應(yīng)用于現(xiàn)代人的生活當(dāng)中，現(xiàn)在很多的互聯(lián)網(wǎng)公司都希望通過互聯(lián)網(wǎng)流媒體技術(shù)推送給用戶來獲取更多的用戶量。但是音視頻數(shù)據(jù)的數(shù)據(jù)量是很大的，如果要下載下來會(huì)消耗很大的網(wǎng)絡(luò)帶寬和流量。目前網(wǎng)絡(luò)帶寬平均情況下還不算很大，在這種情況下，流媒體技術(shù)的出現(xiàn)就讓這種情況有了很大的改善。讓網(wǎng)絡(luò)客戶通過互聯(lián)網(wǎng)收看互聯(lián)網(wǎng)節(jié)目能夠更加的方便。流媒體技術(shù)的成熟，讓PC可以在接收數(shù)據(jù)的同時(shí)馬上進(jìn)展數(shù)據(jù)解碼，而不需要整個(gè)音視頻文件全部下載，所以客戶只需要等待數(shù)據(jù)初始化完成就可以在線觀看了。當(dāng)音視頻這些數(shù)據(jù)通過互聯(lián)網(wǎng)流媒體效勞器在PC上播放的同時(shí)，數(shù)據(jù)的剩余局部還會(huì)同時(shí)繼續(xù)在效勞器上下載。在

32、互聯(lián)網(wǎng)上傳輸音視頻數(shù)據(jù)就好似在日常生活中從水龍頭接水一樣，以前舊的互聯(lián)網(wǎng)傳輸模式必須要等所有的數(shù)據(jù)下載完成，就像必須等水裝滿才能使用，而水流的大小直接影響著接滿水所需要的時(shí)間?，F(xiàn)在流媒體傳輸方式的出現(xiàn)和完善，包括互聯(lián)網(wǎng)帶寬越來越大，讓用戶能夠在收看的同時(shí)也能夠繼續(xù)下載未觀看的局部。目前，流媒體傳輸技術(shù)大致上可以分為兩類，一種是流實(shí)時(shí)傳輸，另一種是流式的順序傳輸。順序傳輸就是說按照數(shù)據(jù)的順序進(jìn)展下載，所以用戶可以邊下邊看，但是效勞器的數(shù)據(jù)推送和用戶對(duì)數(shù)據(jù)的接收不是同時(shí)的，而是效勞器將數(shù)據(jù)推送后，用戶經(jīng)過一定的網(wǎng)絡(luò)延時(shí)才能接收到并且使用。所以這種傳輸方式用戶看到的視頻并不是實(shí)時(shí)的而是之前一段時(shí)間推

33、送的，中間存在一定時(shí)間間隔。在這種情況下用戶只能觀看已經(jīng)下好的數(shù)據(jù)而不能跳躍時(shí)間看文件后面的節(jié)目。因此對(duì)畫面質(zhì)量要求高的傳輸可以采用這種模式，但是流式傳輸可以保證比較好的傳輸質(zhì)量。顯而易見，流式傳輸更適合在網(wǎng)絡(luò)上用于點(diǎn)播或者直播音視頻節(jié)目。相反的實(shí)時(shí)流式傳輸這種傳輸模式，音視頻信息可以通過網(wǎng)絡(luò)進(jìn)展實(shí)時(shí)的使用和播放。在播放數(shù)據(jù)過程中可以對(duì)觀看進(jìn)度進(jìn)展對(duì)節(jié)目的實(shí)時(shí)控制比方快進(jìn)或者拖放，然而使用這種模式進(jìn)展傳輸不能很好的保證承受質(zhì)量，會(huì)發(fā)生數(shù)據(jù)丟包等情況影響收看質(zhì)量。3攝像機(jī)推送器的設(shè)計(jì)與實(shí)現(xiàn)3.1攝像機(jī)主要模塊攝像機(jī)主要有連接網(wǎng)絡(luò)，與攝像機(jī)進(jìn)展通訊、獲取碼流、設(shè)置參數(shù)、語音對(duì)講、錄像等功能。按照實(shí)

34、現(xiàn)的功能可以分為五個(gè)模塊，實(shí)現(xiàn)每個(gè)模塊的功能時(shí)首先要初始化攝像機(jī)網(wǎng)絡(luò)庫然后進(jìn)展用戶注冊(cè)，在完畢功能時(shí)就需要注銷設(shè)備和釋放網(wǎng)絡(luò)庫，這四個(gè)流程是每個(gè)模塊必不可少的。攝像機(jī)在開機(jī)時(shí)會(huì)向本系統(tǒng)的中心管理效勞器發(fā)送注冊(cè)請(qǐng)求，這個(gè)注冊(cè)請(qǐng)定時(shí)的，在發(fā)送時(shí)還會(huì)攜帶快照，保證連接?；?。中心管理效勞器會(huì)記錄所以在線的Camera信息。攝像機(jī)連接效勞器時(shí)，首先需要對(duì)攝像機(jī)網(wǎng)絡(luò)庫進(jìn)展初始化，設(shè)置定期連接時(shí)間和超時(shí)連接時(shí)間。用戶注冊(cè)設(shè)備需要調(diào)用HI_NET_DEV_Login接口，在注冊(cè)成功后，會(huì)返回一個(gè)Session id作為其他操作的唯一標(biāo)識(shí)。設(shè)備在接入到效勞器后，會(huì)與接入效勞器建立一個(gè)交互的會(huì)話，以TCP方式進(jìn)展

35、連接并發(fā)送保活包，在原有DSS的RTSPSession根底上進(jìn)展改造，修改為屬于自定義協(xié)議的交互流程，底層的網(wǎng)絡(luò)讀取與發(fā)送構(gòu)造完全一致，只需要修改上層對(duì)收到的報(bào)文的處理，則對(duì)于多路會(huì)話的維護(hù)也可以直接用原來對(duì)RTPSession列表的維護(hù)方式，如前端設(shè)備的ID、IP等。自定義協(xié)議局部參考DSS對(duì)RTSP的處理，修改為自己的協(xié)議處理文本協(xié)議、字節(jié)流協(xié)議就可以完成根本的設(shè)計(jì)。如圖3-1是攝像機(jī)對(duì)主要模塊的實(shí)現(xiàn)流程。圖3-1 攝像機(jī)主要模塊實(shí)現(xiàn)流程3.2 攝像機(jī)各模塊的設(shè)計(jì)與實(shí)現(xiàn)3.2.1 語音對(duì)講模塊的設(shè)計(jì)與實(shí)現(xiàn)首先客戶端使用POST在body中攜帶協(xié)議報(bào)文向云平臺(tái)發(fā)送開場(chǎng)對(duì)講命令，云平臺(tái)組織協(xié)議

36、報(bào)文向指定的設(shè)備發(fā)送。如圖3-2語音對(duì)講實(shí)現(xiàn)的流程圖。設(shè)備執(zhí)行開場(chǎng)對(duì)講命令后向云平臺(tái)返回相應(yīng)報(bào)文，云平臺(tái)將響應(yīng)報(bào)文返回給客戶端，客戶端請(qǐng)求開場(chǎng)對(duì)講成功后，開場(chǎng)向云平臺(tái)發(fā)送采集的音頻數(shù)據(jù)，云平臺(tái)將音頻數(shù)據(jù)轉(zhuǎn)發(fā)給設(shè)備，設(shè)備將音頻數(shù)據(jù)播放出來。轉(zhuǎn)發(fā)語音數(shù)據(jù)首先調(diào)用netDevStartStream()，開啟攝像頭流轉(zhuǎn)發(fā)。在該函數(shù)中調(diào)用攝像頭的請(qǐng)求流轉(zhuǎn)發(fā)數(shù)據(jù)的API，并且設(shè)置回調(diào)函數(shù)myStreamProc來接收數(shù)據(jù)，具體的流轉(zhuǎn)發(fā)在EasyCameraSource:PushFrame函數(shù)中實(shí)現(xiàn)轉(zhuǎn)發(fā)。PushFrame函數(shù)被攝像頭回調(diào)函數(shù)直接調(diào)用，首先調(diào)用GetH246FromPSframe, len,

37、 &h264Buf, h264Len, isVideo, isAudio。從攝像頭的H.264編碼的PS流中解析得到H.264標(biāo)準(zhǔn)流，標(biāo)準(zhǔn)流中包含視頻幀、語音幀攝像頭設(shè)置為復(fù)合流才能獲取到和H.264的其他幀。相關(guān)接口有：?jiǎn)?dòng)語音對(duì)講HI_NET_DEV_StartVoice、停頓語音HI_NET_DEV_StopVoice、轉(zhuǎn)發(fā)數(shù)據(jù)HI_NET_DEV_SendVoiceData。圖3-2 語音對(duì)講模塊的實(shí)現(xiàn)流程圖參數(shù)配置模塊的設(shè)計(jì)與實(shí)現(xiàn)實(shí)現(xiàn)參數(shù)配置必須初始化網(wǎng)絡(luò)庫和用戶注冊(cè)這兩個(gè)步驟。如圖3-3參數(shù)配置模塊的實(shí)現(xiàn)流程。圖3-3參數(shù)配置模塊的實(shí)現(xiàn)流程在攝像機(jī)連接到效勞器之前，就應(yīng)先在

38、Camera效勞中獲取到攝像機(jī)的具體參數(shù)，才能夠繼續(xù)進(jìn)展其他效勞。，將用戶注冊(cè)接口返回的句柄作為配置接口的首個(gè)參數(shù)。相關(guān)接口有：設(shè)置攝像機(jī)參數(shù)HI_NET_DEV_SetConfig、攝像機(jī)翻轉(zhuǎn)HI_NET_DEV_CMD_DISPLAY_E*T。3.2.3 報(bào)警模塊的設(shè)計(jì)與實(shí)現(xiàn)報(bào)警回調(diào)可分為“移動(dòng)報(bào)警和“輸入報(bào)警兩種數(shù)據(jù)。移動(dòng)報(bào)警，當(dāng)檢測(cè)到鏡頭相應(yīng)區(qū)域有移動(dòng)，回調(diào)函數(shù)將移動(dòng)區(qū)域的相關(guān)數(shù)據(jù)輸出。輸入報(bào)警，攝像機(jī)參數(shù)有數(shù)據(jù)變更時(shí)有輸入報(bào)警信息。聯(lián)動(dòng)報(bào)警在初始化網(wǎng)絡(luò)庫和注冊(cè)設(shè)備后就可以使用，相對(duì)來說比較的簡(jiǎn)單，首先根據(jù)客戶端調(diào)用的命令，調(diào)用攝像頭相關(guān)的SDK函數(shù)就可以了。從攝像機(jī)上發(fā)現(xiàn)畫面上有移動(dòng)

39、的物體，首先攝像機(jī)向CMS效勞器發(fā)送一個(gè)請(qǐng)求，報(bào)告有移動(dòng)的信息。CMS回復(fù)MSG_SC_BG_ACK給Client后，會(huì)將報(bào)警信息發(fā)給客戶端，客戶端拿到報(bào)警信息后，再根據(jù)自己的實(shí)現(xiàn)的功能推送給用戶。如圖3-4攝像機(jī)報(bào)警模塊的具體流程。相關(guān)接口有：報(bào)警信息回調(diào)HI_NET_DEV_SetDataCallBack、啟動(dòng)實(shí)時(shí)數(shù)據(jù)HI_NET_DEV_StartStream。圖3-4 報(bào)警模塊的實(shí)現(xiàn)流程 實(shí)時(shí)數(shù)據(jù)流模塊的設(shè)計(jì)與實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)流啟動(dòng)后通過回調(diào)函數(shù)獲取攝像機(jī)的當(dāng)前實(shí)時(shí)數(shù)據(jù)。獲取到的攝像機(jī)視頻畫面每一幀數(shù)據(jù)都是完整的數(shù)據(jù)幀，數(shù)據(jù)幀包含幀頭用于區(qū)分?jǐn)?shù)據(jù)的類型，以及后面的視頻數(shù)據(jù)。具體的實(shí)時(shí)數(shù)據(jù)流

40、實(shí)現(xiàn)首先需要調(diào)用CameraLogin()，之后需要獲取到連接攝像頭的具體配置信息。然后注冊(cè)流推送事件的回調(diào)，根據(jù)接收到的命令生成流信息。最后調(diào)用netDevStartStream()來開啟攝像頭的流轉(zhuǎn)發(fā)。如圖3-5實(shí)時(shí)數(shù)據(jù)流的實(shí)現(xiàn)流程。圖3-5 實(shí)時(shí)數(shù)據(jù)流模塊的實(shí)現(xiàn)流程相關(guān)的接口有：?jiǎn)?dòng)實(shí)時(shí)數(shù)據(jù)HI_NET_DEV_StartStream 、關(guān)閉實(shí)時(shí)數(shù)據(jù)HI_NET_DEV_StopStream 、實(shí)時(shí)數(shù)據(jù)回調(diào)HI_NET_DEV_SetStreamCallBack。 云臺(tái)控制模塊的設(shè)計(jì)與實(shí)現(xiàn)首先根據(jù)客戶端調(diào)用的命令，調(diào)用攝像頭相關(guān)的SDK函數(shù)就可以了。從客戶端上云臺(tái)控制Camera，首先C

41、lient通過RESTful接口向CMS效勞器發(fā)送一個(gè)請(qǐng)求，容包括設(shè)備序列號(hào)、動(dòng)作等。CMS組織控制控制命令報(bào)文回復(fù)Client之后，會(huì)將請(qǐng)求容發(fā)送給對(duì)應(yīng)的Camera進(jìn)展控制，在EasyPlayerActivity.java中增加4個(gè)按鍵，分別為上下左右，并增加OnTouchListener接口，當(dāng)按鍵按下時(shí)持續(xù)轉(zhuǎn)動(dòng)，釋放按鍵時(shí)停頓轉(zhuǎn)動(dòng)。Camera在執(zhí)行云平臺(tái)發(fā)送的控制的報(bào)文之后向Client返回控制的結(jié)果。云臺(tái)控制包括上下左右，方向停頓，聚焦等擴(kuò)展功能。云臺(tái)控制在實(shí)際生活和工作中的用途是非常大的，例如監(jiān)控報(bào)警和實(shí)時(shí)移動(dòng)檢測(cè)，都需要用到攝像頭的轉(zhuǎn)動(dòng)來實(shí)現(xiàn)更大角度的監(jiān)控。所以這個(gè)模塊的實(shí)現(xiàn)是

42、十分有用的。如圖3-6云臺(tái)模塊的實(shí)現(xiàn)流程。相關(guān)接口有：開場(chǎng)云臺(tái)控制操作HI_NET_DEV_PTZ_Ctrl_Standard、云臺(tái)上仰HI_NET_DEV_PTZ_UP、停頓云臺(tái)控制HI_NET_DEV_PTZ_STOP等。圖3-6 云臺(tái)模塊的實(shí)現(xiàn)流程3.3模塊的加載過程每一個(gè)模塊必須實(shí)現(xiàn)兩個(gè)線程，一個(gè)是Main函數(shù)，在DSS效勞器開場(chǎng)啟動(dòng)的時(shí)候就調(diào)用這個(gè)函數(shù)，對(duì)所在開發(fā)的模塊庫進(jìn)展初始化。一個(gè)是Dispatch函數(shù)，也就是分發(fā)函數(shù)，效勞器在做*種特定的目的時(shí)需要調(diào)用這個(gè)函數(shù)。對(duì)一個(gè)編寫好的模塊，在效勞器啟動(dòng)的時(shí)候就應(yīng)該自動(dòng)的加載這個(gè)模塊。對(duì)于DSS模塊加載的整個(gè)過程，首先我們應(yīng)知道在DSS

43、中模塊實(shí)際上就是類，我們完成的功能實(shí)際是通過這些類的方法來實(shí)現(xiàn)的。界面調(diào)用函數(shù)主要介紹了Client數(shù)據(jù)獲取來源，主要通過采集數(shù)據(jù)，得到數(shù)據(jù)后停頓采集，進(jìn)展推流，流推送完畢之后停頓推流，得到輸出的流進(jìn)展開場(chǎng)播放和播放完畢的停頓播放為一個(gè)主流程。首先開場(chǎng)捕獲采集，傳遞采集參數(shù)SOURCE_TYPE資源類型、nCamId攝像機(jī)ID、nAudioId音頻ID、hCapWnd云平臺(tái)對(duì)象、szURL云平臺(tái)地址、nVideoWidth視頻寬度、nVideoHeight視頻高度、nFps文件、nBitRate字節(jié)頻率。傳遞參數(shù)后調(diào)用接口。再調(diào)用停頓采集函數(shù)，停頓采集。接下來進(jìn)展視頻播放的第二步開場(chǎng)推流。調(diào)用

44、推流函數(shù)傳遞推流參數(shù)ServerIp效勞器ip、nPushPort推流端口、sPushName推流名稱、nPushBufSize推流大小。推流完成后調(diào)用停頓推流函數(shù)，進(jìn)展視頻播放的第三步播放。首先流已經(jīng)得到解析流并進(jìn)展播放調(diào)用播放函數(shù)、傳遞播放函數(shù)參數(shù)szURL播放停頓、HWND播放流。當(dāng)播放完畢后調(diào)用停頓播放函數(shù)，停頓播放。如圖3-7為界面回調(diào)的主要流程。圖3-7界面回調(diào)函數(shù)流程圖3.3.1采集模塊采集分為本地音視頻采集和RTSP流采集。本地音視頻主要通過DShow進(jìn)展采集，函數(shù)如下：int CSourceManager:StartDSCaptureint nCamId, int nAudi

45、oId,HWNDhShowWnd,int nVideoWidth, int nVideoHeight, int nFps, int nBitRate該函數(shù)主要實(shí)現(xiàn)本地音視頻采集和音視頻編碼器的初始化，需要注意的是這里的參數(shù)設(shè)置：1本地采集的視頻寬高和*264編碼器的寬高需一致，數(shù)據(jù)格式建議設(shè)為YUY2程序中默認(rèn)為“YUY2，因?yàn)樵贒Show的數(shù)據(jù)采集線程中需要進(jìn)展編碼前的格式轉(zhuǎn)換YUY2->I420，如果格式不統(tǒng)一，這里將要重寫轉(zhuǎn)換函數(shù)。2本地音頻采樣率默認(rèn)為16000，這個(gè)設(shè)置在Pusher中表現(xiàn)最正確，其他采樣率還有待測(cè)試。3其他設(shè)置請(qǐng)參照DEVICE_CONFIG_INFO構(gòu)造和E

46、ncoder_Config_Info構(gòu)造的詳細(xì)說明。而RTSP流采集和流播放采用的是同一個(gè)類ClassPlayerManager實(shí)現(xiàn)，主要實(shí)現(xiàn)方法為：接收網(wǎng)絡(luò)RTSP流進(jìn)展推流EasyPlayerManager m_netStreamCapture;接收Darwin推出的RTSP流進(jìn)展播放m_netStreamPlayer。這個(gè)類封裝了libEasyPlayer庫提供的接口，方便調(diào)用；這個(gè)庫集成在EasyClient源碼中，也是EasyPlayer的核心；她主要實(shí)現(xiàn)了從網(wǎng)絡(luò)接收RTSP流進(jìn)展解析，獲取H264編碼數(shù)據(jù)和AAC編碼數(shù)據(jù)分別進(jìn)展解碼并呈現(xiàn)和播放。當(dāng)然，作為Capturer而言，我們

47、只需要用它獲取到編碼數(shù)據(jù)即可。3.3.2推送模塊首先開場(chǎng)推流，調(diào)用推流函數(shù)傳遞推流需要的參數(shù)ServerIp效勞器IP、nPushPort，效勞器端口、sPushName推送流名稱、nPushBufSize推送流大小。創(chuàng)立推送器指針，指針先實(shí)例化對(duì)象，設(shè)置推送流編碼格式、設(shè)置推送回調(diào)，可以獲取推送器反響的信息，最后開啟流推送調(diào)用流回調(diào)方法。這個(gè)時(shí)候回調(diào)方法開場(chǎng)生效回傳推送器反響信息，當(dāng)反響信息大于等于0時(shí)說明流推送完畢，如果反響失敗停頓推流。停頓推流之后關(guān)閉流接口，釋放流，將流信息置空保證下次推送可以繼續(xù)。唯一需要注意的是推送標(biāo)志m_bPushing，這個(gè)標(biāo)志將在數(shù)據(jù)回調(diào)函數(shù)中起到真正的推送開

48、關(guān)的作用嚴(yán)格的說在StartPush中也應(yīng)該調(diào)用m_bPushing判斷是否推送已經(jīng)進(jìn)展。3.4 推送模塊的設(shè)計(jì)與實(shí)現(xiàn)細(xì)節(jié)模塊的主程序就是在收到RTSP命令之后模塊執(zhí)行的總程序。分別是對(duì)文件的解析，文件讀寫等各個(gè)功能的調(diào)用。因?yàn)榱魍扑湍K首先需要獲得數(shù)據(jù)才能推送，所以文件的讀寫性能也十分重要，這樣才不會(huì)因?yàn)閿?shù)據(jù)讀寫對(duì)推送數(shù)據(jù)造成不必要的影響。因此我們使用了雙隊(duì)列緩存，使文件從讀取到發(fā)送是一個(gè)平滑的過程，所以可以讓數(shù)據(jù)發(fā)送的數(shù)率能夠穩(wěn)定發(fā)送。雙隊(duì)列緩存的使用大大提高了讀取數(shù)據(jù)的平滑性，在客戶端播放的時(shí)候能夠明顯的減少因發(fā)送導(dǎo)致的畫面不流暢。Darwin效勞器在接收到Camera直播推送后，將該設(shè)

49、備的直播流信息寫入到Redis中，這樣就方便CMS效勞器直接對(duì)設(shè)備直播流信息進(jìn)展檢索。Darwin效勞器會(huì)定期檢查設(shè)備直播流的客戶端數(shù)量檢查，當(dāng)設(shè)備的Output數(shù)量由>0減為0，或者在Darwin效勞器部巡檢中發(fā)現(xiàn)規(guī)定事件沒有客戶端請(qǐng)求，Darwin效勞器會(huì)向CMS效勞器發(fā)送設(shè)備直播流釋放請(qǐng)求，CMS效勞器再通過信令發(fā)送給Camera，停頓Camera向Darwin效勞器推送直播流。3.5 RTSP請(qǐng)求的處理當(dāng)接收到用戶端的RTSP請(qǐng)求，DSS效勞器就會(huì)解析請(qǐng)求，在RTSPSession:Run函數(shù)中根據(jù)RTSP請(qǐng)求容的不同，將其分派給相應(yīng)的模塊來處理，而這個(gè)Module會(huì)根據(jù)RTSP

50、請(qǐng)求容，對(duì)用戶端做出對(duì)應(yīng)的處理。RTSP支持的操作是客戶端可以請(qǐng)求通過HTTP展示說明。含多播的地址和端口，如果演示文稿正在多播，和包含目的地提供的客戶端，如果演示文稿是單播。媒體效勞器可以參加到現(xiàn)有的會(huì)議效勞器和客戶端之間的對(duì)話。由上述的分析可知，當(dāng)接收到DSS效勞器分派來的任務(wù)，QTSSTSModule模塊也未必一定會(huì)處理這個(gè)請(qǐng)求。QTSSTSModule首先會(huì)解析用戶的RTSP請(qǐng)求，根據(jù)容判斷用戶請(qǐng)求播放的文件是不是TS格式，再檢查效勞器目錄中是否存在這個(gè)文件，再?zèng)Q定是否繼續(xù)預(yù)處理請(qǐng)求。模塊與用戶之間有一個(gè)交互過程，首先客戶端向DSS效勞器詢問有哪些方法可用，效勞器回復(fù)諸如DESCRIB

51、E，SETUP，TEARDOWN，PLAY等；其次客戶端請(qǐng)求DSS效勞器提供的媒體描述信息，比方編碼格式、播放時(shí)長(zhǎng)、傳輸協(xié)議等等，Server以SDP形式回復(fù)；客戶端請(qǐng)求效勞器建立會(huì)話，效勞器建立會(huì)話，返回會(huì)話相關(guān)信息。最后，客戶端請(qǐng)求播放節(jié)目，效勞器應(yīng)答并且向其發(fā)送數(shù)據(jù)流。3.6 EasyPusher函數(shù)EasyPusher是一個(gè)推送RTSP流媒體音/視頻流給RTSP流媒體效勞器的標(biāo)準(zhǔn)RTSP/RTP協(xié)議推送庫，通過EasyPusher就可以防止接觸到稍顯復(fù)雜的RTSPANNOUNCE、SETUP、PLAY/RTP/RTCP推送流程，只需要調(diào)用EasyPusher的幾個(gè)API接口，就能輕松、

52、穩(wěn)定地把流媒體音視頻數(shù)據(jù)推送給RTSP效勞器Darwin Streaming Server進(jìn)展轉(zhuǎn)發(fā)和分發(fā)，EasyPusher經(jīng)過長(zhǎng)時(shí)間的用戶檢驗(yàn)測(cè)試，穩(wěn)定性非常高。具體的調(diào)用過程首先在Callback函數(shù)中可以獲取到H.264視頻流和音頻流。調(diào)用以下圖3-8EasyPusher根本調(diào)用流程中的EasyPusher_PushFrame接口，將音視頻流推送到Darwin等RTSP效勞器。圖3-8 EasyPusher根本調(diào)用流程通過這種方式就可以將實(shí)時(shí)通話的過程通過RTSP、RTP的形式推送給第三方流媒體效勞器做視頻通話監(jiān)視，第三方錄像，級(jí)聯(lián)等等功能。3.7 攝像機(jī)配置本系統(tǒng)選擇的攝像機(jī)是海康螢

53、石云基于海思HI3518C方案攝像頭，該攝像頭可以水平、垂直雙方向轉(zhuǎn)動(dòng)，具有360度的視野控制，具有720P的高清分辨率。下面是攝像頭的配置流程：1連接網(wǎng)絡(luò)將攝像機(jī)通過有線的方式連接到攝像機(jī)，路由器需要開啟DHCP功能，給攝像機(jī)分配到IP地址如果路由器沒有開啟DHCP功能，攝像機(jī)連接網(wǎng)線后，攝像機(jī)的默認(rèn)IP就是8。2查找攝像機(jī)翻開HiCamSearcher.e*e，搜索攝像機(jī)，如圖3-9查找到攝像機(jī)的具體IP地址后就可以進(jìn)展下一步的操作。圖3-9 找到攝像機(jī)分配的網(wǎng)絡(luò)地址3進(jìn)入攝像機(jī)的Web管理通過獲取的攝像機(jī)IP地址登陸攝像機(jī)的Web管理界面，默認(rèn)用戶名：admin，默

54、認(rèn)密碼：admin；如圖3-10攝像機(jī)管理界面。圖3-10攝像機(jī)web管理界面4區(qū)分?jǐn)z像機(jī)硬件方案進(jìn)入設(shè)備信息頁面，找到“軟件版本或者“固件版本項(xiàng)，如果版本號(hào)以V6打頭，則攝像機(jī)是海思HI3518C方案。如果版本號(hào)以V7打頭，則攝像機(jī)就是海思HI3518E方案。如圖3-11設(shè)置攝像機(jī)的具體參數(shù)。圖3-11設(shè)置攝像機(jī)具體參數(shù)3.8 推送音視頻數(shù)據(jù)的緩存設(shè)計(jì)Camera在向Darwin云平臺(tái)推送音視頻數(shù)據(jù)時(shí)，有時(shí)一個(gè)I幀會(huì)很大，從攝像機(jī)SDK中獲取的數(shù)據(jù)就會(huì)被拆分。我們使用Pusher向云平臺(tái)推送時(shí)需要每次發(fā)送一整幀數(shù)據(jù)，這時(shí)我們就需要設(shè)計(jì)一個(gè)緩存機(jī)制將SDK拆分的幀組成一個(gè)完整的幀數(shù)據(jù)，再使用P

55、usher推送給Darwin云平臺(tái)。如圖3-12這里我們可以看到圖片的第三行到第十行是一幀數(shù)據(jù)。由于數(shù)據(jù)過大，SDK將其拆分為8個(gè)包。我們就需要將這8個(gè)數(shù)據(jù)包組合正一個(gè)完整的關(guān)鍵幀推送給云平臺(tái)。圖3-12 攝像機(jī)SDK獲取的幀數(shù)據(jù)具體的設(shè)計(jì)思路我們建立一個(gè)固定大小的緩存區(qū)buffer，和一個(gè)用于標(biāo)記偏移的pos并初始化為0；當(dāng)我們獲取第一個(gè)數(shù)據(jù)包的時(shí)候我們判斷數(shù)據(jù)包是否為0*00、0*00、0*00、0*01開頭，則表示這是一個(gè)I幀或P幀，判斷pos是否為0，假設(shè)為0，則將數(shù)據(jù)放入buffer。假設(shè)不是，說明buffer中已經(jīng)存在一個(gè)完整的I幀或者P幀數(shù)據(jù)，則發(fā)送。假設(shè)獲取到的數(shù)據(jù)開頭不為0*

56、00、0*00、0*00、0*01，則判斷pos是否為0，假設(shè)是，則丟棄，假設(shè)不是，則說明這個(gè)數(shù)據(jù)為拆分的數(shù)據(jù)，需要參加buffer。4系統(tǒng)測(cè)試4.1 測(cè)試方法本次測(cè)試使用的方法是黑盒測(cè)試方法，這是一種通用的軟件測(cè)試方法，它直接通過測(cè)試軟件或系統(tǒng)設(shè)計(jì)的功能是否能夠正常使用來作為測(cè)試準(zhǔn)則。在黑盒測(cè)試的過程中，我們把要測(cè)試的功能當(dāng)做一個(gè)不能翻開的黑盒子，不需要考慮其部的構(gòu)造和特效，直接調(diào)用程序的接口測(cè)試，功能能否到達(dá)系統(tǒng)設(shè)計(jì)需要的要求。這是一種十分簡(jiǎn)便而且高效的測(cè)試方法。4.2 TS推送測(cè)試本系統(tǒng)同時(shí)支持MPEG-2 TS流和H.264 TS流，所以現(xiàn)在對(duì)兩種流分別進(jìn)展測(cè)試，我們找到了兩種不同流的

57、文件共十五個(gè)，對(duì)其進(jìn)展了推送的測(cè)試。首先我們進(jìn)展對(duì)MPEG-2 TS流的測(cè)試，我們共做了十次不同文件的測(cè)試，測(cè)試過程中視頻的播放十分流程清晰，沒有視頻中斷卡頓，或者馬賽克和延時(shí)的現(xiàn)象。表4-1 推送MPEG-2 TS流測(cè)試前置條件：Darwin效勞器配置成功和攝像機(jī)推送模塊開啟測(cè)試方法：黑盒測(cè)試。輸入數(shù)據(jù)：共10組MPEG-2數(shù)據(jù)。執(zhí)行步驟：開啟攝像機(jī)推送效勞。預(yù)期輸出：數(shù)據(jù)推送成功，誤差符合要求。實(shí)際結(jié)果：推送成功，誤差很小，符合要求。結(jié)論：測(cè)試成功從表4-2可以看出。文件的播放時(shí)間和發(fā)送耗時(shí)的誤差十分的小，根本都在23毫秒之間，這個(gè)誤差是完全符合標(biāo)準(zhǔn)的。表4-2MPEG-2 TS流文件推送測(cè)試結(jié)果文件名文件大小mb