本發(fā)明屬于實(shí)時(shí)視頻傳輸技術(shù)領(lǐng)域,具體涉及一種基于TD-LTE應(yīng)急通信的無線視頻傳輸系統(tǒng)。
背景技術(shù):
隨著科技的不斷發(fā)展,人們對(duì)于火災(zāi)、地震、襲擊等突發(fā)應(yīng)急事件的救援過程日益重視。一般的救援通信系統(tǒng)中都包括一個(gè)監(jiān)控中心、若干現(xiàn)場(chǎng)視頻采集點(diǎn)以及若干接受語音命令的呼叫終端。傳統(tǒng)的視頻采集點(diǎn)都是固定攝像頭,將采集到的視頻數(shù)據(jù)通過以太網(wǎng)傳送到監(jiān)控指揮中心,這種傳輸方式已經(jīng)過于死板,一是其監(jiān)控力度的局限性,只能監(jiān)督固定的范圍,無法動(dòng)態(tài)的移動(dòng);二是這種方式的基礎(chǔ)設(shè)施很容易遭到破壞,一旦主線路或者某個(gè)重要的轉(zhuǎn)發(fā)節(jié)點(diǎn)壞掉,則整個(gè)視頻傳輸系統(tǒng)都將癱瘓,而采用TD-LTE無線網(wǎng)絡(luò)作為傳輸信道則可以避免這些弊端。一般在多線程處理過程中,子線程創(chuàng)建之后都要通過循環(huán)維持線程的生存,而為了防止子線程一直占用系統(tǒng)資源,在子線程中會(huì)加入休眠機(jī)制,但是,在視頻傳輸系統(tǒng)的接收過程中,如果加入休眠函數(shù)會(huì)導(dǎo)致數(shù)據(jù)包的丟失,嚴(yán)重時(shí)會(huì)導(dǎo)致畫面失真。
技術(shù)實(shí)現(xiàn)要素:
有鑒于此,本發(fā)明的目的是提供一種基于TD-LTE應(yīng)急通信的無線視頻傳輸系統(tǒng)。
本發(fā)明的目的是通過以下技術(shù)方案來實(shí)現(xiàn)的,基于TD-LTE應(yīng)急通信的無線視頻傳輸系統(tǒng),包括至少一個(gè)移動(dòng)通信終端、基站和監(jiān)控中心;
移動(dòng)通信終端:用于采集視頻數(shù)據(jù),并將所采集的視頻數(shù)據(jù)進(jìn)行壓縮編碼,通過TD-LTE無線通信網(wǎng)絡(luò)將壓縮編碼后的視頻數(shù)據(jù)傳輸給基站;
基站:用于接收移動(dòng)通信終端傳輸過來的壓縮編碼后的視頻數(shù)據(jù),通過TD-LTE無線通信網(wǎng)絡(luò)將壓縮編碼后的視頻數(shù)據(jù)傳輸給監(jiān)控中心的服務(wù)器作解碼處理并予以顯示。
進(jìn)一步,移動(dòng)通信終端將采集的視頻數(shù)據(jù)進(jìn)行壓縮編碼后以UDP方式將視頻數(shù)據(jù)傳輸?shù)交?,再由基站轉(zhuǎn)發(fā)至監(jiān)控中心。
進(jìn)一步,移動(dòng)通信終端將一幀數(shù)據(jù)分為若干個(gè)UDP分包存入緩存區(qū),然后將UDP分包按順序從視頻發(fā)送端口發(fā)送至基站,再由基站轉(zhuǎn)發(fā)至監(jiān)控中心。
進(jìn)一步,監(jiān)控中心的服務(wù)器按照預(yù)先設(shè)置的IP號(hào)開辟端口并接收UDP分包,接收到的數(shù)據(jù)存入緩存區(qū)。
進(jìn)一步,每個(gè)移動(dòng)通信終端具有與該移動(dòng)通信終端相對(duì)應(yīng)的接收線程、接收緩存以及解碼播放線程。
進(jìn)一步,所述移動(dòng)通信終端具有北斗GPS雙模定位功能。
進(jìn)一步,監(jiān)控中心的服務(wù)器接收到的視頻數(shù)據(jù)被從緩存區(qū)提取出來,然后經(jīng)過Ffmpeg視頻處理程序?qū)?shù)據(jù)包解碼并轉(zhuǎn)換為流的形式,最后經(jīng)過OpenCV的視覺庫(kù)作視頻顯示。
由于采用了上述技術(shù)方案,本發(fā)明具有如下的優(yōu)點(diǎn):
視頻傳輸?shù)臄?shù)據(jù)量十分龐大,因此,在傳輸數(shù)據(jù)之前必須進(jìn)行壓縮編碼,然后在接收端進(jìn)行解碼播放,本發(fā)明所使用的H264標(biāo)準(zhǔn)相比于目前在網(wǎng)絡(luò)中所使用的H263以及H261壓縮標(biāo)準(zhǔn)具有更高的編碼效率。
在視頻接收模塊,本發(fā)明采用消息響應(yīng)機(jī)制的用戶界面線程進(jìn)行接收,可以有效地解決傳統(tǒng)線程使用循環(huán)配合休眠函數(shù)所引起的丟包情況,在接收端檢測(cè)數(shù)據(jù)包的幀信息與包序列,以確定每一個(gè)視頻包進(jìn)入循環(huán)鏈表的存儲(chǔ)位置,防止UDP傳輸協(xié)議引發(fā)的亂序情況。另外,本發(fā)明在在解碼模塊與播放模塊中間加入一個(gè)雙緩存結(jié)構(gòu)的乒乓buffer,數(shù)據(jù)經(jīng)過解碼之后以幀為單位存入緩存中,可以有效地提高處理器的運(yùn)算能力,并防止數(shù)據(jù)因?yàn)榫€程間處理速度的不同而被覆蓋丟失。
附圖說明
為了使本發(fā)明的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚,下面將結(jié)合附圖對(duì)本發(fā)明作進(jìn)一步的詳細(xì)描述,其中:
圖1為基于TD-LTE應(yīng)急通信的數(shù)據(jù)傳輸系統(tǒng)結(jié)構(gòu)示意圖;
圖2為基于TD-LTE應(yīng)急通信的數(shù)據(jù)傳輸系統(tǒng)原理框圖;
圖3為發(fā)送端視頻采集過程的流程圖;
圖4為發(fā)送端視頻編碼過程;
圖5為接收端通過消息響應(yīng)機(jī)制建立的數(shù)據(jù)接收線程;
圖6為接收端通過死循環(huán)建立的視頻解碼播放線程;
圖7為整個(gè)視頻接收端所有線程的工作過程;
圖8為解碼之后的幀緩存部分的工作原理。
具體實(shí)施方式
以下將結(jié)合附圖,對(duì)本發(fā)明的優(yōu)選實(shí)施例進(jìn)行詳細(xì)的描述;應(yīng)當(dāng)理解,優(yōu)選實(shí)施例僅為了說明本發(fā)明,而不是為了限制本發(fā)明的保護(hù)范圍。
如圖1、2所示,基于TD-LTE應(yīng)急通信的無線視頻傳輸系統(tǒng),包括至少一個(gè)移動(dòng)通信終端、基站和監(jiān)控中心。每一個(gè)移動(dòng)通信終端都會(huì)事先知道監(jiān)控中心的網(wǎng)絡(luò)信息并都將在監(jiān)控中心的數(shù)據(jù)庫(kù)上注冊(cè),移動(dòng)通信終端以一定的時(shí)間周期向監(jiān)控中心發(fā)送自己的網(wǎng)絡(luò)信息,監(jiān)控中心也以一定的時(shí)間不斷的檢測(cè)在線用戶列表,如果時(shí)間超出一定范圍,監(jiān)控中心一直沒有收到某一個(gè)移動(dòng)通信終端的網(wǎng)絡(luò)信息,說明該用戶不在線,監(jiān)控中心將重新更新用戶列表。
移動(dòng)通信終端主要包括視頻采集模塊、顯示控制模塊、通信傳輸模塊以及電源模塊。監(jiān)控中心主要是具有多線程處理功能的服務(wù)器或者PC機(jī)。在移動(dòng)通信終端和監(jiān)控中心上都使用能夠處理多線程業(yè)務(wù)的面向?qū)ο笳Z言控制視頻數(shù)據(jù)的接收、編解碼和播放過程。
移動(dòng)通信終端:用于采集視頻數(shù)據(jù),并將所采集的視頻數(shù)據(jù)進(jìn)行壓縮編碼,通過TD-LTE無線通信網(wǎng)絡(luò)將壓縮編碼后的視頻數(shù)據(jù)傳輸給基站;
基站:用于接收移動(dòng)通信終端傳輸過來的壓縮編碼后的視頻數(shù)據(jù),通過TD-LTE無線通信網(wǎng)絡(luò)將壓縮編碼后的視頻數(shù)據(jù)傳輸給監(jiān)控中心的服務(wù)器作解碼處理并予以顯示。監(jiān)控中心的服務(wù)器接收到的視頻數(shù)據(jù)被從緩存區(qū)提取出來,然后經(jīng)過Ffmpeg視頻處理程序?qū)?shù)據(jù)包解碼并轉(zhuǎn)換為流的形式,最后經(jīng)過OpenCV的視覺庫(kù)作視頻顯示。
作為對(duì)本發(fā)明的改進(jìn),移動(dòng)通信終端將一幀數(shù)據(jù)分為若干個(gè)UDP分包存入緩存區(qū),然后將UDP分包按順序從視頻發(fā)送端口發(fā)送至基站,再由基站轉(zhuǎn)發(fā)至監(jiān)控中心。監(jiān)控中心的服務(wù)器按照預(yù)先設(shè)置的IP號(hào)開辟端口并接收UDP分包,接收到的數(shù)據(jù)存入緩存區(qū)。
由于本發(fā)明在視頻接收時(shí)使用UDP傳輸協(xié)議,具有低時(shí)延性;為了克服UDP傳輸協(xié)議可靠性差的缺點(diǎn),本發(fā)明采用并行的多線程接收和單獨(dú)存儲(chǔ)的接收機(jī)制,即為每一路移動(dòng)通信終端開辟一個(gè)單獨(dú)的接收線程和接收緩存,使服務(wù)器在下一個(gè)數(shù)據(jù)包來臨之前可以完整的接收并存儲(chǔ)當(dāng)前數(shù)據(jù)包,在同等網(wǎng)絡(luò)條件下,該方法相比于串行接收可以極大的降低丟包率;在數(shù)據(jù)接收過程中采用消息響應(yīng)的方法而不是采用死循環(huán)的方法,在保證丟包率在一定范圍內(nèi)的前提下,該方法具有降低CPU消耗的優(yōu)點(diǎn)。
在無線視頻傳輸?shù)倪^程中,使用幀間預(yù)測(cè)編碼對(duì)視頻數(shù)據(jù)進(jìn)行編碼可以提升視頻的編碼效率。在幀間預(yù)測(cè)編碼中,以規(guī)定的間隔生成通過其自身對(duì)輸入圖像進(jìn)行編碼的幀內(nèi)編碼幀(I圖像),在I圖像彼此之間生成對(duì)輸入圖像與預(yù)測(cè)圖像的差分進(jìn)行編碼的多個(gè)幀間編碼幀(P圖像或B圖像),因此能夠大幅度地壓縮視頻數(shù)據(jù)。被采集到的視頻數(shù)據(jù)先是進(jìn)入緩存區(qū)域,移動(dòng)通信終端的回放線程和壓縮編碼線程獨(dú)立的在緩存區(qū)域中讀取數(shù)據(jù),如果回放的視頻模糊或者不連續(xù),說明采集到的視頻數(shù)據(jù)失真,移動(dòng)通信終端使用者應(yīng)該重新采集。壓縮編碼線程從緩存區(qū)域讀取的數(shù)據(jù)經(jīng)過H.264標(biāo)準(zhǔn)壓縮編碼之后被送到套接字發(fā)送。
作為對(duì)發(fā)明的改進(jìn),在移動(dòng)通信終端的發(fā)送終端加入了北斗GPS雙模定位功能,通過儲(chǔ)存的預(yù)制程序算法,獲得準(zhǔn)確可靠的地理位置信息。雙模定位的工作方式相比于單模定位可以更好的保證定位精確性和可靠性,若其中一種定位系統(tǒng)的衛(wèi)星信號(hào)丟失,還可以依靠另一個(gè)定位系統(tǒng)進(jìn)行定位導(dǎo)航。移動(dòng)通信終端在采集到一幀視頻數(shù)據(jù)后,系統(tǒng)將通過雙模定位獲取該視頻采集點(diǎn)的具體地理位置一并發(fā)送給監(jiān)控中心,在監(jiān)控中心通過數(shù)據(jù)挖掘的方式分離視頻數(shù)據(jù)和地理信息。通過精確定位,可以讓用戶實(shí)時(shí)了解自己的位置情況,也可以讓監(jiān)控中心更清楚的了解救援現(xiàn)場(chǎng)的周邊環(huán)境。
在本發(fā)明中,設(shè)置了至少一個(gè)移動(dòng)通信終端中,每一路移動(dòng)通信終端都會(huì)統(tǒng)一通過TD-LTE網(wǎng)絡(luò)實(shí)時(shí)的向監(jiān)控中心發(fā)送視頻數(shù)據(jù),但是由于監(jiān)控中心屏幕大小的局限性,為了保證視頻信息的準(zhǔn)確性和圖像質(zhì)量,監(jiān)控中心只能選擇性的接收和播放各個(gè)移動(dòng)終端采集的視頻。所以,在救援過程中,營(yíng)救人員會(huì)根據(jù)現(xiàn)場(chǎng)的事態(tài)情況設(shè)定當(dāng)前緊急程度,監(jiān)控中心將根據(jù)事故的緩急程度為每一路視頻設(shè)定優(yōu)先級(jí),并根據(jù)優(yōu)先級(jí)選擇性的接收和播放各路終端的視頻數(shù)據(jù),如果出現(xiàn)突發(fā)的緊急事件,營(yíng)救人員可以直接通過語音呼叫請(qǐng)求指揮人員與自己進(jìn)行視頻通信。指揮人員可以通過當(dāng)前在線列表更換自己需要觀看的視頻,也可以進(jìn)入其中的某一路觀看此路視頻的詳細(xì)畫面和詳細(xì)信息。
在傳統(tǒng)的監(jiān)控中心設(shè)計(jì)過程中,為了減少計(jì)算開銷,只用開辟一個(gè)端口串行接收所有終端或者多個(gè)終端的數(shù)據(jù)量,將數(shù)據(jù)統(tǒng)一存入一個(gè)緩存里,然后在解碼播放的時(shí)候提取數(shù)據(jù)通過特征信息分離識(shí)別,將數(shù)據(jù)送到對(duì)應(yīng)的播放窗口,這種做法對(duì)于接收不需要達(dá)到高清晰度的監(jiān)控系統(tǒng)是比較合理的,但是卻不利于高清視頻的完整傳輸,當(dāng)單位時(shí)間內(nèi)監(jiān)控端的接收數(shù)據(jù)量比所有視頻終端發(fā)送的數(shù)據(jù)量小時(shí),很容易造成較大的丟包率,最終必然導(dǎo)致畫面失真,且該方法容易出現(xiàn)串?dāng)_造成畫面的混亂。在本發(fā)明中,考慮到視頻的質(zhì)量問題,視頻采集頻率設(shè)置到8000Hz以上,采樣率越高圖像越清晰,而數(shù)據(jù)量也就越龐大,因此,當(dāng)某一路視頻被監(jiān)控指揮人員設(shè)定為接收狀態(tài)時(shí),本發(fā)明中的視頻接收采用并行接收模式,為該路視頻設(shè)定單獨(dú)的接收線程、接收緩存以及解碼播放線程,可以在保證視頻的高質(zhì)量性的同時(shí)降低接收時(shí)延和丟包率。
本發(fā)明移動(dòng)通信終端是在基于達(dá)芬奇數(shù)字圖像處理技術(shù)的嵌入式開發(fā)平臺(tái)上加以實(shí)現(xiàn)。目前,較為流行的DM37x/AM37x系列是高性能、增強(qiáng)型數(shù)字媒體處理器,這種架構(gòu)提供了豐富的外設(shè)接口,充分滿足用戶對(duì)網(wǎng)口、S-VIDEO接口、音頻輸入輸出接口、USB等各種接口的需求,此架構(gòu)主要被用于ARM和圖形演示,具有低功耗的優(yōu)點(diǎn)。典型代表是DM3730/AM3715處理器,該處理器集成了高主頻的ARM內(nèi)核以及具有高級(jí)數(shù)字信號(hào)處理能力的DSP核。
在進(jìn)行視頻采集時(shí),首先打開視頻操作獲取設(shè)備狀態(tài)并檢測(cè)設(shè)備的狀態(tài)是否可以被激活。然后再以讀寫、非阻塞模式打開設(shè)備,查詢?cè)O(shè)備是否支持V412編程,枚舉此設(shè)備支持的視頻格式和視頻大小,最后設(shè)置系統(tǒng)需要的視頻格式及大小,將視頻格式設(shè)置為YUV格式,圖像高度為240,圖像寬度為320。
DM37x/AM37x系列平臺(tái)所提供的攝像頭接口ISP兼容了CCD工業(yè)攝像頭和CMOS數(shù)字?jǐn)z像頭,同時(shí)支持BT.601、BT.656制式。2D/3D圖形加速的底層加快了2D和3D的圖形應(yīng)用速度,其SGX底層是基于新一代可編程的POWERVR圖形核,這種架構(gòu)具有可伸展性。
在設(shè)備中申請(qǐng)一個(gè)空的視頻緩存區(qū)域隊(duì)列并保存隊(duì)列的相關(guān)信息,同時(shí)將獲取到的實(shí)際隊(duì)列長(zhǎng)度里的值提取出來,該長(zhǎng)度一般不能超過五個(gè)視頻緩存區(qū),然后為每個(gè)視頻緩存區(qū)所在的內(nèi)核空間申請(qǐng)內(nèi)存,申請(qǐng)完的內(nèi)核空間需要映射到用戶空間。最后,申請(qǐng)相同個(gè)數(shù)的RGB圖像緩沖區(qū),用于在終端上的顯示。
在移動(dòng)通信終端中用于顯示的主要在LCD或者TV接口下提供存儲(chǔ)幀緩存的邏輯視頻圖像,底層模塊包括:顯示控制模組、遠(yuǎn)程幀緩沖接口模組、顯示串行接口的I/O模塊和DSI協(xié)議引擎、DSI PLL控制器驅(qū)動(dòng)以及NTSC/PAL視頻編碼。NTSC與PAL是兩種不同的電視標(biāo)準(zhǔn),其中,適用于中國(guó)與歐洲的是PAL標(biāo)準(zhǔn),考慮到與國(guó)內(nèi)其他設(shè)備保持一致性,在移動(dòng)通信終端采用的是PAL標(biāo)準(zhǔn)。
通過事件驅(qū)動(dòng)機(jī)制將采集到的圖像數(shù)據(jù)將保存到一個(gè)開辟了10幀大小的YUV圖像緩沖隊(duì)列中,其中開辟的每幀圖像的最大緩沖區(qū)大小為153600B。YUV圖像緩沖區(qū)中的每幀圖像將在視頻編碼線程中被調(diào)用。
視頻編碼采用的是基于達(dá)芬奇平臺(tái)的H264視頻編碼方案,該標(biāo)準(zhǔn)是建立在MPEG-4技術(shù)的基礎(chǔ)之上,編解碼流程大致可以分為五步:幀間和幀內(nèi)預(yù)測(cè)、變換和反變換、量化和反量化、環(huán)路濾波、熵編碼。與其它現(xiàn)有的視頻編碼標(biāo)準(zhǔn)相比,H.264標(biāo)準(zhǔn)在同等帶寬條件下對(duì)圖象的質(zhì)量具有更好的保障,且該標(biāo)準(zhǔn)在保證相同的圖象質(zhì)量前提下,其壓縮效率要比以前的標(biāo)準(zhǔn)高出2倍左右。
移動(dòng)通信終端使用的是DM9000的10/100M自適應(yīng)網(wǎng)絡(luò)接口,DM9000是低功耗、高度集成了快速以太網(wǎng)控制器與通用處理器的芯片,網(wǎng)絡(luò)接口包括一路10/100M PHY和4K DWORD SRAM,該芯片支持3.3V和5V的IO接口。其中,DM9000內(nèi)置的10/100M Ethernet模塊,它兼容了IEEE 802.3標(biāo)準(zhǔn)協(xié)議,網(wǎng)線接口為標(biāo)準(zhǔn)RJ45,可以通過直通網(wǎng)線連接到網(wǎng)絡(luò)hub上。
由于在視頻編碼過程中,每一幀數(shù)據(jù)分包后的每個(gè)子包放入到UDP發(fā)送隊(duì)列的時(shí)間間隔為5ms,為了實(shí)現(xiàn)將數(shù)據(jù)放入U(xiǎn)DP隊(duì)列和從UDP隊(duì)列取出數(shù)據(jù)的同步,視頻的發(fā)送間隔也設(shè)為5ms。
視頻數(shù)據(jù)最終通過LTE雙極化智能天線進(jìn)入LTE網(wǎng)絡(luò)中。雙極化智能天線使用一組雙極化輻射單元代替原有單極化輻射單元,并且陣列數(shù)量減少為原來的一半,以達(dá)到在保持端口總數(shù)不變的前提下,減小天線寬度的目的。雙極化智能天線在工程上通常采用+45與-45度輻射單元的排列方式,通過這種方式組成的雙極化N*2天線線陣,其中N為同極化輻射單元數(shù)目,根據(jù)目前理論研究、仿真和測(cè)試表明,優(yōu)先選擇N=4。
移動(dòng)通信終端的電源管理模塊包括電源管理控制器、USB高速傳輸控制、LED驅(qū)動(dòng)控制、模數(shù)轉(zhuǎn)換(ADC)、實(shí)時(shí)時(shí)鐘(RTC)和嵌入式時(shí)鐘管理(EPC)等。
本實(shí)施例的無線視頻傳輸是基于跨平臺(tái)設(shè)計(jì)的,發(fā)送端是在基于Linux操作系統(tǒng)的嵌入式開發(fā)板上實(shí)現(xiàn),而無線視頻傳輸系統(tǒng)的接收端是在基于Windows操作系統(tǒng)上的PC機(jī)或大型計(jì)算機(jī)上實(shí)現(xiàn)。通過MySQL結(jié)合MFC建立監(jiān)控中心的數(shù)據(jù)庫(kù)模塊,每一個(gè)在線終端一旦開機(jī)會(huì)自動(dòng)在監(jiān)控中心注冊(cè),監(jiān)控中心實(shí)時(shí)檢測(cè)在線列表。通過MFC中封裝的API以及相關(guān)的類實(shí)現(xiàn)數(shù)據(jù)的接收和線程的創(chuàng)建與控制,結(jié)合ffmpeg以及OpenCV實(shí)現(xiàn)視頻的解碼與播放。
圖4為移動(dòng)通信終端發(fā)送視頻的基本步驟,移動(dòng)通信終端采集到一幀數(shù)據(jù)之后,將其進(jìn)行編碼壓縮并以KByte為單位(K>0)分成若干個(gè)UDP包。在本發(fā)明的動(dòng)態(tài)圖像編碼過程中,將采集到的若干幅數(shù)據(jù)圖像分成P幀與I幀,I幀為數(shù)據(jù)畫面,是圖像的關(guān)鍵幀,P幀為參考幀,是由在它前面的P幀或者I幀預(yù)測(cè)而來,它與它前面的P幀或者I幀之間的相同信息或數(shù)據(jù)進(jìn)行比較,也即考慮運(yùn)動(dòng)的特性進(jìn)行幀間壓縮。采取P幀和I幀聯(lián)合壓縮的方法可達(dá)到更高的壓縮且無明顯的壓縮痕跡。
圖5表示監(jiān)控中心接收線程基本工作流程,該線程采用消息響應(yīng)機(jī)制達(dá)到無休眠、低時(shí)延的接收效果。一般情況下,工作子線程創(chuàng)建之后,必須使用循環(huán)機(jī)制維持其生存,但是無限的循環(huán)工作會(huì)一直占用運(yùn)算器,最終將導(dǎo)致系統(tǒng)崩潰,為了避免這類事件發(fā)生,在循環(huán)工作機(jī)制中需要加入休眠機(jī)制,緩解處理器的壓力,而對(duì)于實(shí)時(shí)傳輸系統(tǒng),加入休眠機(jī)制將會(huì)導(dǎo)致非常大的丟包率,最終表現(xiàn)為視頻畫面十分不連貫。本發(fā)明提供了一種實(shí)時(shí)傳輸子線程的創(chuàng)建方法,且該方法不需要休眠,當(dāng)有數(shù)據(jù)來臨時(shí),線程開始工作,沒有數(shù)據(jù)來臨時(shí)則不工作。
由微軟公司封裝的類庫(kù)MFC提供了豐富的類以及API,為監(jiān)控中心服務(wù)器軟件模塊的實(shí)現(xiàn)奠定了環(huán)境基礎(chǔ)。為了滿足更好的用戶體驗(yàn),當(dāng)現(xiàn)場(chǎng)情況不是很緊急或者涉及到個(gè)人隱私時(shí),營(yíng)救人員可以自行關(guān)閉視頻,一來可以節(jié)約終端的能量,二來可以為其他的移動(dòng)終端騰出接入點(diǎn)。這也就決定了移動(dòng)通信終端的視頻數(shù)據(jù)并不是時(shí)刻都有的。本發(fā)明通過創(chuàng)建繼承于Thread基類的派生類實(shí)現(xiàn)監(jiān)控中心的接收線程,相比于普通線程的實(shí)現(xiàn)方法,其優(yōu)勢(shì)在于:無需循環(huán)工作維持自身的生存,可以在線程中嵌入消息響應(yīng)機(jī)制,當(dāng)有視頻數(shù)據(jù)來臨時(shí),接收線程會(huì)實(shí)時(shí)接收數(shù)據(jù),當(dāng)沒有數(shù)據(jù)來臨時(shí),線程處于監(jiān)聽狀態(tài),等待數(shù)據(jù)到來,這樣也就省去了休眠機(jī)制,減少這種特性迎合了實(shí)時(shí)通信中低時(shí)延和低丟包率的需求。
如圖7所示,在主線程中通過AfxBeginThread創(chuàng)建一個(gè)獨(dú)立的線程,該線程中聲明并定義一個(gè)創(chuàng)建套接字端口的執(zhí)行函數(shù)。創(chuàng)建一個(gè)由MFC的Socket類衍生的派生類,聲明并定義其接收響應(yīng)函數(shù),在該函數(shù)中寫入和發(fā)送終端保持一致性的接收函數(shù)。然后在接收線程中聲明一個(gè)Socket派生類的指針變量,在開啟監(jiān)聽的地方new一個(gè)Socket派生類的對(duì)象,用此對(duì)象在前面創(chuàng)建的接收線程函數(shù)中創(chuàng)建端口號(hào),再綁定一個(gè)SOCKADDR_IN的對(duì)象,指定發(fā)送端地址是任意地址,只要發(fā)送端往主機(jī)所創(chuàng)建的接收端口上發(fā)送數(shù)據(jù),就會(huì)觸發(fā)該派生類的接收響應(yīng)函數(shù)接收數(shù)據(jù)。
在本發(fā)明的視頻傳輸中,存在兩種不同的緩存區(qū)域,第一是接收緩存區(qū)域BUFFER,第二是解碼緩存區(qū)域buffer。接收緩存是一個(gè)容量足夠大的環(huán)形BUFFER,接收數(shù)據(jù)包一律存放在同一個(gè)環(huán)形BUFFER中,由于在存放數(shù)據(jù)的節(jié)點(diǎn)上均有對(duì)應(yīng)窗口號(hào)的標(biāo)識(shí),解碼線程在訪問該BUFFER時(shí)只需按照標(biāo)識(shí)將數(shù)據(jù)解碼到對(duì)應(yīng)的播放緩存中去。由于視頻數(shù)據(jù)的接收、解碼與播放線程均是不同步的,為了防止解碼之后的數(shù)據(jù)發(fā)生丟失,本發(fā)明在每一路視頻解碼之后的分配一個(gè)較小的乒乓buffer,其結(jié)構(gòu)如圖8所示,解碼線程將解好的幀數(shù)據(jù)存放在一個(gè)緩沖單元里,當(dāng)該緩沖單元存滿之后,解碼線程開始將數(shù)據(jù)存入另一個(gè)緩沖單元,而播放線程開始從前面的緩沖單元中讀取數(shù)據(jù),兩個(gè)線程交替訪問兩個(gè)緩沖單元,使每一幀視頻數(shù)據(jù)完整的顯示在對(duì)應(yīng)的窗口中。由于視頻數(shù)據(jù)包遵循先進(jìn)先出的讀寫順序,所以環(huán)形BUFFER實(shí)際上是一個(gè)FIFO,其最小深度為:
Delph=B_Length-(B_Length/w_clk)*(Numclk/Wlength)*(r_clk/w_clk)其中,B_Length表示突發(fā)寫入的數(shù)據(jù)長(zhǎng)度;w_clk表示寫周期時(shí)鐘;r_clk表示讀周期時(shí)鐘;Numclk表示寫周期時(shí)鐘個(gè)數(shù);Wlength表示Numclk個(gè)寫時(shí)鐘周期內(nèi)寫入的數(shù)據(jù)長(zhǎng)度;
由于人眼的識(shí)別能力是在25ms以外,因此在解碼與播放過程中延遲1毫秒,對(duì)于人的觀察而言是沒有任何影響的,如圖5所示,為了減小解碼線程與播放的復(fù)雜度,減小處理器的計(jì)算開銷,直接使用Windows自帶的API創(chuàng)建解碼線程和播放線程,并使用while(1)維持線程的生存,使用sleep(1)分割線程周期,避免系統(tǒng)CPU被一直占用。
按照前面的兩步驟依次創(chuàng)建接收線程、接收緩存、解碼線程和播放線程。為預(yù)先設(shè)定為接收狀態(tài)的每一個(gè)終端開辟接收端口,監(jiān)控中心根據(jù)應(yīng)急程度選擇性的接收并播放該視頻。
最后說明的是,以上優(yōu)選實(shí)施例僅用以說明本發(fā)明的技術(shù)方案而非限制,盡管通過上述優(yōu)選實(shí)施例已經(jīng)對(duì)本發(fā)明進(jìn)行了詳細(xì)的描述,但本領(lǐng)域技術(shù)人員應(yīng)當(dāng)理解,可以在形式上和細(xì)節(jié)上對(duì)其作出各種各樣的改變,而不偏離本發(fā)明權(quán)利要求書所限定的范圍。