本發(fā)明涉及計(jì)算機(jī)存儲技術(shù)領(lǐng)域，尤其涉及一種分布式文件系統(tǒng)中流媒體讀取方法及服務(wù)器。

背景技術(shù)：

流媒體技術(shù)是一種專門用于網(wǎng)絡(luò)多媒體信息傳播和處理的新技術(shù)，該技術(shù)能夠在網(wǎng)絡(luò)上實(shí)現(xiàn)傳播和播放同時(shí)進(jìn)行的實(shí)時(shí)工作模式，相對于其他的一些音、視頻網(wǎng)絡(luò)傳輸和處理技術(shù)，流媒體比較成熟和使用，目前已經(jīng)成為網(wǎng)上音、視頻傳輸?shù)闹饕鉀Q方案。

當(dāng)前制約流媒體寬帶應(yīng)用發(fā)展的關(guān)鍵在于互聯(lián)網(wǎng)的服務(wù)質(zhì)量，流媒體從理論上解決了大容量網(wǎng)絡(luò)多媒體數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性要求問題，但是由于大型分組交換網(wǎng)絡(luò)中數(shù)據(jù)傳輸受到諸多因素的影響，網(wǎng)絡(luò)的狀況是不可靠的，其帶寬、負(fù)荷等的變化難以滿足流媒體寬帶業(yè)務(wù)的實(shí)時(shí)性服務(wù)質(zhì)量要求。并且常常造成播放卡殼、延遲、視頻抖動劇烈，對用戶體驗(yàn)造成很大影響。

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

本發(fā)明的主要目的在于提供一種分布式文件系統(tǒng)中流媒體讀取方法及服務(wù)器，旨在提高視頻數(shù)據(jù)的傳輸效率。

為實(shí)現(xiàn)上述目的，本發(fā)明提供的一種分布式文件系統(tǒng)中流媒體讀取方法，所述流媒體讀取方法包括如下步驟：

接收客戶端發(fā)出的觀看視頻的請求，并根據(jù)所述觀看視頻的請求發(fā)回獲準(zhǔn)觀看視頻的響應(yīng)至所述客戶端；

獲取視頻源發(fā)出的視頻數(shù)據(jù)，并將所述視頻數(shù)據(jù)發(fā)送至所述客戶端；所述視頻源為全部視頻源中部分預(yù)先已建立映射關(guān)系的視頻源。

優(yōu)選地，所述接收客戶端發(fā)出的觀看視頻的請求，并根據(jù)所述觀看視頻的請求發(fā)回獲準(zhǔn)觀看視頻的響應(yīng)至所述客戶端之前還包括：

與所述視頻源進(jìn)行交互；

啟動UDP端口準(zhǔn)備接收所述視頻源發(fā)出的所述視頻數(shù)據(jù)。

優(yōu)選地，所述獲取視頻源發(fā)出的視頻數(shù)據(jù)之后還包括：

將從所述視頻源獲取到的所述視頻數(shù)據(jù)存儲至后臺。

優(yōu)選地，所述獲取視頻源發(fā)出的視頻數(shù)據(jù)具體包括：

獲取所述視頻源發(fā)出的第一視頻數(shù)據(jù)；

發(fā)出包括第一網(wǎng)絡(luò)狀態(tài)的響應(yīng)至所述視頻源；所述第一網(wǎng)絡(luò)狀態(tài)為與所述視頻源連接的網(wǎng)絡(luò)狀態(tài)；

獲取所述視頻源在發(fā)出第一視頻數(shù)據(jù)的預(yù)設(shè)時(shí)間后發(fā)出的第二視頻數(shù)據(jù)；所述第二視頻數(shù)據(jù)是所述視頻源根據(jù)所述第一網(wǎng)絡(luò)狀態(tài)對視頻數(shù)據(jù)的大小進(jìn)行調(diào)整后發(fā)出的所述視頻數(shù)據(jù)。

優(yōu)選地，所述將所述視頻數(shù)據(jù)發(fā)送至所述客戶端具體包括：

將從所述視頻源獲取到的第三視頻數(shù)據(jù)發(fā)送給所述客戶端；

接收所述客戶端發(fā)出的包括第二網(wǎng)絡(luò)狀態(tài)的響應(yīng)；所述第二網(wǎng)絡(luò)狀態(tài)為與所述客戶端連接的網(wǎng)絡(luò)狀態(tài)；

在發(fā)出所述第三視頻數(shù)據(jù)的預(yù)設(shè)時(shí)間后發(fā)出第四視頻數(shù)據(jù)；所述第四視頻數(shù)據(jù)是根據(jù)所述第二網(wǎng)絡(luò)狀態(tài)對視頻數(shù)據(jù)的大小進(jìn)行調(diào)整后發(fā)出的所述視頻數(shù)據(jù)。

