本發(fā)明涉及媒體數(shù)據(jù)存儲，尤其涉及將RTSP流媒體轉(zhuǎn)換為對象存儲的技術(shù)。

背景技術(shù)：

實時傳輸協(xié)議(Real-time Transport Protocol或簡寫RTP)是一個網(wǎng)絡(luò)傳輸協(xié)議，詳細(xì)說明了在互聯(lián)網(wǎng)上傳遞音頻和視頻的標(biāo)準(zhǔn)數(shù)據(jù)包格式。RTP協(xié)議常用于流媒體系統(tǒng)(配合RTSP協(xié)議)。

安全實時傳輸協(xié)議(Secure Real-time Transport Protocol或SRTP)是在實時傳輸協(xié)議(RTP)基礎(chǔ)上所定義的一個協(xié)議，旨在為單播和多播應(yīng)用程序中的實時傳輸協(xié)議的數(shù)據(jù)提供加密、消息認(rèn)證、完整性保證和重放保護(hù)。

媒體業(yè)務(wù)是近幾年迅速發(fā)展的一種新業(yè)務(wù)，流媒體業(yè)務(wù)利用流式傳輸技術(shù)，在包交換網(wǎng)絡(luò)上傳輸多媒體內(nèi)容數(shù)據(jù)，例如視頻、音頻等數(shù)據(jù)。流式傳輸技術(shù)的主要特點在于，將連續(xù)的視頻和音頻數(shù)據(jù)經(jīng)過處理后放到網(wǎng)站服務(wù)器，這樣，用戶可以一邊下載一邊觀看和收聽，而不需要在整個文件下載到使用的用戶終端后才可以觀看和收聽。

傳統(tǒng)的流媒體系統(tǒng)基于C/S(client/server)模式，所有的客戶端都要從流媒體服務(wù)器獲取其所需要的流媒體資源，因此對流媒體的性能要求很高，并且其支撐的客戶端數(shù)量也很有限。

目前現(xiàn)有技術(shù)中得到廣泛應(yīng)用的流媒體系統(tǒng)是基于P2P技術(shù)的，大大降低了所述對象存儲的計算壓力和帶寬占用。

對象存儲相對于NAS、SAN等傳統(tǒng)的存儲方式，在可擴(kuò)展行、安全性、高可用性、經(jīng)濟(jì)性等方便都有較大優(yōu)勢；主流的云存儲幾乎全部建立在對象存儲的基礎(chǔ)上。

RTSP(Real Time Streaming Protocol)，RFC2326，實時流傳輸協(xié)議，是TCP/IP協(xié)議體系中的一個應(yīng)用層協(xié)議，由哥倫比亞大學(xué)、網(wǎng)景和RealNetworks公司提交的IETF RFC標(biāo)準(zhǔn)。該協(xié)議定義了一對多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上，它使用TCP或UDP完成數(shù)據(jù)傳輸。HTTP與RTSP相比，HTTP請求由客戶機(jī)發(fā)出，服務(wù)器作出響應(yīng)；使用RTSP時，客戶機(jī)和服務(wù)器都可以發(fā)出請求，即RTSP可以是雙向的。RTSP是用來控制聲音或影像的多媒體串流協(xié)議，并允許同時多個串流需求控制，傳輸時所用的網(wǎng)絡(luò)通訊協(xié)定并不在其定義的范圍內(nèi)，服務(wù)器端可以自行選擇使用TCP或UDP來傳送串流內(nèi)容，它的語法和運作跟HTTP 1.1類似，但并不特別強(qiáng)調(diào)時間同步，所以比較能容忍網(wǎng)絡(luò)延遲。而前面提到的允許同時多個串流需求控制(Multicast)，除了可以降低服務(wù)器端的網(wǎng)絡(luò)用量，更進(jìn)而支持多方視訊會議(Video Conference)。因為與HTTP1.1的運作方式相似，所以代理服務(wù)器〈Proxy〉的快取功能〈Cache〉也同樣適用于RTSP，并因RTSP具有重新導(dǎo)向功能，可視實際負(fù)載情況來轉(zhuǎn)換提供服務(wù)的服務(wù)器，以避免過大的負(fù)載集中于同一服務(wù)器而造成延遲。

該協(xié)議用于C/S模型，是一個基于文本的協(xié)議，用于在客戶端和服務(wù)器端建立和協(xié)商實時流會話。

