本發(fā)明涉及視頻監(jiān)控中的數(shù)據(jù)傳輸方法，尤其是一種混合協(xié)議數(shù)據(jù)統(tǒng)一化輸出的視頻傳輸方法。
背景技術(shù)：
：隨著城市化進(jìn)程的快速發(fā)展以及社會(huì)治安體系的不斷健全，視頻監(jiān)控在社會(huì)中發(fā)揮的作用日益重要，交通道路監(jiān)控和公安治安監(jiān)控是視頻監(jiān)控的兩大用武之地，由于用途不同，同一地區(qū)的交通部門(mén)與公安部門(mén)通常有各自視頻監(jiān)控平臺(tái)，不同地區(qū)之間一般也都有自己各自的監(jiān)控平臺(tái)，另外每個(gè)地區(qū)的監(jiān)控設(shè)備都是分批次逐步更新的，設(shè)備型號(hào)不同，由于這些歷史原因，無(wú)論是監(jiān)控平臺(tái)還是監(jiān)控設(shè)備都不可能實(shí)現(xiàn)一次性統(tǒng)一建設(shè)與更新?lián)Q代。一方面，隨著社會(huì)協(xié)作化的進(jìn)步，資源需要合理整合與共享，以實(shí)現(xiàn)最大利用率。視頻資源的整合就是一個(gè)重要環(huán)節(jié)，不同部門(mén)和地區(qū)之間的資源共享可以大大提高社會(huì)的安定與高效；就視頻監(jiān)控平臺(tái)而言，不同平臺(tái)和設(shè)備分別采用不同的視頻傳輸協(xié)議，其中主要包括國(guó)標(biāo)協(xié)議(GB/T28181)和私有協(xié)議等，要整合這些平臺(tái)設(shè)備資源，必須對(duì)這兩種協(xié)議進(jìn)行混合處理，使其具有公共的屬性。另一方面，私有協(xié)議的視頻傳輸中，為了保證一些協(xié)商數(shù)據(jù)(如視頻頭)的完整性，大多采用TCP方式，而TCP方式雖然能夠保證數(shù)據(jù)完整性，卻由于連接過(guò)程復(fù)雜，不適用于實(shí)時(shí)性較高的應(yīng)用場(chǎng)景；而國(guó)標(biāo)協(xié)議則是規(guī)定了只能用UDP方式傳輸視頻數(shù)據(jù)，這樣就保證了數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性和傳輸效率，適用于大部分的安防監(jiān)控場(chǎng)景，但是卻不能滿(mǎn)足對(duì)數(shù)據(jù)完整性要求較高的場(chǎng)景，當(dāng)前國(guó)標(biāo)標(biāo)準(zhǔn)GB/T28181-2011補(bǔ)充協(xié)議(2014年發(fā)布)尚未支持TCP方式的視頻傳輸方式，而正在草擬的GB/T28181最新標(biāo)準(zhǔn)已經(jīng)在為T(mén)CP支持征求意見(jiàn)，雖然標(biāo)準(zhǔn)還在草擬階段，TCP方式的國(guó)標(biāo)傳輸也沒(méi)有權(quán)威的解決方案，但是由此可以看出，國(guó)標(biāo)協(xié)議的UDP/TCP多種傳輸方式支持已經(jīng)成為大勢(shì)所趨。專(zhuān)利公布號(hào)[CN104954764A]基于視頻資源安全網(wǎng)關(guān)的視頻監(jiān)控系統(tǒng)中提出通過(guò)協(xié)議轉(zhuǎn)碼和視頻轉(zhuǎn)碼的方式將非國(guó)標(biāo)設(shè)備(私有協(xié)議)無(wú)縫接入到SIP(國(guó)標(biāo))服務(wù)器，實(shí)現(xiàn)不同協(xié)議的混合接入，該方法是本領(lǐng)域人員較容易想到的方法，但是在實(shí)際環(huán)境中卻很難實(shí)現(xiàn)，一方面對(duì)非國(guó)標(biāo)設(shè)備的視頻轉(zhuǎn)碼是一項(xiàng)消耗資源的方法，往往需要另外添加硬件轉(zhuǎn)碼服務(wù)器，對(duì)成本影響較大；另一方面，由于監(jiān)控設(shè)備的參差不同，有相當(dāng)部分的早期非國(guó)標(biāo)設(shè)備不支持國(guó)標(biāo)轉(zhuǎn)碼，即使是支持國(guó)標(biāo)轉(zhuǎn)碼的新設(shè)備，不同廠家的轉(zhuǎn)碼規(guī)則也都不同，對(duì)于接入不同廠家設(shè)備的大規(guī)模視頻監(jiān)控平臺(tái)并不適用。技術(shù)實(shí)現(xiàn)要素：為了克服已有視頻監(jiān)控?cái)?shù)據(jù)傳輸方式實(shí)現(xiàn)不同協(xié)議混合接入時(shí)實(shí)現(xiàn)困難、成本較高、適用性較差的不足，本發(fā)明提供一種實(shí)現(xiàn)簡(jiǎn)便、成本較低、適用性良好的混合協(xié)議數(shù)據(jù)統(tǒng)一化輸出的視頻傳輸方法。本發(fā)明解決其技術(shù)問(wèn)題所采用的技術(shù)方案是：一種混合協(xié)議數(shù)據(jù)統(tǒng)一化輸出的視頻傳輸方法，基本實(shí)施環(huán)境包括下級(jí)數(shù)據(jù)接入平臺(tái)或設(shè)備、數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器和客戶(hù)端；所述下級(jí)數(shù)據(jù)接入平臺(tái)或設(shè)備接收下屬設(shè)備采集的視頻流并發(fā)送給數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器，視頻數(shù)據(jù)接入方式包括私有數(shù)據(jù)以TCP協(xié)議方式接入和國(guó)標(biāo)數(shù)據(jù)以UDP協(xié)議方式接入；所述數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器接收下級(jí)數(shù)據(jù)接入平臺(tái)或設(shè)備發(fā)送的視頻數(shù)據(jù)，私有數(shù)據(jù)以TCP協(xié)議方式接入，國(guó)標(biāo)數(shù)據(jù)以UDP協(xié)議方式接入；并根據(jù)客戶(hù)端發(fā)送的視頻傳輸方式請(qǐng)求，對(duì)視頻數(shù)據(jù)進(jìn)行協(xié)議混合處理，對(duì)數(shù)據(jù)的RTP協(xié)議頭進(jìn)行統(tǒng)一的重新定義和拆分處理，在當(dāng)前私有數(shù)據(jù)通過(guò)TCP協(xié)議傳輸和國(guó)標(biāo)數(shù)據(jù)通過(guò)UDP協(xié)議傳輸兩種方式的基礎(chǔ)上，增加私有數(shù)據(jù)通過(guò)UDP協(xié)議傳輸和國(guó)標(biāo)數(shù)據(jù)通過(guò)TCP協(xié)議傳輸兩種視頻數(shù)據(jù)傳輸方式，進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)；所述客戶(hù)端根據(jù)當(dāng)前應(yīng)用場(chǎng)景及網(wǎng)絡(luò)負(fù)載情況，選擇視頻傳輸方式并發(fā)送請(qǐng)求至數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器，獲取視頻數(shù)據(jù)，進(jìn)行解碼播放操作。作為優(yōu)選，當(dāng)所述數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器接收到TCP傳輸請(qǐng)求后，對(duì)于接收到的國(guó)標(biāo)數(shù)據(jù)，保留第一個(gè)數(shù)據(jù)包的RTP協(xié)議頭用于接收端解析，后續(xù)包則去除RTP協(xié)議頭，組成連續(xù)的視頻流數(shù)據(jù)，通過(guò)TCP協(xié)議發(fā)送給客戶(hù)端；對(duì)于接收到的私有數(shù)據(jù)，加入數(shù)據(jù)緩存機(jī)制，將視頻數(shù)據(jù)緩存在隊(duì)列中，并取出固定長(zhǎng)度的數(shù)據(jù)，添加RTP協(xié)議頭，用于視頻流的描述，封裝為國(guó)標(biāo)格式后以固定包長(zhǎng)進(jìn)行發(fā)送。當(dāng)所述數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器接收到UDP傳輸請(qǐng)求后，對(duì)于接收到的國(guó)標(biāo)數(shù)據(jù)，則直接轉(zhuǎn)發(fā)給客戶(hù)端；對(duì)于接收到的私有數(shù)據(jù)，將視頻數(shù)據(jù)緩存在隊(duì)列中，并取出固定長(zhǎng)度的數(shù)據(jù)，添加RTP協(xié)議頭，用于視頻流的描述，封裝為國(guó)標(biāo)格式后以固定包長(zhǎng)進(jìn)行發(fā)送。作為優(yōu)選，所述私有數(shù)據(jù)添加的RTP協(xié)議頭為12個(gè)字節(jié)，其中定義PT字段中100-127的值為不同的私有廠家。作為優(yōu)選，私有數(shù)據(jù)傳輸時(shí)，對(duì)于含視頻頭的廠家數(shù)據(jù)，第一個(gè)包取出視頻頭，添加RTP頭然后填充無(wú)效數(shù)據(jù)使總長(zhǎng)度達(dá)到固定包長(zhǎng)，然后發(fā)送，其他廠商數(shù)據(jù)則直接取固定長(zhǎng)度數(shù)據(jù)添加RTP協(xié)議頭后發(fā)送，后續(xù)包則都以固定包長(zhǎng)發(fā)送。作為優(yōu)選，私有數(shù)據(jù)通過(guò)UDP協(xié)議傳輸時(shí)，在后續(xù)數(shù)據(jù)包的起始位置添加2個(gè)字節(jié)的序列號(hào)字段，序列號(hào)編碼順序?yàn)?-65536，依次遞增，用于接收端對(duì)數(shù)據(jù)進(jìn)行丟包處理及亂序重組。作為優(yōu)選，所述客戶(hù)端發(fā)送TCP傳輸請(qǐng)求后，首先接收一個(gè)固定長(zhǎng)度的數(shù)據(jù)包，取出RTP協(xié)議頭，并解析出PT的值，如果PT＝96，則代表視頻流為國(guó)標(biāo)標(biāo)準(zhǔn)流，剩余的視頻流數(shù)據(jù)直接發(fā)送給國(guó)標(biāo)通用播放器模塊中，后續(xù)數(shù)據(jù)包也都直接發(fā)送到播放器模塊進(jìn)行解碼播放操作。如果PT≠96，則為私有數(shù)據(jù)流，找出對(duì)應(yīng)廠家，然后將剩余視頻流數(shù)據(jù)分別送入對(duì)應(yīng)廠家的播放器模塊，如果該廠家是含有視頻頭的，則在第一個(gè)包的數(shù)據(jù)中取出RTP協(xié)議頭后視頻頭長(zhǎng)度的數(shù)據(jù)送入播放器的解析接口，并將后續(xù)數(shù)據(jù)送入解碼接口進(jìn)行解碼播放操作。所述客戶(hù)端發(fā)送UDP傳輸請(qǐng)求后，首先接收到一個(gè)完整數(shù)據(jù)包，取出RTP協(xié)議頭，并解析出PT的值，如果PT＝96，則代表視頻流為國(guó)標(biāo)標(biāo)準(zhǔn)流，按照當(dāng)前國(guó)標(biāo)標(biāo)準(zhǔn)對(duì)每一個(gè)數(shù)據(jù)包都進(jìn)行RTP協(xié)議頭的解析，并把剩余視頻流數(shù)據(jù)送入通用國(guó)標(biāo)播放器模塊進(jìn)行解碼播放操作。如果PT≠96，則為私有數(shù)據(jù)流，找出對(duì)應(yīng)廠家，然后將剩余視頻流數(shù)據(jù)分別送入對(duì)應(yīng)廠家的播放器模塊，如果該廠家是含有視頻頭的，則在第一個(gè)包的數(shù)據(jù)中取出RTP協(xié)議頭后視頻頭長(zhǎng)度的數(shù)據(jù)送入播放器的解析接口，后續(xù)數(shù)據(jù)包則先解析出前2個(gè)字節(jié)的序列號(hào)，用于對(duì)數(shù)據(jù)包的丟包的處理與亂序重排，剩余其余數(shù)據(jù)則送入解碼接口進(jìn)行解碼播放操作。本發(fā)明的技術(shù)構(gòu)思為：在保證不同協(xié)議純視頻數(shù)據(jù)和對(duì)原協(xié)議支持不做改動(dòng)的前提下，對(duì)數(shù)據(jù)的特定位置進(jìn)行統(tǒng)一的重新定義和拆分等處理，并制定新的發(fā)送規(guī)則，使接收端在需要的時(shí)候按照約定規(guī)則對(duì)數(shù)據(jù)進(jìn)行重組和解析，即可以任何自己希望的傳輸方式得到希望的視頻數(shù)據(jù)。適用于將通過(guò)私有協(xié)議對(duì)接得到的私有視頻數(shù)據(jù)和通過(guò)國(guó)標(biāo)對(duì)接得到的標(biāo)準(zhǔn)視頻數(shù)據(jù)，經(jīng)過(guò)數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器封裝處理后，以統(tǒng)一化的方式與外界進(jìn)行數(shù)據(jù)對(duì)接，通過(guò)對(duì)當(dāng)前協(xié)議的修改完善，屏蔽下級(jí)協(xié)議類(lèi)型，數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器與接收方(客戶(hù)端或?qū)臃?wù)器)之間達(dá)成共識(shí)，接收方只需根據(jù)當(dāng)前網(wǎng)絡(luò)狀況配置TCP/UDP傳輸方式，即可得到需要的點(diǎn)位視頻數(shù)據(jù)，而不必提前知曉所需點(diǎn)位的設(shè)備廠家、協(xié)議類(lèi)型等信息，最終達(dá)到使混合協(xié)議接入的數(shù)據(jù)統(tǒng)一化輸出的目的；方案同時(shí)提出了國(guó)標(biāo)TCP傳輸較為實(shí)用的解決方案，為正在修訂的國(guó)標(biāo)新標(biāo)準(zhǔn)中該意見(jiàn)的征集提供一定的參考。本發(fā)明的有益效果主要表現(xiàn)在：1、對(duì)TCP傳輸?shù)乃接辛鲾?shù)據(jù)參考國(guó)標(biāo)方式進(jìn)行統(tǒng)一包裝與分割，同時(shí)利用國(guó)標(biāo)規(guī)定的RTP協(xié)議頭中現(xiàn)有的PT字段對(duì)私有流所屬?gòu)S家進(jìn)行映射，將國(guó)標(biāo)協(xié)議與私有協(xié)議區(qū)分開(kāi)，這樣做的好處在于既能使私有流數(shù)據(jù)與國(guó)標(biāo)數(shù)據(jù)保持格式一致，又無(wú)需在當(dāng)前數(shù)據(jù)基礎(chǔ)上另外包裝私有協(xié)議信息，對(duì)于數(shù)據(jù)接收者，從只對(duì)國(guó)標(biāo)數(shù)據(jù)進(jìn)行RTP解析改為對(duì)所有數(shù)據(jù)進(jìn)行解析，然后根據(jù)規(guī)則進(jìn)一步的分類(lèi)處理即可，最大程度的簡(jiǎn)化附加規(guī)則，使TCP方式的私有流可以以類(lèi)似國(guó)標(biāo)的方式進(jìn)行UDP的傳輸；2、對(duì)于當(dāng)前國(guó)標(biāo)唯一支持的UDP方式傳輸?shù)臉?biāo)準(zhǔn)視頻流，則根據(jù)TCP數(shù)據(jù)連續(xù)性的特點(diǎn)進(jìn)行適當(dāng)?shù)母倪M(jìn)，保留第一個(gè)數(shù)據(jù)包的RTP頭用于協(xié)議和數(shù)據(jù)解析，取出后續(xù)包中的RTP頭，組成連續(xù)的視頻數(shù)據(jù)，并以固定包長(zhǎng)發(fā)送以適應(yīng)TCP傳輸特性，從而與簡(jiǎn)單包裝后的私有協(xié)議格式保持一致，實(shí)現(xiàn)國(guó)標(biāo)數(shù)據(jù)UDP到TCP的快速轉(zhuǎn)換，同時(shí)又不影響當(dāng)前國(guó)標(biāo)標(biāo)準(zhǔn)的UDP方式；3、本方案利用當(dāng)前私有流和國(guó)標(biāo)流傳輸方式中現(xiàn)有的特性，通過(guò)整合協(xié)商，將數(shù)據(jù)格式趨于統(tǒng)一，使客戶(hù)端在無(wú)需知曉底層連接方式的情況下，根據(jù)當(dāng)前應(yīng)用場(chǎng)景及網(wǎng)絡(luò)負(fù)載狀況，任意指定視頻傳輸方式以滿(mǎn)足需求，此方案不僅適用于客戶(hù)端與轉(zhuǎn)發(fā)服務(wù)器的對(duì)接，更可用于轉(zhuǎn)發(fā)服務(wù)器與外部平臺(tái)的數(shù)據(jù)對(duì)接，進(jìn)而擴(kuò)展至多級(jí)平臺(tái)之間的對(duì)接，不僅有效地實(shí)現(xiàn)了協(xié)議間的靈活搭配，也可以為當(dāng)前正在草擬的新GB/T28181標(biāo)準(zhǔn)提供一種現(xiàn)實(shí)可行的參考方案。4、本方案是采用數(shù)據(jù)規(guī)則統(tǒng)一化的方式實(shí)現(xiàn)國(guó)標(biāo)數(shù)據(jù)和私有數(shù)據(jù)的混合統(tǒng)一化輸出，避免了采用視頻轉(zhuǎn)碼等方式造成的成本增加，是一種較為經(jīng)濟(jì)實(shí)用的方法。5、本方案的所有數(shù)據(jù)協(xié)議處理方式都是在保持原始數(shù)據(jù)協(xié)議與傳輸方式基本不變的前提下進(jìn)行的，如果客戶(hù)端不需要擴(kuò)展至協(xié)議混合傳輸或者外部接收端不了解本方案的數(shù)據(jù)協(xié)議規(guī)則，則只需要按照原始的協(xié)議方式進(jìn)行請(qǐng)求即可，如接收端以現(xiàn)在國(guó)標(biāo)規(guī)定的UDP方式對(duì)接國(guó)標(biāo)數(shù)據(jù)時(shí)，不需要做任何的協(xié)商，轉(zhuǎn)發(fā)服務(wù)器對(duì)于UDP方式的國(guó)標(biāo)數(shù)據(jù)采用直接轉(zhuǎn)發(fā)的方式，接收端只需按照正常流程進(jìn)行對(duì)接即可。附圖說(shuō)明圖1是本發(fā)明方案的系統(tǒng)架構(gòu)圖，其中(a)為基本架構(gòu)圖，(b)為方案預(yù)期效果架構(gòu)圖。圖2是本發(fā)明方案的數(shù)據(jù)發(fā)送圖。圖3是本發(fā)明方案的數(shù)據(jù)接收?qǐng)D。圖4是字段格式的示意圖。圖5是添加過(guò)RTP后的私有數(shù)據(jù)起始包的示意圖。圖6是起始包包裝前的示意圖。圖7是起始包包裝后的示意圖。具體實(shí)施方式下面結(jié)合附圖對(duì)本發(fā)明作進(jìn)一步描述。參照?qǐng)D1～圖7，一種混合協(xié)議數(shù)據(jù)統(tǒng)一化輸出的視頻傳輸方法，實(shí)施環(huán)境包括前端采集設(shè)備、下級(jí)視頻服務(wù)器、數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器、和客戶(hù)端(或?qū)臃?wù)器)，其中下級(jí)視頻服務(wù)器將從前端設(shè)備采集到的視頻數(shù)據(jù)以國(guó)標(biāo)協(xié)議和私有協(xié)議兩種方式接入到數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器，數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器通過(guò)對(duì)接收到的數(shù)據(jù)進(jìn)行協(xié)議混合處理，最終以可自由配置的方式提供給客戶(hù)端或上級(jí)對(duì)接服務(wù)器，使其最終獲取到需要的視頻流數(shù)據(jù)，即實(shí)現(xiàn)從圖1-(a)到圖1-(b)的轉(zhuǎn)變；如圖2所示，數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器接收到下級(jí)服務(wù)器的視頻數(shù)據(jù)，其中私有數(shù)據(jù)以TCP方式接入，國(guó)標(biāo)數(shù)據(jù)以UDP方式接入，這是當(dāng)前大部分廠商主要支持的接入方式，尤其是國(guó)標(biāo)方式，在新的GB/T28181標(biāo)準(zhǔn)出臺(tái)之前，只能支持UDP+RTP的方式接入；轉(zhuǎn)發(fā)服務(wù)器再根據(jù)客戶(hù)端的指定選擇傳輸類(lèi)型，當(dāng)客戶(hù)端選擇TCP傳輸時(shí)，需要對(duì)兩種數(shù)據(jù)分別進(jìn)行處理：對(duì)于國(guó)標(biāo)數(shù)據(jù)，為了將傳輸效率優(yōu)先且數(shù)據(jù)包獨(dú)立傳輸?shù)腢DP特性與數(shù)據(jù)完整性?xún)?yōu)先且數(shù)據(jù)包連續(xù)的TCP特性相兼容，實(shí)施例中將第一個(gè)數(shù)據(jù)包的RTP保留，用于接收者進(jìn)行視頻的解析，其中的PT(payloadtype)字段代表荷載類(lèi)型,在國(guó)標(biāo)協(xié)議中已經(jīng)默認(rèn)為96，接收者在接收到視頻流后，可以據(jù)此判斷此視頻流為國(guó)標(biāo)數(shù)據(jù)，并對(duì)其進(jìn)行處理，對(duì)于后續(xù)的國(guó)標(biāo)數(shù)據(jù)包則去除前12個(gè)字節(jié)的RTP頭后通過(guò)TCP發(fā)送給客戶(hù)端，客戶(hù)端接收到的為多個(gè)包連接的數(shù)據(jù)，或者是被網(wǎng)絡(luò)拆分后的包數(shù)據(jù)，由于此時(shí)已去除RTP頭，所以為純視頻數(shù)據(jù)，不受TCP傳輸時(shí)網(wǎng)絡(luò)拆分的影響，接收者可以依次送入解碼模塊；對(duì)于私有數(shù)據(jù)，由于本身就是通過(guò)TCP接入的，所以不用考慮后續(xù)數(shù)據(jù)拆分與重新組包的影響，但是為了使客戶(hù)端可以區(qū)分?jǐn)?shù)據(jù)的性質(zhì)，實(shí)施例中將國(guó)標(biāo)標(biāo)準(zhǔn)加入12字節(jié)的RTP協(xié)議頭，使其在格式上與國(guó)標(biāo)數(shù)據(jù)保持一致，并根據(jù)RFC3550標(biāo)準(zhǔn)中的RTP描述進(jìn)行時(shí)間戳、標(biāo)志位、序列號(hào)等字段填充，其描述如圖4所示。由于PT字段中96-127之間的值在標(biāo)準(zhǔn)中未被定義，實(shí)施例中將其填充為私有廠家的類(lèi)型，同時(shí)與國(guó)標(biāo)中默認(rèn)的值96相對(duì)應(yīng)，其定義如表1：廠家類(lèi)型國(guó)標(biāo)廠家A廠家B廠家C…PT96100101102…表1添加過(guò)RTP后的私有數(shù)據(jù)起始包如圖5所示。其中框選區(qū)域內(nèi)的起始12個(gè)字節(jié)既為添加的RTP數(shù)據(jù)。為了保證數(shù)據(jù)長(zhǎng)度的一致，無(wú)論是TCP還是UDP傳輸，私有數(shù)據(jù)都采用固定數(shù)據(jù)大小進(jìn)行發(fā)送(國(guó)標(biāo)數(shù)據(jù)大小本身已有限制，無(wú)需另外拆分)，由于UDP傳輸?shù)腗TU限制，實(shí)施例中按照公式(1)設(shè)置固定包長(zhǎng)：PACK_SIZE＝MTU(1500)–IP頭(20)-UDP頭(8)＝1472公式(1)由于廠家私有流通常有包含視頻頭和不含視頻頭兩種，視頻頭的作用是用于廠商自己解碼模塊的視頻信息解析，客戶(hù)端需要在解碼視頻流數(shù)據(jù)前先傳入視頻頭，因此對(duì)于含有視頻頭的私有數(shù)據(jù)和不含視頻頭的私有數(shù)據(jù)起始包的組成如表2：表2以含有視頻頭的?？邓接幸曨l數(shù)據(jù)為例，實(shí)施例中對(duì)其起始包進(jìn)行了再包裝，包裝前由40字節(jié)的?？狄曨l頭和后續(xù)視頻數(shù)據(jù)組成，包裝后由RTP頭(12)+視頻頭(40)+無(wú)效填充數(shù)據(jù)(1420)組成。包裝前如圖6所示，包裝后如圖7所示。為了便于對(duì)私有數(shù)據(jù)進(jìn)行處理，需要對(duì)數(shù)據(jù)進(jìn)行緩存，為了最小程度的影響數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性，實(shí)施例中設(shè)置PACK_SIZE*5＝7360大小的緩存區(qū)，每次緩存5個(gè)固定包長(zhǎng)大小的數(shù)據(jù)；如圖2所示，當(dāng)客戶(hù)端選擇UDP傳輸時(shí)，同樣需要對(duì)兩種數(shù)據(jù)分別進(jìn)行處理：對(duì)于接收到的國(guó)標(biāo)數(shù)據(jù)，由于本身就是UDP方式，所以無(wú)需處理直接轉(zhuǎn)發(fā)給客戶(hù)端，客戶(hù)端根據(jù)當(dāng)前國(guó)標(biāo)協(xié)議方式進(jìn)行接收與解析；對(duì)于接收到的私有數(shù)據(jù)則采用與步驟2中私有數(shù)據(jù)的TCP傳輸基本相同的方式進(jìn)行處理，即封裝為國(guó)標(biāo)格式后以固定包長(zhǎng)進(jìn)行發(fā)送，保證在不同協(xié)議和不同傳輸方式之間能夠保持?jǐn)?shù)據(jù)格式的一致性，唯一不同的是，由于UDP傳輸?shù)牟豢煽啃?，在傳輸過(guò)程中會(huì)發(fā)生丟包和亂序現(xiàn)象，因此需要對(duì)每一個(gè)數(shù)據(jù)包的序列號(hào)進(jìn)行編碼，用于接收端對(duì)數(shù)據(jù)進(jìn)行丟包處理及亂序重組，對(duì)于國(guó)標(biāo)數(shù)據(jù)每個(gè)包前的RTP頭中已經(jīng)帶有序列信息，對(duì)于私有流，起始數(shù)據(jù)包已添加過(guò)RTP信息，我們只需要在后續(xù)數(shù)據(jù)包的起始位置添加2個(gè)字節(jié)的序列號(hào)字段，即序列號(hào)編碼順序?yàn)?-65536，依次遞增，包組成如下；如圖3所示，對(duì)于接收客戶(hù)端，當(dāng)發(fā)送了TCP傳輸請(qǐng)求后，建立TCP連接，首先持續(xù)接收至固定PACK_SIZE長(zhǎng)度的數(shù)據(jù)，并解析前出12個(gè)字節(jié)的RTP頭，存放在pBuffer[12]數(shù)組中，利用公式(2)計(jì)算出PT值：PT＝pBuffer[1]&0x7F公式(2)如果PT＝96，則代表視頻流為國(guó)標(biāo)標(biāo)準(zhǔn)流，將剩余的視頻流數(shù)據(jù)發(fā)送給國(guó)標(biāo)通用播放器模塊中，后續(xù)接收的數(shù)據(jù)包則直接發(fā)送到播放器模塊進(jìn)行解碼播放等操作；如果PT不等于96的視頻流，根據(jù)步驟2中的表1映射找出對(duì)應(yīng)廠家，然后將剩余視頻流數(shù)據(jù)送入對(duì)應(yīng)廠家的播放器模塊，如果該廠家是含有視頻頭的，則只取RTP頭后視頻頭長(zhǎng)度的數(shù)據(jù)(每個(gè)廠家的視頻頭長(zhǎng)度固定的)送入播放器的解析接口，后續(xù)接收的數(shù)據(jù)包則直接發(fā)送到該廠家對(duì)應(yīng)的播放器模塊進(jìn)行解碼播放等操作；如圖3所示，如果客戶(hù)端發(fā)送了UDP傳輸請(qǐng)求，首先接收第一個(gè)數(shù)據(jù)包，并解析出RTP協(xié)議頭，按照公式2得到PT類(lèi)型值，如果是國(guó)標(biāo)，則按照當(dāng)前國(guó)標(biāo)標(biāo)準(zhǔn)將剩余視頻數(shù)據(jù)送入國(guó)標(biāo)通用播放器模塊，并對(duì)于后續(xù)每個(gè)數(shù)據(jù)包做同樣的處理；如果為私有數(shù)據(jù)類(lèi)型，起始包的處理同對(duì)TCP的處理相同，后續(xù)數(shù)據(jù)包則先解析出前2個(gè)字節(jié)的序列號(hào)，用于對(duì)數(shù)據(jù)包的丟包的處理與亂序重排，剩余其余數(shù)據(jù)則送入解碼接口進(jìn)行解碼播放等操作。本發(fā)明的上述實(shí)施例中數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器將下級(jí)平臺(tái)(或設(shè)備)以不同協(xié)議接入的視頻數(shù)據(jù)，結(jié)合國(guó)標(biāo)與私有流各自的數(shù)據(jù)格式特性，TCP與UDP各自不同的數(shù)據(jù)傳輸特性，對(duì)數(shù)據(jù)和協(xié)議進(jìn)行統(tǒng)一化處理，最終實(shí)現(xiàn)不同視頻數(shù)據(jù)和傳輸協(xié)議之間的靈活轉(zhuǎn)換，使客戶(hù)端用戶(hù)可以根據(jù)當(dāng)前應(yīng)用場(chǎng)景中的設(shè)備和網(wǎng)絡(luò)現(xiàn)狀，對(duì)所有視頻點(diǎn)位的數(shù)據(jù)傳輸方式進(jìn)行自由配置，而不必關(guān)心該點(diǎn)位的底層接入信息，本發(fā)明的思路可以為GB/T28181最新標(biāo)準(zhǔn)的補(bǔ)充擴(kuò)展提供一定的參考價(jià)值。以上的所述乃是本發(fā)明的具體實(shí)施例及所運(yùn)用的技術(shù)原理，若依本發(fā)明的構(gòu)想所作的改變，其所產(chǎn)生的功能作用仍未超出說(shuō)明書(shū)及附圖所涵蓋的精神時(shí)，仍應(yīng)屬本發(fā)明的保護(hù)范圍。當(dāng)前第1頁(yè)1 2 3