本發(fā)明還提供分布式文件系統(tǒng)中流媒體服務(wù)器，所述分布式文件系統(tǒng)中流媒體服務(wù)器包括第一接收模塊、第一發(fā)送模塊、獲取模塊和第二發(fā)送模塊，其中：

所述第一接收模塊，用于接收客戶端發(fā)出的觀看視頻的請求；

所述第一發(fā)送模塊，用于根據(jù)所述觀看視頻的請求發(fā)回獲準(zhǔn)觀看視頻的響應(yīng)至所述客戶端；

獲取模塊，用于獲取視頻源發(fā)出的視頻數(shù)據(jù)；所述視頻源為全部視頻源中部分預(yù)先已建立映射關(guān)系的視頻源；

第二發(fā)送模塊，用于將所述視頻數(shù)據(jù)發(fā)送至所述客戶端。

優(yōu)選地，所述分布式文件系統(tǒng)中流媒體服務(wù)器還包括交互模塊和啟動模塊，其中：

所述交互模塊，用于與所述視頻源進(jìn)行交互；

所述啟動模塊，用于啟動UDP端口準(zhǔn)備接收所述視頻源發(fā)出的所述視頻數(shù)據(jù)。

優(yōu)選地，所述分布式文件系統(tǒng)中流媒體服務(wù)器還包括：

存儲模塊，用于將從所述視頻源獲取到的所述視頻數(shù)據(jù)存儲至后臺。

優(yōu)選地，所述獲取模塊包括第一獲取單元、第一發(fā)送單元和第二獲取單元，其中：

所述第一獲取單元，用于獲取所述視頻源發(fā)出的第一視頻數(shù)據(jù)；

所述第一發(fā)送單元，用于發(fā)出包括第一網(wǎng)絡(luò)狀態(tài)的響應(yīng)至所述視頻源；所述第一網(wǎng)絡(luò)狀態(tài)為與所述視頻源連接的網(wǎng)絡(luò)狀態(tài)；

所述第二獲取單元，用于獲取所述視頻源在發(fā)出第一視頻數(shù)據(jù)的預(yù)設(shè)時(shí)間后發(fā)出的第二視頻數(shù)據(jù)；所述第二視頻數(shù)據(jù)是所述視頻源根據(jù)所述第一網(wǎng)絡(luò)狀態(tài)對視頻數(shù)據(jù)的大小進(jìn)行調(diào)整后發(fā)出的所述視頻數(shù)據(jù)。

優(yōu)選地，所述第二發(fā)送模塊包括第二發(fā)送單元和接收單元，其中：

所述第二發(fā)送單元，用于將從所述視頻源獲取到的第三視頻數(shù)據(jù)發(fā)送給所述客戶端；

所述接收單元，用于接收所述客戶端發(fā)出的包括第二網(wǎng)絡(luò)狀態(tài)的響應(yīng)；所述第二網(wǎng)絡(luò)狀態(tài)為與所述客戶端連接的網(wǎng)絡(luò)狀態(tài)；

所述第三發(fā)送單元，用于在發(fā)出所述第三視頻數(shù)據(jù)的預(yù)設(shè)時(shí)間后發(fā)出第四視頻數(shù)據(jù)；所述第四視頻數(shù)據(jù)是根據(jù)所述第二網(wǎng)絡(luò)狀態(tài)對視頻數(shù)據(jù)的大小進(jìn)行調(diào)整后發(fā)出的所述視頻數(shù)據(jù)。

本發(fā)明通過對流媒體的項(xiàng)目規(guī)模配置相應(yīng)的數(shù)量的流媒體服務(wù)器，將視頻源均衡的與多個獨(dú)立網(wǎng)絡(luò)的所述流媒體服務(wù)器建立映射關(guān)系，避免在網(wǎng)絡(luò)帶寬不穩(wěn)定的情況下，整個流媒體的視頻數(shù)據(jù)僅通過一個視頻監(jiān)視器傳輸，而嚴(yán)重影響視頻傳輸效率的問題；此外，通過實(shí)時(shí)響應(yīng)視頻源與流媒體服務(wù)器、流媒體服務(wù)器與客戶端之間的網(wǎng)絡(luò)狀態(tài)，可以對應(yīng)調(diào)整視頻數(shù)據(jù)的大小，進(jìn)一步提高了整個項(xiàng)目的視頻傳輸效率。

附圖說明

圖1為本發(fā)明分布式文件系統(tǒng)中流媒體讀取方法第一實(shí)施例的流程示意圖；

圖2為本發(fā)明分布式文件系統(tǒng)中流媒體讀取方法的步驟S20的細(xì)化流程示意圖；

