本發(fā)明涉及在DSS框架下音視頻數(shù)據(jù)流通過TCP方式傳輸?shù)牟僮?，更具體說是涉及基于DSS分時系統(tǒng)的TCP方式中轉音視頻數(shù)據(jù)流的方法。

背景技術：

Darwin Streaming Server簡稱DSS。DSS是Apple公司提供的開源實時流媒體播放服務器程序，整個程序使用純粹C++編寫，在設計上遵循高性能、簡單、模塊化等程序設計原則，務求做到程序高效，可擴充性好，因此DSS服務器系統(tǒng)在跨平臺的支持上是相當理想的，它可以運行在Windows NT、Windows 2000及以上的windows內(nèi)核版本，同時也能良好的運行在*NIX的各種版本上，包括Mac OS X，Linux，F(xiàn)reeBSD，Solaris，同時DSS基于標準的流媒體協(xié)議RTSP，RTP/RTCP進行開發(fā)，因此在運用上具有極強的廣泛性和通用性。

在此基礎上，DSS框架設計成一個較為復雜的，層次結構較為清晰的流媒體服務器系統(tǒng)，主要由基礎功能組件（網(wǎng)絡，字符串處理，內(nèi)存開辟釋放，模塊工具，內(nèi)部錯誤消息定義，全局數(shù)據(jù)字典等等），各種子系統(tǒng)（RTSP，RTP，RTCP等等），各種功能插件（身份驗證，身份授權，數(shù)據(jù)流預處理，數(shù)據(jù)流處理，HTTP隧道處理，服務器消息回復等等）組合而成，很多開發(fā)人員主要會進行各種功能插件的開發(fā)，在服務器啟動的時候進行動態(tài)加載，當主流程狀態(tài)機處理到相應狀態(tài)的時候將調(diào)用對應的插件，此時服務器將控制權交給插件進行相應功能運作。因此，在這個基礎上從使用結構的角度上，服務器被分成兩個大塊，服務器內(nèi)部以及服務器外部，服務器內(nèi)部由各種基礎功能組件和子系統(tǒng)所組成，服務器外部由功能插件組成，這兩個部分之間通過函數(shù)指針設計成的API接口進行數(shù)據(jù)的交互以及基礎功能的實現(xiàn)。

然而，原始的DSS框架在音視頻數(shù)據(jù)流中轉以及反射上是采用UDP（用戶數(shù)據(jù)報協(xié)議）方式實現(xiàn)，并且是極具示范效果的實現(xiàn)，因此原始的DSS框架幾乎無法使用在實際工程項目之中。更為糟糕的是DSS框架也已經(jīng)停止支持不再更新，如果需要使用原始DSS框架的UDP方式進行數(shù)據(jù)流的傳輸處理必須解決以下幾個大問題：

1：NAT（網(wǎng)絡地址轉換）穿透，當基于TCP方式的RTSP（實時流傳輸協(xié)議）主動發(fā)送請求往音視頻源完成RTSP交互成功之后，音視頻將通過RTSP協(xié)商的端口開始首次傳輸基于UDP的RTP/RTCP數(shù)據(jù)包往服務器，此時將發(fā)生NAT問題，而且NAT具有4種不同方式，因此要針對4種不同方式進行處理，如果使用完全基于TCP方式的傳輸則不用考慮NAT問題，位于路由器后面的服務器上的RTSP客戶端主動發(fā)送之后將打通傳輸通道，RTP/RTCP碼流數(shù)據(jù)以及網(wǎng)絡控制數(shù)據(jù)也將沿著這條通道進行傳送；

2：ReliableRTP，基于UDP的碼流傳輸將繼承傳輸層UDP的特點，存在丟包、亂序等不可靠特性，因此需要服務器完成序列號檢測，序列號回繞，對系列號期望值判斷如果超出則需要進行丟包或者其它動作，對數(shù)據(jù)包重新排序進行組幀等可靠RTP傳輸行為，這些處理大大增加了服務器開發(fā)的復雜程度；

3：Congestion Control（擁塞控制），UDP并不是一個流量友好的協(xié)議，它不具備TCP中的通告窗口和滑動窗口，因此UDP無法進行發(fā)送端或者接收端流量控制，而是不停的往網(wǎng)絡中發(fā)送大量的音視頻數(shù)據(jù)包，輕則造成視頻非常卡頓，重則發(fā)送網(wǎng)絡擁塞導致同條路由癱瘓。而如果要基于UDP完成比較成熟的擁塞控制機制難度相當之大。

