Rtmp與rudp結(jié)合的實時流媒體直播系統(tǒng)的制作方法
【技術(shù)領(lǐng)域】
[0001 ]本發(fā)明涉及計算機網(wǎng)絡(luò)技術(shù)領(lǐng)域，尤其涉及一種RTMP與RUDP結(jié)合的實時流媒體直播系統(tǒng)。
【背景技術(shù)】
[0002]流媒體技術(shù)是把連續(xù)的影像和聲音信息經(jīng)過壓縮處理后放上網(wǎng)站服務器，讓用戶一邊下載一邊觀看、收聽，而不要等整個壓縮文件下載到自己的計算機上才可以觀看的網(wǎng)絡(luò)傳輸技術(shù)。在網(wǎng)上進行流媒體傳輸時，技術(shù)方面，所傳輸?shù)奈募仨氈谱鞒蛇m合流媒體傳輸?shù)牧髅襟w格式文件，傳輸方面，流媒體的傳輸需要合適的傳輸協(xié)議，在Internet上的文件傳輸大部分都是建立在TCP協(xié)議的基礎(chǔ)上，也有一些是以FTP傳輸協(xié)議的方式進行傳輸，但采用這些傳輸協(xié)議都不能實現(xiàn)實時方式的傳輸。隨著流媒體技術(shù)的深入研究，比較成熟的流媒體傳輸一般都是采用建立在UDP協(xié)議上的RTP/RTSP實時傳輸協(xié)議。
[0003]流媒體的傳輸技術(shù)分兩種，一種是順序流式傳輸，另一種是實時流式傳輸。順序流式傳輸是順序下載，在下載文件的同時用戶可以觀看，但是，用戶的觀看與服務器上的傳輸并不是同步進行的，用戶是在一段延時后才能看到服務器上傳出來的信息，或者說用戶看到的總是服務器在若干時間以前傳出來的信息。在這過程中，用戶只能觀看已下載的那部分，而不能要求跳到還未下載的部分。
[0004]在實時流式傳輸中，音視頻信息可被實時觀看到。在觀看過程中用戶可快進或后退以觀看前面或后面的內(nèi)容，但是在這種傳輸方式中，如果網(wǎng)絡(luò)傳輸狀況不理想，則收到的信號效果比較差。

【發(fā)明內(nèi)容】