圖3為本發(fā)明分布式文件系統(tǒng)中流媒體讀取方法第二實(shí)施例的流程示意圖；

圖4為本發(fā)明分布式文件系統(tǒng)中流媒體讀取方法第三實(shí)施例的流程示意圖；

圖5為本發(fā)明分布式文件系統(tǒng)的結(jié)構(gòu)示意圖；

圖6為本發(fā)明分布式文件系統(tǒng)中流媒體服務(wù)器第一實(shí)施例的功能模塊圖；

圖7為圖6中獲取模塊的細(xì)化功能模塊圖；

圖8為圖6中第二發(fā)送模塊的細(xì)化功能模塊圖；

圖9為本發(fā)明分布式文件系統(tǒng)中流媒體服務(wù)器第二實(shí)施例的功能模塊圖；

圖10為本發(fā)明分布式文件系統(tǒng)中流媒體服務(wù)器第三實(shí)施例的功能模塊圖。

本發(fā)明目的的實(shí)現(xiàn)、功能特點(diǎn)及優(yōu)點(diǎn)將結(jié)合實(shí)施例，參照附圖做進(jìn)一步說明。

具體實(shí)施方式

應(yīng)當(dāng)理解，此處所描述的具體實(shí)施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

本發(fā)明提供一種分布式文件系統(tǒng)中流媒體讀取方法，請參照圖1，在一實(shí)施例中，該分布式文件系統(tǒng)中流媒體讀取方法包括：

步驟S10，接收客戶端發(fā)出的觀看視頻的請求，并根據(jù)所述觀看視頻的請求發(fā)回獲準(zhǔn)觀看視頻的響應(yīng)至所述客戶端；

當(dāng)用戶需要觀看視頻源的實(shí)時(shí)監(jiān)控視頻時(shí)，通過客戶端發(fā)出觀看視頻的請求，流媒體服務(wù)器接受請求后根據(jù)客戶端的狀態(tài)判斷是否允許其觀看，在允許觀看的情況下，向所述客戶端發(fā)回允許觀看的響應(yīng)，具體的，返回值為200。

步驟S20，獲取視頻源發(fā)出的視頻數(shù)據(jù)，并將所述視頻數(shù)據(jù)發(fā)送至所述客戶端；所述視頻源為全部視頻源中部分預(yù)先已建立映射關(guān)系的視頻源。

流媒體的傳輸?shù)膶?shí)現(xiàn)需要緩存。因?yàn)镮nternet以分組傳輸為基礎(chǔ)進(jìn)行斷續(xù)的異步傳輸，對一個實(shí)時(shí)的A/V源或存儲的A/V文件。在傳輸中它們要被分解為許多的分組，由于網(wǎng)絡(luò)是動態(tài)變化的，各個分組選擇的路由可能不盡相同，故到達(dá)客戶端的時(shí)間延遲也就不等，甚至先發(fā)的數(shù)據(jù)分組有可能后到。為此，使用緩存系統(tǒng)來彌補(bǔ)延遲和抖動的影響，并保證分組的順序正確，從而使媒體數(shù)據(jù)能連續(xù)輸出，而不會因?yàn)榫W(wǎng)絡(luò)暫時(shí)擁塞使播放出現(xiàn)停頓。在流媒體傳輸中，使用RTP/UDP和RTSP/TCP兩種不同的通信協(xié)議與A/V服務(wù)器建立聯(lián)系，是為了能夠把服務(wù)器的輸出重定向到一個不同于運(yùn)行A/V Helper程序所在客戶機(jī)的目的地址，實(shí)現(xiàn)流媒體傳輸一般都需要專用服務(wù)器和播放器。

在允許所述客戶端觀看視頻的情況下，通過實(shí)時(shí)流傳輸協(xié)議(Real Time Streaming Protocol，RTSP)和實(shí)時(shí)傳輸協(xié)議(Real-time Transport Protocol，RTP)將實(shí)時(shí)的視頻流發(fā)送至所述客戶端。RTSP由RealNetworks和Netscape共同提出，是工作在RTP之上的應(yīng)用層協(xié)議。它的主要目標(biāo)是為單播和多播提供可靠的播放性能。RTSP的主要思想是提供控制多種應(yīng)用數(shù)據(jù)傳送的功能，即提供一種選擇傳送通道的方法，例如UDP、TCP、IP多播，同時(shí)提供基于RTP傳送機(jī)制的方法。RTSP控制通過單獨(dú)協(xié)議發(fā)送的流，與控制通道無關(guān)，例如，RTSP控制可通過TCP連接，而數(shù)據(jù)流通過UDP，通過建立并控制一個或幾個時(shí)間同步的連續(xù)流數(shù)據(jù)，其中可能包括控制流，RTSP能為服務(wù)器提供遠(yuǎn)程控制。另外，由于RTSP在語法和操作上與HTTP類似，RTSP請求可由標(biāo)準(zhǔn)HTTP或MIME解析器解析，并且RTSP請求可被代理、通道與緩存處理。與HTTP相比，RTSP是雙向的，即客戶機(jī)和服務(wù)器都可以發(fā)出RTSP請求。