4：服務器結構管理困難，基于UDP的音視頻傳輸協(xié)議RTP/RTCP，需要對視頻流和音頻流分別開啟2個接收端口，一共是4個進行碼流接收，當只有幾個音視頻源的時候對于服務器系統(tǒng)資源影響不大，但是實際工程項目中往往具有成千上百個源頭，將大量耗費掉系統(tǒng)資源并且在進行業(yè)務控制的時候產(chǎn)生極大的困難，一旦前期規(guī)劃不好，后期幾乎無法推進項目。

有鑒于此，本發(fā)明綜合以上的DDS服務器特點以及使用UDP方式存在的各種問題，詳細設計了基于DSS分時系統(tǒng)的TCP方式中轉音視頻數(shù)據(jù)流的方法。

技術實現(xiàn)要素：

本發(fā)明的一個目的在于提供一種基于DSS分時系統(tǒng)的TCP方式中轉音視頻數(shù)據(jù)流的方法，其規(guī)避了NAT問題，提升了音視頻數(shù)據(jù)流中轉的穩(wěn)定性，占用服務器資源減少，音視頻數(shù)據(jù)傳輸更為流暢。

為了實現(xiàn)上述目的，本發(fā)明的技術方案如下：

一種基于DSS分時系統(tǒng)的TCP方式中轉音視頻數(shù)據(jù)流的方法，包括以下步驟：

步驟1、基于DSS框架設計TCP中轉插件，在TCP中轉插件中設計注冊角色、初始化角色、RTSP過濾角色、RTSP路由角色、RTSP提交處理角色和關閉角色，在TCP中轉插件中設計的各角色是該插件中具有高內(nèi)聚、低耦合的模塊，所有角色均在協(xié)議解析主流程被調(diào)用，其中注冊角色用于注冊當前插件中所有要具備的功能角色，初始化角色用于初始化當前插件需要用到的數(shù)據(jù)結構以及啟動RTSP客戶端任務，RTSP過濾角色用于過濾當前用戶請求指令是否是HTTP隧道方式，RTSP路由角色用于重定位當前用戶請求的目的，RTSP提交處理角色和關閉角色用于處理和回復當前用戶請求指令，RTSP關閉角色用于關閉/釋放掉當前用戶請求指令過程和資源；

步驟2、基于DSS框架設計TCP反射模塊插件，并在TCP反射模塊插件中注冊初始化角色、重讀配置文件角色、RTSP路由角色、RTSP預處理角色、RTSP碼流數(shù)據(jù)角色、客戶端會話關閉角色、關閉角色及RTSP認證角色；其中初始化角色用于注冊當前插件中所有要具備的功能角色，RTSP路由角色用于重定位當前用戶請求的目的，RTSP預處理角色用于預先判斷當前用戶請求是否合法，RTSP碼流數(shù)據(jù)角色用于對RTP/RTCP數(shù)據(jù)流進行處理，客戶端會話關閉角色用于關閉/釋放客戶端請求連接過程以及資源，關閉角色用于在服務器端關閉當前用戶請求連接的RTSP過程，RTSP認證角色用于在服務器配置文件設置了身份認證時對用戶請求連接進行身份認證；

TCP中轉插件根據(jù)數(shù)據(jù)存儲文件對音視頻源進行引流，將音視頻源轉往服務器，當服務器捕獲到音視頻數(shù)據(jù)流時，觸發(fā)TCP反射插件；所述數(shù)據(jù)存儲文件來自數(shù)據(jù)庫；

步驟4：TCP反射模塊插件在服務器捕捉到音視頻數(shù)據(jù)流時，對與用戶請求對應的數(shù)據(jù)庫中的音視頻數(shù)據(jù)流進行反射，從而完成音視頻數(shù)據(jù)流中轉。

優(yōu)選的，TCP中轉插件和TCP反射模塊插件中所有模塊角色的任務設計均為非阻塞類型。

優(yōu)選的，在所述步驟2之后步驟3之前還包括：基于DSS框架設計數(shù)據(jù)庫插件，在數(shù)據(jù)庫插件中的初始化角色中讀取數(shù)據(jù)庫中的音視頻源頭以及中轉目的相關信息保存在當前程序的地址空間中。

優(yōu)選的，所述步驟3中，TCP中轉插件根據(jù)數(shù)據(jù)存儲文件對音視頻源進行引流，將音視頻源轉往服務器，具體包括：