實時流協(xié)議(RTSP)是應(yīng)用級協(xié)議，控制實時數(shù)據(jù)的發(fā)送。RTSP提供了一個可擴(kuò)展框架，使實時數(shù)據(jù)，如音頻與視頻的受控點播成為可能。數(shù)據(jù)源包括現(xiàn)場數(shù)據(jù)與存儲在剪輯中數(shù)據(jù)。該協(xié)議目的在于控制多個數(shù)據(jù)發(fā)送連接，為選擇發(fā)送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP上發(fā)送機(jī)制提供方法。

實時流協(xié)議(RTSP)建立并控制一個或幾個時間同步的連續(xù)流媒體。盡管連續(xù)媒體流與控制流交換是可能的，通常它本身并不發(fā)送連續(xù)流。換言之，RTSP充當(dāng)多媒體服務(wù)器的網(wǎng)絡(luò)遠(yuǎn)程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開或關(guān)閉多個對服務(wù)器的可傳輸連接以發(fā)出RTSP請求。此外，可使用無連接傳輸協(xié)議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續(xù)媒體的傳輸機(jī)制。

協(xié)議支持的操作如下：

(1)從媒體服務(wù)器上檢索媒體：用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用于連續(xù)媒體的的組播地址和端口。如演示僅通過單播發(fā)送給用戶，用戶為了安全應(yīng)提供目的地址。

(2)媒體服務(wù)器邀請進(jìn)入會議：媒體服務(wù)器可被邀請參加正進(jìn)行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分布式教育應(yīng)用上很有用，會議中幾方可輪流按遠(yuǎn)程控制按鈕。

(3)將媒體加到現(xiàn)成講座中：如服務(wù)器告訴用戶可獲得附加媒體內(nèi)容，對現(xiàn)場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。

RTSP協(xié)議特點：

(1)可擴(kuò)展性：新方法和參數(shù)很容易加入RTSP。

(2)易解析：RTSP可由標(biāo)準(zhǔn)HTTP或MIME解析器解析。

(3)安全：RTSP使用網(wǎng)頁安全機(jī)制。

(4)獨立于傳輸：RTSP可使用不可靠數(shù)據(jù)報協(xié)議(EDP)、可靠數(shù)據(jù)報協(xié)議(RDP)；如要實現(xiàn)應(yīng)用級可靠，可使用可靠流協(xié)議。

(5)多服務(wù)器支持：每個流可放在不同服務(wù)器上，用戶端自動與不同服務(wù)器建立幾個并發(fā)控制連接，媒體同步在傳輸層執(zhí)行。

(6)記錄設(shè)備控制：協(xié)議可控制記錄和回放設(shè)備。

(7)流控與會議開始分離：僅要求會議初始化協(xié)議提供，或可用來創(chuàng)建惟一會議標(biāo)識號。特殊情況下，可用SIP或H.323來邀請服務(wù)器入會。

(8)適合專業(yè)應(yīng)用：通過SMPTE時標(biāo)，RTSP支持幀級精度，允許遠(yuǎn)程數(shù)字編輯。

(9)演示描述中立：協(xié)議沒強(qiáng)加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少必須包括一個RTSP URL。

(10)代理與防火墻友好：協(xié)議可由應(yīng)用和傳輸層防火墻處理。防火墻需要理解SETUP方法，為UDP媒體流打開一個“缺口”。

(11)HTTP友好：此處，RTSP明智地采用HTTP觀念，使現(xiàn)在結(jié)構(gòu)都可重用。結(jié)構(gòu)包括Internet內(nèi)容選擇平臺(PICS)。由于在大多數(shù)情況下控制連續(xù)媒體需要服務(wù)器狀態(tài)，RTSP不僅僅向HTFP添加方法。

(12)適當(dāng)?shù)姆?wù)器控制：如用戶啟動一個流，必須也可以停止一個流。

(13)傳輸協(xié)調(diào)：實際處理連續(xù)媒體流前，用戶可協(xié)調(diào)傳輸方法。

(14)性能協(xié)調(diào)：如基本特征無效，必須有一些清理機(jī)制讓用戶決定哪種方法沒生效。這允許用戶提出適合的用戶界面。