現(xiàn)RTSP的系統(tǒng)必須支持通過TCP傳輸RTSP，并支持UDP。RTSP服務(wù)器的TCP和UDP缺省端口都是554。目前最新的微軟Media Services V9和RealSystem都支持RTSP協(xié)議。

流媒體的項(xiàng)目中包括多個視頻源和多個流媒體服務(wù)器，其中多個視頻源和多個流媒體服務(wù)器之間對應(yīng)建立了映射關(guān)系，所述流媒體服務(wù)器的數(shù)量不多于所述視頻源的數(shù)量，具體包括1對多、1對1和多對1等多種情況，以平衡視頻傳輸?shù)呢?fù)載?？蛻舳诵枰^看視頻時(shí)，只需向?qū)?yīng)的所述流媒體服務(wù)器請求，而該服務(wù)器也只通過少量與其已建立映射關(guān)系的視頻源發(fā)出的視頻數(shù)據(jù)，減輕對網(wǎng)絡(luò)帶寬的依賴，提高視頻數(shù)據(jù)的傳輸效率。

本實(shí)施例中，通過對流媒體的項(xiàng)目規(guī)模配置相應(yīng)的數(shù)量的流媒體服務(wù)器，將視頻源均衡的與多個獨(dú)立網(wǎng)絡(luò)的所述流媒體服務(wù)器建立映射關(guān)系，避免在網(wǎng)絡(luò)帶寬不穩(wěn)定的情況下，整個流媒體的視頻數(shù)據(jù)僅通過一個視頻監(jiān)視器傳輸，而嚴(yán)重影響視頻傳輸效率的問題，提高了視頻傳輸?shù)男省?/p>

進(jìn)一步地，請參閱圖2，步驟S20中獲取視頻源發(fā)出的視頻數(shù)據(jù)具體包括：

步驟S21，獲取所述視頻源發(fā)出的第一視頻數(shù)據(jù)；

步驟S22，發(fā)出包括第一網(wǎng)絡(luò)狀態(tài)的響應(yīng)至所述視頻源；所述第一網(wǎng)絡(luò)狀態(tài)為與所述視頻源連接的網(wǎng)絡(luò)狀態(tài)；

步驟S23，獲取所述視頻源在發(fā)出第一視頻數(shù)據(jù)的預(yù)設(shè)時(shí)間后發(fā)出的第二視頻數(shù)據(jù)；所述第二視頻數(shù)據(jù)是所述視頻源根據(jù)所述第一網(wǎng)絡(luò)狀態(tài)對視頻數(shù)據(jù)的大小進(jìn)行調(diào)整后發(fā)出的所述視頻數(shù)據(jù)。

步驟S20中將所述視頻數(shù)據(jù)發(fā)送至所述客戶端具體包括：

步驟S24，將從所述視頻源獲取到的第三視頻數(shù)據(jù)發(fā)送給所述客戶端；

步驟S25，接收所述客戶端發(fā)出的包括第二網(wǎng)絡(luò)狀態(tài)的響應(yīng)；所述第二網(wǎng)絡(luò)狀態(tài)為與所述客戶端連接的網(wǎng)絡(luò)狀態(tài)；

步驟S26，在發(fā)出所述第三視頻數(shù)據(jù)的預(yù)設(shè)時(shí)間后發(fā)出第四視頻數(shù)據(jù)；所述第四視頻數(shù)據(jù)是根據(jù)所述第二網(wǎng)絡(luò)狀態(tài)對視頻數(shù)據(jù)的大小進(jìn)行調(diào)整后發(fā)出的所述視頻數(shù)據(jù)。

流媒體之所以能夠?qū)崿F(xiàn)多媒體數(shù)據(jù)的實(shí)時(shí)播放是采用了專門的網(wǎng)絡(luò)控制協(xié)議和數(shù)據(jù)傳輸機(jī)制。服務(wù)器端有專門的流媒體發(fā)布系統(tǒng)，而客戶端則有專門的播放器，這兩部分都需要通過數(shù)據(jù)緩存區(qū)進(jìn)行數(shù)據(jù)的緩存。