TCP中轉插件在執(zhí)行初始化角色模塊，始化角色創(chuàng)建RTSP數(shù)據(jù)源隊列用于存放音視頻源，初始化TCP中轉會話，將當前模塊作為一個屬性插入到系統(tǒng)統(tǒng)一配置的模塊屬性結構體中，讀取緩存中的音視頻源以及中轉目的相關信息；

TCP中轉插件中的初始化角色對RTSP數(shù)據(jù)源隊列進行檢查是否已經(jīng)被建立過引流鏈接，如果已經(jīng)建立則不再進行數(shù)據(jù)引流，如果沒有建立過則通過RTSP數(shù)據(jù)源中的元素獲取RTSP數(shù)據(jù)源信息類，啟動會話創(chuàng)建任務開始創(chuàng)建RTSP客戶端任務進行音視頻源引流。

優(yōu)選的，所述用戶在RTSP客戶端向TCP中轉插件提出請求過程具體包括：

用戶在RTSP客戶端使用標準的RTSP方式進行與TCP中轉插件指令交互，指令包括選擇指令和描述指令，選擇指令不發(fā)送探測指令，描述指令要對接收到的SDP協(xié)議包進行解析，獲取當前設備源具有的流信息；

將SDP信息保存在本地SDP文件中；

在TCP中轉插件中的初始化模塊啟動的RTSP客戶端過程中的Describe指令交互過程中解析成功SDP協(xié)議數(shù)據(jù)之后在描述指令過程中創(chuàng)建中轉會話以及反射會話，在創(chuàng)建反射會話中開辟當前設備源中具有的所有媒體流的信息空間，創(chuàng)建對應的RTP發(fā)送者和RTCP發(fā)送者；

當TCP中轉會話創(chuàng)建成功，則準備啟動中轉任務，將每個輸出目的添加進對應的輸出流中進行TCP中轉輸出，每條流對應著多個中轉目的；

在TCP中轉輸出中將啟動TCP中轉宣告任務，對這個任務的驅動使用時間片方式，每隔不低于10毫秒的時間片進行一次任務調(diào)用，調(diào)用任務過程中將清空可發(fā)送數(shù)據(jù)包隊列；

在RTSP交互過程中的SETUP指令階段，音視頻源使用TCP傳輸方式進行傳輸協(xié)商，最后發(fā)送播放指令指揮音視頻設備開始發(fā)送數(shù)據(jù)流；

在播放過程中讀取媒體流函數(shù)的永久循環(huán)過程中，對無效數(shù)據(jù)包進行跳出處理，以跳出RTSP客戶端過程；

TCP中轉插件中的初始化模塊中啟動的RTSP客戶端過程中的媒體流數(shù)據(jù)包處理函數(shù)對于每個處理好的數(shù)據(jù)包判斷是RTP或者RTCP類型，分別調(diào)用啟動反射會話中創(chuàng)建的UDP套接字類轉化成TCP反射套接字送入數(shù)據(jù)包處理函數(shù)進行處理，數(shù)據(jù)包處理函數(shù)將對數(shù)據(jù)包進入到對應發(fā)送者的發(fā)送數(shù)據(jù)包隊列中，這個隊列將在輸出的TCP中轉宣告任務中被調(diào)用。

進一步的，當讀取媒體流函數(shù)退出，需要在播放過程的結束返回一個時間值進行RTSP客戶端任務的自動調(diào)用運轉，該時間值不能低于10毫秒；

進一步的：在創(chuàng)建TCP中轉輸出過程中，根據(jù)數(shù)據(jù)庫或者配置文件中的中轉目的發(fā)送RTSP擴展指令宣告過程，對反射服務器的中轉目的進行宣告，并且宣告指令掛著LocalSDP協(xié)議數(shù)據(jù)，告訴反射服務器將要主動發(fā)送碼流數(shù)據(jù)信息，宣告指令還將攜帶標識當前視頻源碼流的唯一標識符；

宣告指令過程成功執(zhí)行之后，循環(huán)當前中轉會話攜帶的所有數(shù)據(jù)流，取出每條流中對應的TCP反射發(fā)送者，調(diào)用反射包函數(shù)開始進行中轉發(fā)送，所述TCP反射發(fā)送者分別對應著RTP發(fā)送者/RTCP發(fā)送者。

進一步的，進行中轉發(fā)送的音頻數(shù)據(jù)流不需要進行緩存設置，而是由中轉音頻數(shù)據(jù)流直接調(diào)用反射中轉包，在反射中轉包函數(shù)中取出每條流下所有的桶數(shù)量，桶中循環(huán)每個索引，取出所有的中轉隊列開始進行發(fā)送，對于每個發(fā)送目的，發(fā)送出在數(shù)據(jù)包隊列中所有的數(shù)據(jù)包。

