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