與普通的分組交換網(wǎng)絡(luò)不同，流媒體系統(tǒng)的緩存區(qū)中的數(shù)據(jù)在數(shù)據(jù)傳輸過程中是動態(tài)的，也可成為是交換狀態(tài)的，數(shù)據(jù)以堆棧方式進(jìn)出緩沖區(qū)，而不需要等待數(shù)據(jù)全部達(dá)到客戶機(jī)后才從緩沖區(qū)中被釋放出來，由于數(shù)據(jù)緩沖區(qū)中的數(shù)據(jù)是“流動”的，再加上數(shù)據(jù)的播放需要維持一個穩(wěn)定的數(shù)據(jù)輸出速度，隨時(shí)都要求緩沖區(qū)有相應(yīng)的數(shù)據(jù)提供給播放器，如果沒有相應(yīng)的數(shù)據(jù)，則會出現(xiàn)內(nèi)容播放過程中的暫停和畫面的條約，出現(xiàn)前一種情況一般是由于網(wǎng)絡(luò)傳輸速度跟不上數(shù)據(jù)的播放速度，而發(fā)生了數(shù)據(jù)的下溢，后一種情況的發(fā)生是由于網(wǎng)絡(luò)傳輸速度過快，超過了播放的速度，而又沒有適當(dāng)?shù)膫鬏斂刂贫斐傻臄?shù)據(jù)上溢。

本實(shí)施例中，通過所述流媒體服務(wù)器與所述視頻流之間的網(wǎng)絡(luò)狀態(tài)對所述視頻數(shù)據(jù)的大小進(jìn)行調(diào)整，自適應(yīng)調(diào)整視頻數(shù)據(jù)的碼率以克服上述的問題而達(dá)到監(jiān)看的最佳效果。

進(jìn)一步地，請參閱圖3，基于本發(fā)明分布式文件系統(tǒng)中流媒體讀取方法的第一實(shí)施例，本發(fā)明分布式文件系統(tǒng)中流媒體讀取方法的第二實(shí)施例中，所述步驟S10之前還包括：

步驟S30，與所述視頻源進(jìn)行交互；

流媒體服務(wù)器向所述視頻源發(fā)出獲取視頻數(shù)據(jù)的請求，所述視頻源在允許所述流媒體服務(wù)器獲取視頻數(shù)據(jù)的情況下發(fā)回允許獲取的響應(yīng)，再由所述流媒體服務(wù)器接收該響應(yīng)，具體的，返回值為200。

步驟S40，啟動UDP端口以接收所述視頻源發(fā)出的所述視頻數(shù)據(jù)；

在所述流媒體服務(wù)器接收到允許獲取的響應(yīng)后，啟動UDP端口，所述視頻源通過所述UDP端口采用RTP協(xié)議將所述視頻數(shù)據(jù)發(fā)送至所述流媒體服務(wù)器，所述流媒體服務(wù)器接收所述視頻數(shù)據(jù)。

本實(shí)施例中，在客戶端未請求觀看視頻之前所述流媒體服務(wù)器就能夠收到所述視頻源的數(shù)據(jù)信息，較現(xiàn)有技術(shù)中在客戶端請求觀看視頻的后還需要等待所述流媒體服務(wù)器啟動所述UDP端口而言，在所述客戶端請求視頻數(shù)據(jù)之后減少了步驟，加速了所述客戶端獲取所述視頻數(shù)據(jù)的速度。

進(jìn)一步地，請參閱圖4，基于本發(fā)明分布式文件系統(tǒng)中流媒體讀取方法的第一實(shí)施例，本發(fā)明分布式文件系統(tǒng)中流媒體讀取方法的第三實(shí)施例中，所述步驟S20之后還包括：

S50，將從所述視頻源獲取到的所述視頻數(shù)據(jù)存儲至后臺；

與市場上的現(xiàn)有技術(shù)相比較，通過采用市場上最先進(jìn)的H264以及H265編碼降低了傳輸?shù)拇a率，在同等帶寬下節(jié)省了存儲空間，同時(shí)在分布式存儲過程中利用分布式存儲特點(diǎn)將視頻流并發(fā)的存儲到各個子存儲系統(tǒng)中，實(shí)現(xiàn)高效的視頻信息存儲，過程中記錄下通道號、日期、時(shí)間等參數(shù)。

之后如果要查看某歷史視頻數(shù)據(jù)，流媒體服務(wù)器則根據(jù)查詢條件如：通道號、日期、時(shí)間等參數(shù)從分布式存儲設(shè)備中找到最優(yōu)路徑，讀取視頻流信息，并轉(zhuǎn)發(fā)給監(jiān)看平臺。

本實(shí)施例中，所述流媒體服務(wù)器在接收視頻數(shù)據(jù)后將視頻數(shù)據(jù)并發(fā)的存儲到各個子存儲系統(tǒng)中，實(shí)現(xiàn)了高效的視頻信息存儲，且便于日后查找所述視頻數(shù)據(jù)。