進一步的，當TCP中轉輸出在執(zhí)行發(fā)送包函數(shù)的時候將會調(diào)用RTSP客戶端中的PutMediaPakcet函數(shù)，當這個函數(shù)返回值并不等于OS_NoErr的時候，將返回值設置成QTSS_WouldBlock，此時返回到反射中轉包函數(shù)將會對這個發(fā)生阻塞的數(shù)據(jù)包進行書簽設置，下一次進行TCP反射RelayPackets的時候將會首先尋找書簽包進行發(fā)送。

進一步的，當TCP中轉插件成功對音視頻源數(shù)據(jù)進行中轉以及主動推送宣告指令給TCP反射模塊的時候，服務器將執(zhí)行TCP反射模塊模塊中預先注冊的對應角色模塊；在RTSP指令交互階段當收到中轉模塊發(fā)送過來的宣告指令的時候TCP反射模塊中的RTSP預處理角色角色模塊將進行工作，保存宣告指令中攜帶的SDP消息于本地文件中。

進一步的，當TCP中轉插件模塊發(fā)送啟動指令過來的時候，TCP反射模塊中的RTSP預處理角色角色模塊將觸發(fā)DoSetup函數(shù)，這個函數(shù)將判斷啟動指令中是否需要推送的標志用于決定添加進客戶端會話中或者是發(fā)送目的隊列中，如果這是該宣告指令的流，則創(chuàng)建TCP反射會話，并且將這個會話存放進客戶端會話的sClientBroadcastSessionAttr中；

如果這是一條用戶終端連接進來的啟動指令，說明這個用戶終端是作為一個反射目的，需要被反射出流的，因此創(chuàng)建TCPRTP反射目的會話并且添加進TCP反射會話中；

如果這是一條由宣告開頭的指令進來的會話，在啟動TCP反射會話之前將這條流設置成需要緩存的會話類型；

如果這是一條用戶終端會話進來的，則在DoSetup的時候將會發(fā)現(xiàn)已經(jīng)具有此用戶終端要請求的會話標識，DoSessionSetup中的FindOrCreateSession函數(shù)將發(fā)現(xiàn)已經(jīng)存在請求會話，如果成功發(fā)現(xiàn)請求會話則將此用戶終端會話添加進Output將進行數(shù)據(jù)流反射。

進一步的，在FindOrCreateSession函數(shù)調(diào)用創(chuàng)建TCP反射會話函數(shù)中，對于CreateUDP套接字配對在TCP方式下注釋掉原DSS框架中的UDP地址復用過程，否則這個過程將導致在TCP方式下第二條媒體流SSRC發(fā)生沖突。

進一步的，當TCP中轉插件成功引流并且主動推送ANNOUNCE指令過程往反射服務器成功創(chuàng)建反射會話，則開始發(fā)送音視頻碼流數(shù)據(jù)，此時將觸發(fā)TCP反射模塊中的RTSP碼流數(shù)據(jù)角色角色模塊開始工作，這個角色模塊將調(diào)用PushPacket函數(shù)，區(qū)分RTP/RTCP數(shù)據(jù)包往對應的用戶終端；

PushPacket將觸發(fā)TCP反射套接字類中的Run任務，這個任務設計成IdleTask類型的任務，當具有外屆的連接進來的時候，將優(yōu)先處理外界連接，服務器線程池無任何其他任務的時候才進行碼流的持續(xù)推送；

當最終用戶以選擇指令連接方式發(fā)送進來的時候TCP反射插件將辨別是否已經(jīng)具有最終用戶請求的碼流標識，如果已經(jīng)存在需要請求的碼流會話，則將最終用戶作為一個輸出指令添加進去。

優(yōu)選的，所述引流、中轉和反射過程中，無論是否具有用戶終端的接入，引流和中轉過程持續(xù)進行。

采用上述方案后，本發(fā)明的有益效果是：

一、采用TCP方式中轉不用考慮NAT問題，位于路由器后面的服務器上的RTSP客戶端主動發(fā)送請求之后將打通傳輸通道，RTP/RTCP碼流數(shù)據(jù)以及網(wǎng)絡控制數(shù)據(jù)也將沿著這條通道進行傳送；

二、避免了丟包，亂序的問題；

三、通過TCP可發(fā)送大量的音視頻數(shù)據(jù)包，不會出現(xiàn)發(fā)送網(wǎng)絡擁塞導致同條路由癱瘓的情況，甚至杜絕了卡頓的現(xiàn)象；

