本發(fā)明涉及網(wǎng)絡(luò)通信領(lǐng)域以及流媒體通信領(lǐng)域；更具體地說，本發(fā)明涉及一種多終端多協(xié)議流媒體發(fā)布方法。

背景技術(shù)：

流媒體(Streaming Media)指在數(shù)據(jù)網(wǎng)絡(luò)上按時間先后次序傳輸和播放的連續(xù)的音/視頻數(shù)據(jù)流。最早，用戶在網(wǎng)絡(luò)上觀看視頻或者收聽音頻時，必須先將整個影音文件下載并存儲在本地計算機上，然后才可以觀看。與這種下載后播放的傳統(tǒng)播放方式不同的是，流媒體在播放前并不下載整個文件，只將部分內(nèi)容緩存，同時剩余流媒體數(shù)據(jù)流則邊傳送邊播放，這樣就節(jié)省了下載等待時間和存儲空間。

流媒體數(shù)據(jù)流具有三個特點：連續(xù)性(Continuous)、實時性(Real-time)、時序性，即其數(shù)據(jù)流具有嚴(yán)格的前后時序關(guān)系。

為了實現(xiàn)流媒體的傳輸，現(xiàn)有技術(shù)提出了一些具體的解決方案，例如：

實時流協(xié)議RTSP(Real Time Streaming Protocol)是由哥倫比亞大學(xué)、網(wǎng)景Netscape和RealNetworks(RealPlayer播放器的制造商)共同提出的，該協(xié)議定義了一對多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。

MMS協(xié)議(Microsoft Media Server protocol)用來訪問并流式接收WindowsMedia服務(wù)器中.asf文件的一種協(xié)議。MMS協(xié)議用于訪問Windows Media發(fā)布點上的單播內(nèi)容。MMS是連接WindowsMedia單播服務(wù)的默認(rèn)方法。若觀眾在Windows Media Player中鍵入一個URL以連接內(nèi)容，而不是通過超級鏈接訪問內(nèi)容，則他們必須使用MMS協(xié)議引用該流。

但是，在現(xiàn)有技術(shù)中，還沒有很好的解決方案能夠?qū)崿F(xiàn)流媒體的全平臺(例如包括iOS、安卓、Windows、Mac)適配播放。

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

本發(fā)明所要解決的技術(shù)問題是針對現(xiàn)有技術(shù)中存在上述缺陷，提供一種能夠?qū)崿F(xiàn)流媒體的全平臺(例如包括iOS、安卓、Windows、Mac)適配播放的多終端多協(xié)議流媒體發(fā)布方法。

根據(jù)本發(fā)明，提供了一種多終端多協(xié)議流媒體發(fā)布方法，包括：

第一步驟：直播錄播發(fā)起方利用第一數(shù)據(jù)格式向直播錄播云端的直播服務(wù)器和錄播服務(wù)器傳送流媒體數(shù)據(jù)；

第二步驟：直播服務(wù)器和錄播服務(wù)器分別對接收到的流媒體數(shù)據(jù)進(jìn)行錄制轉(zhuǎn)碼和存儲；

第三步驟：直播錄播云端基于第一網(wǎng)絡(luò)協(xié)議向第一類接收終端傳送經(jīng)錄制轉(zhuǎn)碼和存儲的流媒體數(shù)據(jù)；

第四步驟：直播錄播云端基于第二網(wǎng)絡(luò)協(xié)議向第二類接收終端傳送經(jīng)錄制轉(zhuǎn)碼和存儲的流媒體數(shù)據(jù)。

優(yōu)選地，第一數(shù)據(jù)格式為h.264格式或者M(jìn)P4格式。

優(yōu)選地，第一網(wǎng)絡(luò)協(xié)議是路由選擇表維護(hù)協(xié)議，而且第一類接收終端包含安卓終端、Windows終端和MAC終端。

優(yōu)選地，第一類接收終端通過Flash播放器觀看直播和/或錄播。

優(yōu)選地，第二網(wǎng)絡(luò)協(xié)議是HLS協(xié)議，而且第二類接收終端包含iOS終端。

優(yōu)選地，第二類接收終端通過HTML5播放器觀看直播和/或錄播。

本發(fā)明通過一種特殊的視頻文件加載格式實現(xiàn)了一個直播/錄播音視頻流即可實現(xiàn)流媒體的全平臺(iOS、安卓、Windows、Mac)適配播放。本發(fā)明實現(xiàn)了直播/錄播一次發(fā)布即可同時支持多種協(xié)議(RTMP/HLS)多種終端(iOS、安卓、PC及Mac)流暢高清播放。而且，本發(fā)明可以自動適配客戶端平臺并選擇合適的播放器格式，例如HTML5播放器或者Flash播放器。

本發(fā)明兼容性強，一個直播/錄播流適配多種協(xié)議多種平臺；而且，本發(fā)明可以適應(yīng)多種場景，既支持直播又支持錄播。

附圖說明