本發(fā)明還提供一種分布式文件系統(tǒng)中流媒體服務(wù)器，請參照圖5和圖6，在一實(shí)施例中，上述分布式文件系統(tǒng)100中包括視頻源10、流媒體30和客戶端50，該分布式文件系統(tǒng)100中流媒體服務(wù)器30包括第一接收模塊31、第一發(fā)送模塊32、獲取模塊33和第二發(fā)送模塊34，其中：

所述第一接收模塊31，用于接收客戶端發(fā)出的觀看視頻的請求；

所述第一發(fā)送模塊32，用于根據(jù)所述觀看視頻的請求發(fā)回獲準(zhǔn)觀看視頻的響應(yīng)至所述客戶端；

當(dāng)用戶需要觀看視頻源的實(shí)時(shí)監(jiān)控視頻時(shí)，通過客戶端發(fā)出觀看視頻的請求，流媒體服務(wù)器接受請求后根據(jù)客戶端的狀態(tài)判斷是否允許其觀看，在允許觀看的情況下，向所述客戶端發(fā)回允許觀看的響應(yīng)，具體的，返回值為200。

獲取模塊33，用于獲取視頻源10發(fā)出的視頻數(shù)據(jù)；所述視頻源10為全部視頻源中部分預(yù)先已建立映射關(guān)系的視頻源；

第二發(fā)送模塊34，用于將所述視頻數(shù)據(jù)發(fā)送至所述客戶端50。

流媒體的傳輸?shù)膶?shí)現(xiàn)需要緩存。因?yàn)镮nternet以分組傳輸為基礎(chǔ)進(jìn)行斷續(xù)的異步傳輸，對一個實(shí)時(shí)的A/V源或存儲的A/V文件。在傳輸中它們要被分解為許多的分組，由于網(wǎng)絡(luò)是動態(tài)變化的，各個分組選擇的路由可能不盡相同，故到達(dá)客戶端的時(shí)間延遲也就不等，甚至先發(fā)的數(shù)據(jù)分組有可能后到。為此，使用緩存系統(tǒng)來彌補(bǔ)延遲和抖動的影響，并保證分組的順序正確，從而使媒體數(shù)據(jù)能連續(xù)輸出，而不會因?yàn)榫W(wǎng)絡(luò)暫時(shí)擁塞使播放出現(xiàn)停頓。在流媒體傳輸中。使用RTP/UDP和RTSP/TCP兩種不同的通信協(xié)議與A/V服務(wù)器建立聯(lián)系，是為了能夠把服務(wù)器的輸出重定向到一個不同于運(yùn)行A/V Helper程序所在客戶機(jī)的目的地址，實(shí)現(xiàn)流媒體傳輸一般都需要專用服務(wù)器和播放器。

在允許所述客戶端觀看視頻的情況下，通過實(shí)時(shí)流傳輸協(xié)議(Real Time Streaming Protocol，RTSP)和實(shí)時(shí)傳輸協(xié)議(Real-time Transport Protocol，RTP)將實(shí)時(shí)的視頻流發(fā)送至所述客戶端。RTSP由RealNetworks和Netscape共同提出，是工作在RTP之上的應(yīng)用層協(xié)議。它的主要目標(biāo)是為單播和多播提供可靠的播放性能。RTSP的主要思想是提供控制多種應(yīng)用數(shù)據(jù)傳送的功能，即提供一種選擇傳送通道的方法，例如UDP、TCP、IP多播，同時(shí)提供基于RTP傳送機(jī)制的方法。RTSP控制通過單獨(dú)協(xié)議發(fā)送的流，與控制通道無關(guān)，例如，RTSP控制可通過TCP連接，而數(shù)據(jù)流通過UDP，通過建立并控制一個或幾個時(shí)間同步的連續(xù)流數(shù)據(jù)，其中可能包括控制流，RTSP能為服務(wù)器提供遠(yuǎn)程控制。另外，由于RTSP在語法和操作上與HTTP類似，RTSP請求可由標(biāo)準(zhǔn)HTTP或MIME解析器解析，并且RTSP請求可被代理、通道與緩存處理。與HTTP相比，RTSP是雙向的，即客戶機(jī)和服務(wù)器都可以發(fā)出RTSP請求。

現(xiàn)RTSP的系統(tǒng)必須支持通過TCP傳輸RTSP，并支持UDP。RTSP服務(wù)器的TCP和UDP缺省端口都是554。目前最新的微軟Media Services V9和RealSystem都支持RTSP協(xié)議。