四、對服務器需求程度降低，節(jié)省了服務器系統(tǒng)資源，提升業(yè)務控制效率。

以下結合附圖和具體實施方式對本發(fā)明做進一步說明。

附圖說明

圖1為本發(fā)明引流，中轉，反射總體流程圖。

圖2為中轉流程第一過程圖。

圖3為中轉流程第二過程圖。

圖4為中轉流程第三過程圖。

圖5為中轉流程第四過程圖。

圖6為反射流程第一過程圖。

圖7為反射流程第二過程圖。

圖8為用戶終端請求過程圖。

具體實施方式

如圖1所示，本發(fā)明揭示的一種基于DSS分時系統(tǒng)的TCP方式中轉音視頻數(shù)據(jù)流的方法，包括以下步驟：

步驟1、基于DSS框架設計TCP中轉插件，在TCP中轉插件中設計注冊角色、初始化角色、RTSP過濾角色、RTSP路由角色、RTSP提交處理角色和關閉角色，在TCP中轉插件中設計的各角色是該插件中具有高內(nèi)聚、低耦合的模塊，所有角色均在協(xié)議解析主流程被調(diào)用，其中注冊角色用于注冊當前插件中所有要具備的功能角色，初始化角色用于初始化當前插件需要用到的數(shù)據(jù)結構以及啟動RTSP客戶端任務，RTSP過濾角色用于過濾當前用戶請求指令是否是HTTP隧道方式，RTSP路由角色用于重定位當前用戶請求的目的，RTSP提交處理角色和關閉角色用于處理和回復當前用戶請求指令，RTSP關閉角色用于關閉/釋放掉當前用戶請求指令過程和資源；

步驟2、基于DSS框架設計TCP反射模塊插件，并在TCP反射模塊插件中注冊初始化角色、重讀配置文件角色、RTSP路由角色、RTSP預處理角色、RTSP碼流數(shù)據(jù)角色、客戶端會話關閉角色、關閉角色及RTSP認證角色；其中初始化角色用于注冊當前插件中所有要具備的功能角色，RTSP路由角色用于重定位當前用戶請求的目的，RTSP預處理角色用于預先判斷當前用戶請求是否合法，RTSP碼流數(shù)據(jù)角色用于對RTP/RTCP數(shù)據(jù)流進行處理，客戶端會話關閉角色用于關閉/釋放客戶端請求連接過程以及資源，關閉角色用于在服務器端關閉當前用戶請求連接的RTSP過程，RTSP認證角色用于在服務器配置文件設置了身份認證時對用戶請求連接進行身份認證；

TCP中轉插件根據(jù)數(shù)據(jù)存儲文件對音視頻源進行引流，將音視頻源轉往服務器，當服務器捕獲到音視頻數(shù)據(jù)流時，觸發(fā)TCP反射插件；所述數(shù)據(jù)存儲文件來自數(shù)據(jù)庫；

步驟4：TCP反射模塊插件在服務器捕捉到音視頻數(shù)據(jù)流時，對與用戶請求對應的數(shù)據(jù)庫中的音視頻數(shù)據(jù)流進行反射，從而完成音視頻數(shù)據(jù)流中轉。

以下為本實施例的詳細中轉流程：

如圖2所示為中轉流程第一部分的過程圖類的創(chuàng)建和方法函數(shù)調(diào)用過程，TCP中轉插件在進行初始化角色模塊的過程中會將音視頻源的地址信息和中轉目的信息進行存放進視頻源信息隊列中，通過調(diào)用會話查找函數(shù)來進行會話發(fā)現(xiàn)，如果隊列中的地址已經(jīng)建立起會話則返回，如果隊列中的地址還未建立會話則通過TCPRTSP音視頻源信息類中的會話創(chuàng)建任務函數(shù)創(chuàng)建引流會話的套接字過程，準備執(zhí)行對音視頻源進行碼流接收過程任務。這個任務執(zhí)行函數(shù)將觸發(fā)一系列標準的RTSP指令流程，當成功進行完DESCRIBE指令交互的過程之后，將調(diào)用SDPSourceInfo類中的解析函數(shù)方法對接收到的SDP協(xié)議數(shù)據(jù)包進行解析，分析出當前音視頻源具有的流信息進行保存，接著將當前音視頻源的SDP信息作為參數(shù)傳遞給TCP中轉會話類，調(diào)用SetupTCP中轉會話函數(shù)，最后根據(jù)中轉目的地址創(chuàng)建Output中轉添加進當前中轉會話中；