[0005 ]針對上述問題中存在的不足之處，本發(fā)明提供一種RTMP與RUDP結(jié)合的實時流媒體直播系統(tǒng)。
[0006]為實現(xiàn)上述目的，本發(fā)明提供一種RTMP與RUDP結(jié)合的實時流媒體直播系統(tǒng)，包括:物理架構(gòu)和邏輯架構(gòu)；
[0007]所述物理架構(gòu)采用三級交換網(wǎng)絡(luò)，一級交換網(wǎng)絡(luò)為媒體轉(zhuǎn)發(fā)服務器MTS，用于接收通過RUDP傳輸?shù)牧髅襟w信息；二級交換網(wǎng)絡(luò)為流媒體服務器MSS，所述MSS與所述MTS相連，用于接收MTS通過RTMP推流的信息；三級交換網(wǎng)絡(luò)為用戶界面層，用戶界面層與所述MSS相連，用于訪問MSS;
[0008]所述邏輯架構(gòu)采用四層架構(gòu)，從底層至上層依次為Linux內(nèi)核、網(wǎng)絡(luò)層、MTS層和接口層;所述網(wǎng)絡(luò)層通過API接口訪問Linux內(nèi)核。
[0009]作為本發(fā)明的進一步改進，所述MSS包括多個內(nèi)容分發(fā)網(wǎng)絡(luò)⑶N，每一個所述⑶N包括一個源流媒體服務器MSS origin和多個邊界流媒體服務器MSS edge。
[0010]作為本發(fā)明的進一步改進，所述用戶界面層與MSS之間是雙向訪問和互動的。
[0011]作為本發(fā)明的進一步改進，所述網(wǎng)絡(luò)層包括網(wǎng)絡(luò)適配層、NetAPI接口和EventDr i ve，其中NetAPI接口遵循TCP/UDP協(xié)議，event Dr ive通過epol I函數(shù)進行Linux訪問。
[0012]作為本發(fā)明的進一步改進，所述MTS層包括房間管理模塊、游客管理模塊、認證鑒權(quán)模塊、媒體轉(zhuǎn)發(fā)模塊、直播推流模塊和故障管理模塊中的一種或多種。
[0013]作為本發(fā)明的進一步改進，所述接口層包括媒體資源管理服務器接口MRSinterface、媒體任務管理服務器接口MTM interface、流媒體服務器接口MSS interface和客戶端器接口Client interface中的一種或多種。
[0014]本發(fā)明還公開了一種RTMP與RUDP結(jié)合的實時流媒體直播系統(tǒng)的推流方法，包括:
[0015]步驟一、流媒體從助手端通過RUDP實時傳輸至MTS，所述流媒體包括音頻、視頻數(shù)據(jù)包；
[0016]步驟二、流媒體進入MTS的緩沖隊列進行去抖動后，判斷緩沖隊列中是否有數(shù)據(jù)，若有數(shù)據(jù)，則進入步驟三；
[0017]步驟三、將數(shù)據(jù)封裝成RTMP流推送至MSS中，然后判斷是否結(jié)束直播，如果是，則關(guān)閉直播，結(jié)束推送。
[0018]作為本發(fā)明的進一步改進，所述步驟二中，若緩沖隊列中沒有數(shù)據(jù)，則MTS繼續(xù)接收助手端推送的流媒體，并重復步驟一。
[0019]作為本發(fā)明的進一步改進，所述步驟三中，如果不結(jié)束直播，則MTS繼續(xù)接收助手端推送的流媒體，并重復步驟一。
[0020]作為本發(fā)明的進一步改進，
[0021 ]所述將數(shù)據(jù)封裝成RTMP流推送至MSS中包括:
[0022]數(shù)據(jù)封裝成RTMP流推送至源流媒體服務器MSS origin中；
[0023]在每個⑶N的內(nèi)部，源流媒體服務器MSS origin通過RTMP將流媒體信息推送到多個MSS edge 中；
[0024]用戶界面層通過邊界流媒體服務器MSSedge接收流媒體信息或與邊界流媒體服務器MSS edge進行交互。
[0025]與現(xiàn)有技術(shù)相比，本發(fā)明的有益效果為:
[0026]本發(fā)明公開的RTMP與RUDP結(jié)合的實時流媒體直播系統(tǒng)，在MTS接收流媒體信息時，采用RUDP協(xié)議;在MTS將流媒體信息推送至MSS時，采用RTMP協(xié)議，RUDP主要為了彌補RTMP復雜網(wǎng)絡(luò)環(huán)境下傳輸信號差的缺陷;本發(fā)明可以使整個系統(tǒng)的分發(fā)效率提高一倍，提高復雜網(wǎng)絡(luò)環(huán)境下直播系統(tǒng)中音視頻流媒體的傳輸質(zhì)量和傳輸效率，并且無需安裝客戶端程序；
[0027]本發(fā)明公開的CDN采用流媒體服務器集群技術(shù)，克服單機系統(tǒng)輸出帶寬及并發(fā)能力不足的缺點，可極大提升系統(tǒng)支持的并發(fā)流數(shù)目，減少或避免單點失效帶來的不良影響。
【附圖說明】
[0028]圖1為本發(fā)明一種實施例公開的RTMP與RUDP結(jié)合的實時流媒體直播系統(tǒng)的物理架構(gòu)圖；
[0029]圖2為本發(fā)明一種實施例公開的RTMP與RUDP結(jié)合的實時流媒體直播系統(tǒng)的邏輯架構(gòu)圖；
[0030]圖3為本發(fā)明一種實施例公開的RTMP與RUDP結(jié)合的實時流媒體直播系統(tǒng)的推送流程圖；
[0031]圖4為本發(fā)明一種實施例公開的RTMP與RUDP結(jié)合的實時流媒體直播系統(tǒng)的⑶N分發(fā)流程圖。
[0032]圖中:1、媒體轉(zhuǎn)發(fā)服務器MTS;2、流媒體服務器MSS;3、用戶界面層;4、Linux內(nèi)核；
5、網(wǎng)絡(luò)層;6、MTS層;7、接口層。
【具體實施方式】
[0033]為使本發(fā)明實施例的目的、技術(shù)方案和優(yōu)點更加清楚，下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例是本發(fā)明的一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動的前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。
[0034]本發(fā)明提供一種RTMP與RUDP結(jié)合的實時流媒體直播系統(tǒng)，包括:物理架構(gòu)和邏輯架構(gòu)；物理架構(gòu)采用三級交換網(wǎng)絡(luò)，一級交換網(wǎng)絡(luò)為媒體轉(zhuǎn)發(fā)服務器MTS，用于接收通過RUDP傳輸?shù)牧髅襟w信息；二級交換網(wǎng)絡(luò)為流媒體服務器MSS，MSS與MTS相連，用于接收MTS通過RTMP推流的信息；三級交換網(wǎng)絡(luò)為用戶界面層，用戶界面層與MSS相連，用于訪問MSS;邏輯架構(gòu)采用四層架構(gòu)，從底層至上層依次為Linux內(nèi)核、網(wǎng)絡(luò)層、MTS層和接口層；網(wǎng)絡(luò)層通過API接口訪問Linux內(nèi)核。
[0035]本發(fā)明提供一種RTMP與RUDP結(jié)合的實時流媒體直播系統(tǒng)的推流方法，包括:
[0036]步驟一、流媒體從助手端通過RUDP實時傳輸至MTS，流媒體包括音頻、視頻數(shù)據(jù)包；
[0037]步驟二、流媒體進入MTS的緩沖隊列進行去抖動后，判斷緩沖隊列中是否有數(shù)據(jù)，若有數(shù)據(jù)，則進入步驟三；
[0038]步驟三、將數(shù)據(jù)封裝成RTMP流推送至MSS中，然后判斷是否結(jié)束直播，如果是，則關(guān)閉直播，結(jié)束推送。
[0039]本發(fā)明介紹的RTMP與RUDP結(jié)合的實時流媒體直播系統(tǒng)可以提高復雜網(wǎng)絡(luò)環(huán)境下直播系統(tǒng)中音視頻流媒體的傳輸質(zhì)量和傳輸效率，并且無需安裝客戶端程序，大大簡化了客戶操作的復雜度。
[0040]RTMP協(xié)議全稱是Real Time Messaging Protocol，即實時消息傳送協(xié)議，用于在Flash平臺之間傳遞視音頻以及數(shù)據(jù)。與RTSP和RTP組合提供流媒體服務的方式不同，RTMP協(xié)議本身既可以傳輸多媒體數(shù)據(jù)也可以控制多媒體播放。RTMP協(xié)議使用TCP協(xié)議作為其傳輸層的網(wǎng)絡(luò)協(xié)議。TCP是面向連接的，提供可靠交付的協(xié)議，因此在互聯(lián)網(wǎng)上傳輸時不會出現(xiàn)丟包情況，從而保證了用戶體驗(QoE)。但是TCP協(xié)議提供可靠交付的代價就是增加了一些額外的開銷，占用了一些帶寬和處理機資源。UDP雖然開銷小，速率高但它是基于消息的不可靠傳遞協(xié)議。直播系統(tǒng)對視音頻傳輸要求具備一定的可靠性，為此就自然地考慮到在UDP的基礎(chǔ)上增加一些為保證可靠數(shù)據(jù)傳遞所必需的功能使其成為一個基于消息的可靠傳遞協(xié)議這就是RUDP協(xié)議。支持RTMP協(xié)議的流媒體客戶端可以制作成一個普通的Flash文件，只要安裝過Flash Player的網(wǎng)頁瀏覽器就可以自動下載該文件并運行它。而Flash Player是一個上網(wǎng)必備的插件。據(jù)統(tǒng)計，全世界98%的網(wǎng)頁瀏覽器都安裝了Flash Player。因此，普通用戶不需要任何操作，只要使用網(wǎng)頁瀏覽器打開播放頁面，就可以收看流媒體。
[0041 ] RUDP主要是為了彌補RTMP復雜網(wǎng)絡(luò)環(huán)境下傳輸信號差的缺陷，因為RTMP是基于TCP的。本發(fā)明可以使整個系統(tǒng)的分發(fā)效率提高一倍，是因為MSS