流媒體的項(xiàng)目中包括多個視頻源和多個流媒體服務(wù)器，其中多個視頻源和多個流媒體服務(wù)器之間對應(yīng)建立了映射關(guān)系，所述流媒體服務(wù)器的數(shù)量不多于所述視頻源的數(shù)量，具體包括1對多、1對1和多對1等多種情況，以平衡視頻傳輸?shù)呢?fù)載。客戶端需要觀看視頻時(shí)，只需向?qū)?yīng)的所述流媒體服務(wù)器請求，而該服務(wù)器也只通過少量與其已建立映射關(guān)系的視頻源發(fā)出的視頻數(shù)據(jù)，減輕對網(wǎng)絡(luò)帶寬的依賴，提高視頻數(shù)據(jù)的傳輸效率。

本實(shí)施例中，通過對流媒體的項(xiàng)目規(guī)模配置相應(yīng)的數(shù)量的流媒體服務(wù)器，將視頻源均衡的與多個獨(dú)立網(wǎng)絡(luò)的所述流媒體服務(wù)器建立映射關(guān)系，避免在網(wǎng)絡(luò)帶寬不穩(wěn)定的情況下，整個流媒體的視頻數(shù)據(jù)僅通過一個視頻監(jiān)視器傳輸，而嚴(yán)重影響視頻傳輸效率的問題，提高了視頻傳輸?shù)男省?/p>

進(jìn)一步地，請參閱圖7，所述獲取模塊33包括第一獲取單元331、第一發(fā)送單元333和第二獲取單元335，其中：

所述第一獲取單元331，用于獲取所述視頻源10發(fā)出的第一視頻數(shù)據(jù)；

所述第一發(fā)送單元333，用于發(fā)出包括第一網(wǎng)絡(luò)狀態(tài)的響應(yīng)至所述視頻源10；所述第一網(wǎng)絡(luò)狀態(tài)為與所述視頻源10連接的網(wǎng)絡(luò)狀態(tài)；

所述第二獲取單元335，用于獲取所述視頻源10在發(fā)出第一視頻數(shù)據(jù)的預(yù)設(shè)時(shí)間后發(fā)出的第二視頻數(shù)據(jù)；所述第二視頻數(shù)據(jù)是所述視頻源10根據(jù)所述第一網(wǎng)絡(luò)狀態(tài)對視頻數(shù)據(jù)的大小進(jìn)行調(diào)整后發(fā)出的所述視頻數(shù)據(jù)。

請參閱圖8，所述第二發(fā)送模塊34包括第二發(fā)送單元341、接收單元343和第三發(fā)送單元345，其中：

所述第二發(fā)送單元341，用于將從所述視頻源10獲取到的第三視頻數(shù)據(jù)發(fā)送給所述客戶端50；

所述接收單元343，用于接收所述客戶端50發(fā)出的包括第二網(wǎng)絡(luò)狀態(tài)的響應(yīng)；所述第二網(wǎng)絡(luò)狀態(tài)為與所述客戶端50連接的網(wǎng)絡(luò)狀態(tài)；

所述第三發(fā)送單元345，用于在發(fā)出所述第三視頻數(shù)據(jù)的預(yù)設(shè)時(shí)間后發(fā)出第四視頻數(shù)據(jù)；所述第四視頻數(shù)據(jù)是根據(jù)所述第二網(wǎng)絡(luò)狀態(tài)對視頻數(shù)據(jù)的大小進(jìn)行調(diào)整后發(fā)出的所述視頻數(shù)據(jù)。

流媒體之所以能夠?qū)崿F(xiàn)多媒體數(shù)據(jù)的實(shí)時(shí)播放是采用了專門的網(wǎng)絡(luò)控制協(xié)議和數(shù)據(jù)傳輸機(jī)制。服務(wù)器端有專門的流媒體發(fā)布系統(tǒng)，而客戶端則有專門的播放器，這兩部分都需要通過數(shù)據(jù)緩存區(qū)進(jìn)行數(shù)據(jù)的緩存。

與普通的分組交換網(wǎng)絡(luò)不同，流媒體系統(tǒng)的緩存區(qū)中的數(shù)據(jù)在數(shù)據(jù)傳輸過程中是動態(tài)的，也可成為是交換狀態(tài)的，數(shù)據(jù)以堆棧方式進(jìn)出緩沖區(qū)，而不需要等待數(shù)據(jù)全部達(dá)到客戶機(jī)后才從緩沖區(qū)中被釋放出來，由于數(shù)據(jù)緩沖區(qū)中的數(shù)據(jù)是“流動”的，再加上數(shù)據(jù)的播放需要維持一個穩(wěn)定的數(shù)據(jù)輸出速度，隨時(shí)都要求緩沖區(qū)有相應(yīng)的數(shù)據(jù)提供給播放器，如果沒有相應(yīng)的數(shù)據(jù)，則會出現(xiàn)內(nèi)容播放過程中的暫停和畫面的條約，出現(xiàn)前一種情況一般是由于網(wǎng)絡(luò)傳輸速度跟不上數(shù)據(jù)的播放速度，而發(fā)生了數(shù)據(jù)的下溢，后一種情況的發(fā)生是由于網(wǎng)絡(luò)傳輸速度過快，超過了播放的速度，而又沒有適當(dāng)?shù)膫鬏斂刂贫斐傻臄?shù)據(jù)上溢。