如圖3所示為中轉流程第二過程，TCP中轉會話繼承自DSS的反射會話類，因此在建立TCP中轉會話函數(shù)中除了進行一些常規(guī)新建模塊過程之外，主要將調(diào)用啟動反射會話函數(shù)進行工作，啟動反射會話將根據(jù)之前傳入的SDP協(xié)議數(shù)據(jù)包創(chuàng)建TCP反射流類，接著調(diào)用BindSockets創(chuàng)建很重要的中轉套接字，發(fā)送者管理器，以及SSRC標志，本發(fā)明中，對于中轉套接字將延用原DSS框架中的UDP方式數(shù)據(jù)傳輸?shù)慕Y構方法，但是在僅僅作為一個結構框架清晰的表明TCP方式下的每種數(shù)據(jù)流的傳輸方式，在原始DSS框架的UDP方式傳輸下，將對音視頻源所具有的每條Stream創(chuàng)建一對配套的UDP套接字配對，分別對應當前流的RTP和RTCP數(shù)據(jù)，同樣，在本發(fā)明中，TCP方式傳輸也將沿用這種邏輯層次結構，在創(chuàng)建完UDP套接字配對之后，對應著將創(chuàng)建發(fā)送者結構，并且添加進當前DSS框架的反射流類中，在綁定套接字函數(shù)的最后一個重要步驟將對每條具體的數(shù)據(jù)流（視頻流中的RTP或者RTCP，音頻流中的RTP或者RTCP）創(chuàng)建對應的SSRC唯一標識符；

如圖4所示為中轉流程第三過程，當創(chuàng)建中轉會話成功之后將創(chuàng)建中轉目的發(fā)送任務，這個任務將首次主動運行自己并且創(chuàng)建反射包函數(shù)預先開辟包，然后開始對中轉目的發(fā)送ANNOUNCE指令過程和反射服務器建立起聯(lián)系。

如圖5所示為中轉流程的第四個過程，7：當上述中轉過程全部建立好之后，RTSP客戶端（面向音視頻源，中轉中的Output任務將是面向反射服務器）將繼續(xù)推進到PLAY指令過程，這個過程將開始接收音視頻源的媒體流，讀取媒體流函數(shù)將執(zhí)行這個工作，其中主要調(diào)用GetMediaPacket來獲取媒體流中對應的音視頻流的RTP/RTCP數(shù)據(jù)包，對于每個成功的數(shù)據(jù)包，將調(diào)用對應的Stream下已經(jīng)事先開辟好的反射包函數(shù)數(shù)據(jù)包，拷貝進去，此時對于接收到的數(shù)據(jù)已經(jīng)通過內(nèi)存復制到中轉會話之中，等到中轉會話時間片的到達，將開始推送到中轉目的；

以下為本實施例詳細反射流程：

如圖6所示為反射流程第一過程：反射服務器（中轉目 的服務器）接收到ANNOUCNE指令之后將保存此指令所攜帶的SDP協(xié)議數(shù)據(jù)在本地文件，接著接收由中轉服務器發(fā)送過來的SETUP指令判斷當前是否為需要push的會話，中轉會話為需要push出去的會話則建立反射會話，創(chuàng)建的過程和中轉會話類似，一點不同在于需要對碼流數(shù)據(jù)進行緩存，如果為用戶終端會話則為不需要push的會話，此時關聯(lián)是否已經(jīng)存在請求會話標識，如果存在的話則添加進反射output，如果不存在的話則返回401資源未找到錯誤；

如圖7所示為反射流程第二過程：TCP反射模塊插件中的RTSP碼流數(shù)據(jù)角色角色模塊在主流程接收到媒體流的時候將被觸發(fā)調(diào)用，而不會進入到RTSP預處理角色流程中，因此這個角色模塊是處理實際媒體數(shù)據(jù)流的模塊，模塊將會解析媒體數(shù)據(jù)包是否正確，并且驅動反射包函數(shù)中的任務在系統(tǒng)IDLE的是時候開始運作。最終將對應的媒體數(shù)據(jù)流反射給相應終端用戶。

優(yōu)選的，TCP中轉插件和TCP反射模塊插件中所有模塊角色的任務設計均為非阻塞類型。

優(yōu)選的，在所述步驟2之后步驟3之前還包括：基于DSS框架設計數(shù)據(jù)庫插件，在數(shù)據(jù)庫插件中的初始化角色中讀取數(shù)據(jù)庫中的音視頻源頭以及中轉目的相關信息保存在當前程序的地址空間中。