本發(fā)明提供一種將RTSP轉(zhuǎn)換為對象存儲的方式。該系統(tǒng)包括流媒體數(shù)據(jù)源、處理服務(wù)器、流媒體客戶端，系統(tǒng)通過處理服務(wù)器將流媒體數(shù)據(jù)源發(fā)送來的數(shù)據(jù)添加標(biāo)識并存儲到對象存儲中，流媒體客戶端可以直接播放流媒體數(shù)據(jù)源的媒體，也可播放已存儲的媒體數(shù)據(jù)，訪問已存儲的媒體數(shù)據(jù)會優(yōu)先通過P2P的方式訪問其他流媒體客戶端，否則才會向?qū)ο蟠鎯Πl(fā)出請求。

傳統(tǒng)流媒體的后端存儲大多使用集中式存儲，易發(fā)生單點故障，一旦關(guān)鍵的元數(shù)據(jù)服務(wù)器出現(xiàn)問題，性能及可用性都會大受影響；另外后端存儲的性能和容量也無法靈活擴(kuò)展。傳統(tǒng)流媒體后端存儲服務(wù)器通常無法快速響應(yīng)客戶端的播放等控制命令，存在較高的延遲。

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

本發(fā)明的目的在于克服現(xiàn)有技術(shù)的缺點和不足，提供一種將RTSP轉(zhuǎn)換為對象存儲的方式。

本發(fā)明提供的一種將RTSP轉(zhuǎn)換為對象存儲的方式，其特征在于，包括流媒體數(shù)據(jù)源、處理服務(wù)器、流媒體客戶端和對象存儲；流媒體數(shù)據(jù)源連接處理服務(wù)器、流媒體客戶端和對象存儲，處理服務(wù)器連接對象存儲和流媒體客戶端，流媒體客戶端連接對象存儲；

所述流媒體數(shù)據(jù)源，是流媒體資源的提供設(shè)備；

所述處理服務(wù)器，是將所述流媒體數(shù)據(jù)源發(fā)送的流媒體數(shù)據(jù)接收并進(jìn)行處理，最終將數(shù)據(jù)提供給客戶端查看或發(fā)送到對象存儲；

所述流媒體客戶端，是流媒體資源請求者請求資源的工具；

所述對象存儲，是將所述處理服務(wù)器處理后的流媒體數(shù)據(jù)進(jìn)行存儲的設(shè)備。

進(jìn)一步，所述處理服務(wù)器接收來自流媒體數(shù)據(jù)源的流媒體數(shù)據(jù)，使用RTP協(xié)議進(jìn)行數(shù)據(jù)傳輸。

進(jìn)一步，所述流媒體客戶端可以直接播放來自流媒體數(shù)據(jù)源的流媒體，使用RTSP和RTP協(xié)議。

進(jìn)一步，所述處理服務(wù)器在收到流媒體數(shù)據(jù)后會在媒體數(shù)據(jù)中添加標(biāo)識信息，以便訪問。

進(jìn)一步，包含多個流媒體客戶端，之間采用P2P方式共享數(shù)據(jù)。

進(jìn)一步，所述流媒體客戶端在請求已存儲數(shù)據(jù)時會優(yōu)先向其他客戶端發(fā)出請求，如果其他客戶端沒有所需數(shù)據(jù)才會向?qū)ο蟠鎯Πl(fā)出數(shù)據(jù)請求。

進(jìn)一步，使用對象存儲來存儲流媒體信息。

進(jìn)一步，使用Amazon S3作為對象存儲來存儲流媒體信息。

優(yōu)選的，所述流媒體處理服務(wù)器，包括：

接收模塊，用于從所述流媒體數(shù)據(jù)源獲取流媒體信息；

據(jù)標(biāo)識模塊，將從的流媒體數(shù)據(jù)源獲取的數(shù)據(jù)進(jìn)行標(biāo)識，比如添加時間戳等特定信息；

對象存儲模塊，將數(shù)據(jù)標(biāo)識模塊處理過的信息發(fā)送到對象存儲；

數(shù)據(jù)調(diào)度模塊，處理客戶端的請求并將所請求的數(shù)據(jù)的所在信息反饋給客戶端。

優(yōu)選的，所述流媒體客戶端，包括：

播放模塊，用于從所述流媒體數(shù)據(jù)源、其他客戶端或?qū)ο蟠鎯φ埱髷?shù)據(jù)獲取流媒體信息，并對所述流媒體信息進(jìn)行解碼播放；

數(shù)據(jù)緩存模塊，用于建立的流媒體數(shù)據(jù)緩存及流媒體數(shù)據(jù)標(biāo)識列表供數(shù)據(jù)交互模塊查詢；