本實(shí)施例中，通過所述流媒體服務(wù)器與所述視頻流之間的網(wǎng)絡(luò)狀態(tài)對所述視頻數(shù)據(jù)的大小進(jìn)行調(diào)整，自適應(yīng)調(diào)整視頻數(shù)據(jù)的碼率以克服上述的問題而達(dá)到監(jiān)看的最佳效果。

進(jìn)一步地，請參閱圖9，基于本發(fā)明分布式文件系統(tǒng)中流媒體服務(wù)器的第一實(shí)施例，本發(fā)明分布式文件系統(tǒng)中流媒體服務(wù)器的第二實(shí)施例中，所述分布式文件系統(tǒng)100中流媒體服務(wù)器30還包括交互模塊35和啟動模塊36，其中：

所述交互模塊35，用于與所述視頻源10進(jìn)行交互；

流媒體服務(wù)器向所述視頻源發(fā)出獲取視頻數(shù)據(jù)的請求，所述視頻源在允許所述流媒體服務(wù)器獲取視頻數(shù)據(jù)的情況下發(fā)回允許獲取的響應(yīng)，再由所述流媒體服務(wù)器接收該響應(yīng)，具體的，返回值為200。

所述啟動模塊36，用于啟動UDP端口準(zhǔn)備接收所述視頻源發(fā)出的所述視頻數(shù)據(jù)。

在所述流媒體服務(wù)器接收到允許獲取的響應(yīng)后，啟動UDP端口，所述視頻源通過所述UDP端口采用RTP協(xié)議將所述視頻數(shù)據(jù)發(fā)送至所述流媒體服務(wù)器，所述流媒體服務(wù)器接收所述視頻數(shù)據(jù)。

本實(shí)施例中，在客戶端未請求觀看視頻之前所述流媒體服務(wù)器就能夠收到所述視頻源的數(shù)據(jù)信息，較現(xiàn)有技術(shù)中在客戶端請求觀看視頻的后還需要等待所述流媒體服務(wù)器啟動所述UDP端口而言，在所述客戶端請求視頻數(shù)據(jù)之后減少了步驟，加速了所述客戶端獲取所述視頻數(shù)據(jù)的速度。

進(jìn)一步地，請參閱圖10，基于本發(fā)明分布式文件系統(tǒng)中流媒體服務(wù)器的第一實(shí)施例，本發(fā)明分布式文件系統(tǒng)中流媒體服務(wù)器的第三實(shí)施例中，所述分布式文件系統(tǒng)100中流媒體服務(wù)器30還包括：

存儲模塊37，用于將從所述視頻源10獲取到的所述視頻數(shù)據(jù)存儲至后臺。

與市場上的現(xiàn)有技術(shù)相比較，通過采用市場上最先進(jìn)的H264以及H265編碼降低了傳輸?shù)拇a率，在同等帶寬下節(jié)省了存儲空間，同時(shí)在分布式存儲過程中利用分布式存儲特點(diǎn)將視頻流并發(fā)的存儲到各個子存儲系統(tǒng)中，實(shí)現(xiàn)高效的視頻信息存儲，過程中記錄下通道號、日期、時(shí)間等參數(shù)。

之后如果要查看某歷史視頻數(shù)據(jù)，流媒體服務(wù)器則根據(jù)查詢條件如：通道號、日期、時(shí)間等參數(shù)從分布式存儲設(shè)備中找到最優(yōu)路徑，讀取視頻流信息，并轉(zhuǎn)發(fā)給監(jiān)看平臺。

本實(shí)施例中，所述流媒體服務(wù)器在接收視頻數(shù)據(jù)后將視頻數(shù)據(jù)并發(fā)的存儲到各個子存儲系統(tǒng)中，實(shí)現(xiàn)了高效的視頻信息存儲，且便于日后查找所述視頻數(shù)據(jù)。

以上僅為本發(fā)明的優(yōu)選實(shí)施例，并非因此限制本發(fā)明的專利范圍，凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結(jié)構(gòu)或等效流程變換，或直接或間接運(yùn)用在其他相關(guān)的技術(shù)領(lǐng)域，均同理包括在本發(fā)明的專利保護(hù)范圍內(nèi)。