優(yōu)選的，所述步驟3中，TCP中轉插件根據(jù)數(shù)據(jù)存儲文件對音視頻源進行引流，將音視頻源轉往服務器，具體包括：

TCP中轉插件在執(zhí)行初始化角色模塊，始化角色創(chuàng)建RTSP數(shù)據(jù)源隊列用于存放音視頻源，初始化TCP中轉會話，將當前模塊作為一個屬性插入到系統(tǒng)統(tǒng)一配置的模塊屬性結構體中，讀取緩存中的音視頻源以及中轉目的相關信息；

TCP中轉插件中的初始化角色對RTSP數(shù)據(jù)源隊列進行檢查是否已經(jīng)被建立過引流鏈接，如果已經(jīng)建立則不再進行數(shù)據(jù)引流，如果沒有建立過則通過RTSP數(shù)據(jù)源中的元素獲取RTSP數(shù)據(jù)源信息類，啟動會話創(chuàng)建任務開始創(chuàng)建RTSP客戶端任務進行音視頻源引流。

優(yōu)選的，所述用戶在RTSP客戶端向TCP中轉插件提出請求過程具體包括：

用戶在RTSP客戶端使用標準的RTSP方式進行與TCP中轉插件指令交互，指令包括選擇指令和描述指令，選擇指令不發(fā)送探測指令，描述指令要對接收到的SDP協(xié)議包進行解析，獲取當前設備源具有的流信息；

將SDP信息保存在本地SDP文件中；

在TCP中轉插件中的初始化模塊啟動的RTSP客戶端過程中的Describe指令交互過程中解析成功SDP協(xié)議數(shù)據(jù)之后在描述指令過程中創(chuàng)建中轉會話以及反射會話，在創(chuàng)建反射會話中開辟當前設備源中具有的所有媒體流的信息空間，創(chuàng)建對應的RTP發(fā)送者和RTCP發(fā)送者；

當TCP中轉會話創(chuàng)建成功，則準備啟動中轉任務，將每個輸出目的添加進對應的輸出流中進行TCP中轉輸出，每條流對應著多個中轉目的；

在TCP中轉輸出中將啟動TCP中轉宣告任務，對這個任務的驅動使用時間片方式，每隔不低于10毫秒的時間片進行一次任務調(diào)用，調(diào)用任務過程中將清空可發(fā)送數(shù)據(jù)包隊列；

在RTSP交互過程中的SETUP指令階段，音視頻源使用TCP傳輸方式進行傳輸協(xié)商，最后發(fā)送播放指令指揮音視頻設備開始發(fā)送數(shù)據(jù)流；

在播放過程中讀取媒體流函數(shù)的永久循環(huán)過程中，對無效數(shù)據(jù)包進行跳出處理，以跳出RTSP客戶端過程；

TCP中轉插件中的初始化模塊中啟動的RTSP客戶端過程中的媒體流數(shù)據(jù)包處理函數(shù)對于每個處理好的數(shù)據(jù)包判斷是RTP或者RTCP類型，分別調(diào)用啟動反射會話中創(chuàng)建的UDP套接字類轉化成TCP反射套接字送入數(shù)據(jù)包處理函數(shù)進行處理，數(shù)據(jù)包處理函數(shù)將對數(shù)據(jù)包進入到對應發(fā)送者的發(fā)送數(shù)據(jù)包隊列中，這個隊列將在輸出的TCP中轉宣告任務中被調(diào)用。

進一步的，當讀取媒體流函數(shù)退出，需要在播放過程的結束返回一個時間值進行RTSP客戶端任務的自動調(diào)用運轉，該時間值不能低于10毫秒；

進一步的：在創(chuàng)建TCP中轉輸出過程中，根據(jù)數(shù)據(jù)庫或者配置文件中的中轉目的發(fā)送RTSP擴展指令宣告過程，對反射服務器的中轉目的進行宣告，并且宣告指令掛著LocalSDP協(xié)議數(shù)據(jù)，告訴反射服務器將要主動發(fā)送碼流數(shù)據(jù)信息，宣告指令還將攜帶標識當前視頻源碼流的唯一標識符；

宣告指令過程成功執(zhí)行之后，循環(huán)當前中轉會話攜帶的所有數(shù)據(jù)流，取出每條流中對應的TCP反射發(fā)送者，調(diào)用反射包函數(shù)開始進行中轉發(fā)送，所述TCP反射發(fā)送者分別對應著RTP發(fā)送者/RTCP發(fā)送者。