數(shù)據(jù)交互模塊，用于管理和維護(hù)數(shù)據(jù)緩存，向數(shù)據(jù)處理服務(wù)器或其他客戶端發(fā)送數(shù)據(jù)請求；接收和處理來自其他客戶端的數(shù)據(jù)請求。

本發(fā)明將RTSP轉(zhuǎn)換為對象存儲的方式，流媒體客戶端在請求已存儲數(shù)據(jù)時，包括以下步驟：

S1、客戶端首先向其他客戶端發(fā)出流媒體數(shù)據(jù)請求；

S2、其他客戶端處理請求，若緩存中有所請求數(shù)據(jù)則將數(shù)據(jù)發(fā)送；

S3、若其他客戶端緩存中無所請求數(shù)據(jù)，則原客戶端則向?qū)ο蟠鎯φ埱髷?shù)據(jù)。

本發(fā)明的優(yōu)點是：對象存儲過程中對媒體數(shù)據(jù)進(jìn)行優(yōu)化，加入通道號或者索引提高數(shù)據(jù)讀取性能；使用緩存處理數(shù)據(jù)對IO進(jìn)行合并操作，避免頻繁寫盤，延長底層存儲介質(zhì)壽命并提高寫入性能；客戶端在讀取數(shù)據(jù)時優(yōu)先在所有客戶端緩存中查找，未命中再向?qū)ο蟠鎯φ埱?，能夠提高讀取效率進(jìn)而能夠快速響應(yīng)客戶端的播放、拖放等操作，并降低了讀操作對后端對象存儲性能的影響。

附圖說明

此處所說明的附圖用來提供對本發(fā)明的進(jìn)一步理解，構(gòu)成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當(dāng)限定。在附圖中：

圖1為本發(fā)明將RTSP轉(zhuǎn)換為對象存儲的總框架圖；

圖2為本發(fā)明客戶端請求已存儲數(shù)據(jù)的流程示意圖。

具體實施方式

下面可以參照附圖1-2以及文字內(nèi)容理解本發(fā)明的內(nèi)容以及本發(fā)明與現(xiàn)有技術(shù)之間的區(qū)別點。下文通過附圖以及列舉本發(fā)明的一些可選實施例的方式，對本發(fā)明的技術(shù)方案(包括優(yōu)選技術(shù)方案)做進(jìn)一步的詳細(xì)描述。需要說明的是：本實施例中的任何技術(shù)特征、任何技術(shù)方案均是多種可選的技術(shù)特征或可選的技術(shù)方案中的一種或幾種，為了描述簡潔的需要本文件中無法窮舉本發(fā)明的所有可替代的技術(shù)特征以及可替代的技術(shù)方案，也不便于每個技術(shù)特征的實施方式均強(qiáng)調(diào)其為可選的多種實施方式之一，所以本領(lǐng)域技術(shù)人員應(yīng)該知曉：可以將本發(fā)明提供的任意技術(shù)手段進(jìn)行替換或?qū)⒈景l(fā)明提供的任意兩個或更多個技術(shù)手段或技術(shù)特征互相進(jìn)行組合而得到新的技術(shù)方案。本實施例內(nèi)的任何技術(shù)特征以及任何技術(shù)方案均不限制本發(fā)明的保護(hù)范圍，本發(fā)明的保護(hù)范圍應(yīng)該包括本領(lǐng)域技術(shù)人員不付出創(chuàng)造性勞動所能想到的任何替代技術(shù)方案以及本領(lǐng)域技術(shù)人員將本發(fā)明提供的任意兩個或更多個技術(shù)手段或技術(shù)特征互相進(jìn)行組合而得到的新的技術(shù)方案。

下面結(jié)合圖1-2對本發(fā)明提供的技術(shù)方案進(jìn)行更為詳細(xì)的闡述。

一種將RTSP轉(zhuǎn)換為對象存儲的方式，其特征在于，包括流媒體數(shù)據(jù)源、處理服務(wù)器、流媒體客戶端和對象存儲；流媒體數(shù)據(jù)源連接處理服務(wù)器、流媒體客戶端和對象存儲，處理服務(wù)器連接對象存儲和流媒體客戶端，流媒體客戶端連接對象存儲；所述流媒體數(shù)據(jù)源，是流媒體資源的提供設(shè)備；所述處理服務(wù)器，是將所述流媒體數(shù)據(jù)源發(fā)送的流媒體數(shù)據(jù)接收并進(jìn)行處理，最終將數(shù)據(jù)提供給客戶端查看或發(fā)送到對象存儲；所述流媒體客戶端，是流媒體資源請求者請求資源的工具，本實施例包括流媒體客戶端1和流媒體客戶端2；所述對象存儲，是將所述處理服務(wù)器處理后的流媒體數(shù)據(jù)進(jìn)行存儲的設(shè)備；流媒體客戶端1或者2在讀取數(shù)據(jù)時無需經(jīng)過處理服務(wù)器，直接從對象存儲中讀取就可以，數(shù)據(jù)在哪里存儲客戶端可以通過一套算法計算出具體數(shù)據(jù)對象在哪個對象存儲中的主機(jī)上。