結(jié)合附圖，并通過參考下面的詳細(xì)描述，將會更容易地對本發(fā)明有更完整的理解并且更容易地理解其伴隨的優(yōu)點和特征，其中：

圖1示意性地示出了根據(jù)本發(fā)明優(yōu)選實施例的多終端多協(xié)議流媒體發(fā)布方法的示意圖。

需要說明的是，附圖用于說明本發(fā)明，而非限制本發(fā)明。注意，表示結(jié)構(gòu)的附圖可能并非按比例繪制。并且，附圖中，相同或者類似的元件標(biāo)有相同或者類似的標(biāo)號。

具體實施方式

為了使本發(fā)明的內(nèi)容更加清楚和易懂，下面結(jié)合具體實施例和附圖對本發(fā)明的內(nèi)容進(jìn)行詳細(xì)描述。

圖1示意性地示出了根據(jù)本發(fā)明優(yōu)選實施例的多終端多協(xié)議流媒體發(fā)布方法的示意圖。

如圖1所示，根據(jù)本發(fā)明優(yōu)選實施例的多終端多協(xié)議流媒體發(fā)布方法包括：

第一步驟：直播錄播發(fā)起方10利用第一數(shù)據(jù)格式向直播錄播云端20的直播服務(wù)器21和錄播服務(wù)器22傳送流媒體數(shù)據(jù)；

例如，第一數(shù)據(jù)格式為h.264格式或者M(jìn)P4格式。

第二步驟：直播服務(wù)器21和錄播服務(wù)器22分別對接收到的流媒體數(shù)據(jù)進(jìn)行錄制轉(zhuǎn)碼和存儲；

第三步驟：直播錄播云端基于第一網(wǎng)絡(luò)協(xié)議向第一類接收終端30傳送經(jīng)錄制轉(zhuǎn)碼和存儲的流媒體數(shù)據(jù)；

例如，第一網(wǎng)絡(luò)協(xié)議是路由選擇表維護(hù)協(xié)議(Real-Time Messaging Protocol，RTMP)，而且第一類接收終端包含安卓終端、Windows終端和MAC終端。這樣，用戶可以在安卓終端、Windows終端及Mac終端通過RTMP傳輸數(shù)據(jù)流，客戶端通過Flash播放器觀看直播/錄播。

第四步驟：直播錄播云端基于第二網(wǎng)絡(luò)協(xié)議向第二類接收終端40傳送經(jīng)錄制轉(zhuǎn)碼和存儲的流媒體數(shù)據(jù)。

例如，第二網(wǎng)絡(luò)協(xié)議是HLS(Http Live Streaming)協(xié)議，而且第二類接收終端包含iOS終端。這樣，用戶可以在iOS設(shè)備通過HLS協(xié)議傳輸數(shù)據(jù)流，客戶端通過HTML5播放器觀看直播/錄播。

由此，服務(wù)端支持多協(xié)議視頻流讀取，客戶端支持多協(xié)議多格式播放視頻，服務(wù)端和客戶端通過一種特殊的文件格式實現(xiàn)通信。

舉例來說，直播/錄播通信文件格式的示例可以如下所示：

總之，本發(fā)明通過一種特殊的視頻文件加載格式實現(xiàn)了一個直播/錄播音視頻流即可實現(xiàn)流媒體的全平臺(iOS、安卓、Windows、Mac)適配播放。本發(fā)明實現(xiàn)了直播/錄播一次發(fā)布即可同時支持多種協(xié)議(RTMP/HLS)多種終端(iOS、安卓、PC及Mac)流暢高清播放。而且，本發(fā)明可以自動適配客戶端平臺并選擇合適的播放器格式，例如HTML5播放器或者Flash播放器。

本發(fā)明兼容性強，一個直播/錄播流適配多種協(xié)議多種平臺；而且，本發(fā)明可以適應(yīng)多種場景，既支持直播又支持錄播。

需要說明的是，除非特別指出，否則說明書中的術(shù)語“第一”、“第二”、“第三”等描述僅僅用于區(qū)分說明書中的各個組件、元素、步驟等，而不是用于表示各個組件、元素、步驟之間的邏輯關(guān)系或者順序關(guān)系等。

可以理解的是，雖然本發(fā)明已以較佳實施例披露如上，然而上述實施例并非用以限定本發(fā)明。對于任何熟悉本領(lǐng)域的技術(shù)人員而言，在不脫離本發(fā)明技術(shù)方案范圍情況下，都可利用上述揭示的技術(shù)內(nèi)容對本發(fā)明技術(shù)方案作出許多可能的變動和修飾，或修改為等同變化的等效實施例。因此，凡是未脫離本發(fā)明技術(shù)方案的內(nèi)容，依據(jù)本發(fā)明的技術(shù)實質(zhì)對以上實施例所做的任何簡單修改、等同變化及修飾，均仍屬于本發(fā)明技術(shù)方案保護(hù)的范圍內(nèi)。