進一步的，進行中轉發(fā)送的音頻數(shù)據(jù)流不需要進行緩存設置，而是由中轉音頻數(shù)據(jù)流直接調(diào)用反射中轉包，在反射中轉包函數(shù)中取出每條流下所有的桶數(shù)量，桶中循環(huán)每個索引，取出所有的中轉隊列開始進行發(fā)送，對于每個發(fā)送目的，發(fā)送出在數(shù)據(jù)包隊列中所有的數(shù)據(jù)包。

進一步的，當TCP中轉輸出在執(zhí)行發(fā)送包函數(shù)的時候將會調(diào)用RTSP客戶端中的PutMediaPakcet函數(shù)，當這個函數(shù)返回值并不等于OS_NoErr的時候，將返回值設置成QTSS_WouldBlock，此時返回到反射中轉包函數(shù)將會對這個發(fā)生阻塞的數(shù)據(jù)包進行書簽設置，下一次進行TCP反射RelayPackets的時候將會首先尋找書簽包進行發(fā)送。

進一步的，當TCP中轉插件成功對音視頻源數(shù)據(jù)進行中轉以及主動推送宣告指令給TCP反射模塊的時候，服務器將執(zhí)行TCP反射模塊模塊中預先注冊的對應角色模塊；在RTSP指令交互階段當收到中轉模塊發(fā)送過來的宣告指令的時候TCP反射模塊中的RTSP預處理角色角色模塊將進行工作，保存宣告指令中攜帶的SDP消息于本地文件中。

進一步的，當TCP中轉插件模塊發(fā)送啟動指令過來的時候，TCP反射模塊中的RTSP預處理角色角色模塊將觸發(fā)DoSetup函數(shù)，這個函數(shù)將判斷啟動指令中是否需要推送的標志用于決定添加進客戶端會話中或者是發(fā)送目的隊列中，如果這是該宣告指令的流，則創(chuàng)建TCP反射會話，并且將這個會話存放進客戶端會話的sClientBroadcastSessionAttr中；

如果這是一條用戶終端連接進來的啟動指令，說明這個用戶終端是作為一個反射目的，需要被反射出流的，因此創(chuàng)建TCPRTP反射目的會話并且添加進TCP反射會話中；

如果這是一條由宣告開頭的指令進來的會話，在啟動TCP反射會話之前將這條流設置成需要緩存的會話類型；

如果這是一條用戶終端會話進來的，則在DoSetup的時候將會發(fā)現(xiàn)已經(jīng)具有此用戶終端要請求的會話標識，DoSessionSetup中的FindOrCreateSession函數(shù)將發(fā)現(xiàn)已經(jīng)存在請求會話，如果成功發(fā)現(xiàn)請求會話則將此用戶終端會話添加進Output將進行數(shù)據(jù)流反射。

進一步的，在FindOrCreateSession函數(shù)調(diào)用創(chuàng)建TCP反射會話函數(shù)中，對于CreateUDP套接字配對在TCP方式下注釋掉原DSS框架中的UDP地址復用過程，否則這個過程將導致在TCP方式下第二條媒體流SSRC發(fā)生沖突。

進一步的，當TCP中轉插件成功引流并且主動推送ANNOUNCE指令過程往反射服務器成功創(chuàng)建反射會話，則開始發(fā)送音視頻碼流數(shù)據(jù)，此時將觸發(fā)TCP反射模塊中的RTSP碼流數(shù)據(jù)角色角色模塊開始工作，這個角色模塊將調(diào)用PushPacket函數(shù)，區(qū)分RTP/RTCP數(shù)據(jù)包往對應的用戶終端；

PushPacket將觸發(fā)TCP反射套接字類中的Run任務，這個任務設計成IdleTask類型的任務，當具有外屆的連接進來的時候，將優(yōu)先處理外界連接，服務器線程池無任何其他任務的時候才進行碼流的持續(xù)推送；

當最終用戶以選擇指令連接方式發(fā)送進來的時候TCP反射插件將辨別是否已經(jīng)具有最終用戶請求的碼流標識，如果已經(jīng)存在需要請求的碼流會話，則將最終用戶作為一個輸出指令添加進去。

優(yōu)選的，所述引流、中轉和反射過程中，無論是否具有用戶終端的接入，引流和中轉過程持續(xù)進行。

以上僅為本發(fā)明的具體實施例，并非對本發(fā)明的保護范圍的限定。凡依本案的設計思路所做的等同變化，均落入本案的保護范圍。