實施例2

如實施例1所述一種將RTSP轉(zhuǎn)換為對象存儲的方式，所述處理服務(wù)器接收來自流媒體數(shù)據(jù)源的流媒體數(shù)據(jù)，使用RTP協(xié)議進(jìn)行數(shù)據(jù)傳輸；所述流媒體客戶端可以直接播放來自流媒體數(shù)據(jù)源的流媒體，使用RTSP和RTP協(xié)議；所述處理服務(wù)器在收到流媒體數(shù)據(jù)后會在媒體數(shù)據(jù)中添加標(biāo)識信息，以便訪問；包含多個流媒體客戶端，之間采用P2P方式共享數(shù)據(jù)；所述流媒體客戶端在請求已存儲數(shù)據(jù)時會優(yōu)先向其他客戶端發(fā)出請求，如果其他客戶端沒有所需數(shù)據(jù)才會向?qū)ο蟠鎯Πl(fā)出數(shù)據(jù)請求；使用Amazon S3作為對象存儲來存儲流媒體信息。

實施例3

如實施例1或2所述一種將RTSP轉(zhuǎn)換為對象存儲的方式，所述流媒體處理服務(wù)器，包括：接收模塊，用于從所述流媒體數(shù)據(jù)源獲取流媒體信息；據(jù)標(biāo)識模塊，將從的流媒體數(shù)據(jù)源獲取的數(shù)據(jù)進(jìn)行標(biāo)識，比如添加時間戳等特定信息；對象存儲模塊，將數(shù)據(jù)標(biāo)識模塊處理過的信息發(fā)送到對象存儲；數(shù)據(jù)調(diào)度模塊，處理客戶端的請求并將所請求的數(shù)據(jù)的所在信息反饋給客戶端。

實施例4

如實施例1或2或3所述一種將RTSP轉(zhuǎn)換為對象存儲的方式，所述流媒體客戶端，包括：播放模塊，用于從所述流媒體數(shù)據(jù)源、其他客戶端或?qū)ο蟠鎯φ埱髷?shù)據(jù)獲取流媒體信息，并對所述流媒體信息進(jìn)行解碼播放；數(shù)據(jù)緩存模塊，用于建立的流媒體數(shù)據(jù)緩存及流媒體數(shù)據(jù)標(biāo)識列表供數(shù)據(jù)交互模塊查詢；數(shù)據(jù)交互模塊，用于管理和維護(hù)數(shù)據(jù)緩存，向數(shù)據(jù)處理服務(wù)器或其他客戶端發(fā)送數(shù)據(jù)請求；接收和處理來自其他客戶端的數(shù)據(jù)請求。

本發(fā)明將RTSP轉(zhuǎn)換為對象存儲的方式，流媒體客戶端在請求已存儲數(shù)據(jù)時，包括以下步驟：

S1、客戶端首先向其他客戶端發(fā)出流媒體數(shù)據(jù)請求；

S2、其他客戶端處理請求，若緩存中有所請求數(shù)據(jù)則將數(shù)據(jù)發(fā)送；

S3、若其他客戶端緩存中無所請求數(shù)據(jù)，則原客戶端則向?qū)ο蟠鎯φ埱髷?shù)據(jù)。

最后應(yīng)當(dāng)說明的是:以上實施例僅用以說明本發(fā)明的技術(shù)方案而非對其限制；盡管參照較佳實施例對本發(fā)明進(jìn)行了詳細(xì)的說明，所屬領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解：依然可以對本發(fā)明的具體實施方式進(jìn)行修改或者對部分技術(shù)特征進(jìn)行等同替換；而不脫離本發(fā)明技術(shù)方案的精神，其均應(yīng)涵蓋在本發(fā)明請求保護(hù)的技術(shù)方案范圍當(dāng)中。