一種多媒體數(shù)據(jù)的傳輸方法及系統(tǒng)的制作方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及互聯(lián)網(wǎng)技術(shù)領(lǐng)域,尤其涉及一種多媒體數(shù)據(jù)的傳輸方法及系統(tǒng)。
【背景技術(shù)】
[0002]隨著互聯(lián)網(wǎng)技術(shù),尤其是移動互聯(lián)技術(shù)的飛速發(fā)展,除了依靠傳統(tǒng)網(wǎng)站分享文字、圖片音視頻等信息,移動端、web端等用戶平臺也在逐步占領(lǐng)市場。這就需要構(gòu)建更為復雜的多媒體數(shù)據(jù)傳輸網(wǎng)絡。
[0003]但是,目前各大運營商所使用最為廣泛的還是傳統(tǒng)視頻服務器,并針對不同的用戶平臺采取不同的通信協(xié)議,例如:針對電腦客戶端設計采用RTSP (Real Time StreamingProtocol,實時流傳輸協(xié)議),針對 web 端采用 RTMP (Real Time Messaging Protocol,實時消息傳送協(xié)議),針對手機端采用RTSP協(xié)議來傳輸視頻,以及其他多種常用的協(xié)議,比如MMS (Microsoft Media Server 一種串流媒體傳送協(xié)議)。
[0004]當通過傳統(tǒng)的視頻服務器為不同的用戶平臺提供同樣內(nèi)容的媒體數(shù)據(jù)時,就需要同步不同的協(xié)議環(huán)境。但是在目前的異構(gòu)系統(tǒng)中,由于多媒體數(shù)據(jù)不同于普通http請求,需要占用大量帶寬、CPU、內(nèi)存以及其他服務器資源,來處理多媒體數(shù)據(jù)。傳統(tǒng)的視頻服務器在處理不同平臺對應的協(xié)議的時,往往會造成多終端不同步的問題,比如:掉線、視頻丟包、花屏、卡頓、聲音不同步等。使得多用戶平臺的多媒體數(shù)據(jù)的實時交互的難度較大,限制了多用戶平臺實時交互技術(shù)的應用。
【發(fā)明內(nèi)容】
[0005]本發(fā)明的實施例提供一種多媒體數(shù)據(jù)的傳輸方法及系統(tǒng),能夠?qū)崿F(xiàn)不同的協(xié)議環(huán)境的同步,降低了多用戶平臺的多媒體數(shù)據(jù)的實時交互的難度。
[0006]為達到上述目的,本發(fā)明的實施例采用如下技術(shù)方案:
第一方面,本發(fā)明的實施例提供一種多媒體數(shù)據(jù)的傳輸方法,包括:
根據(jù)源媒體數(shù)據(jù)創(chuàng)建內(nèi)部媒體流;
將所述內(nèi)部媒體流關(guān)聯(lián)外部媒體流,并按照外部媒體流的協(xié)議和格式轉(zhuǎn)換源媒體數(shù)據(jù),所述外部媒體流被用于在端口發(fā)布,所述端口傳輸數(shù)據(jù)的協(xié)議和格式為所述外部媒體流的協(xié)議和格式;
將轉(zhuǎn)換后的源媒體數(shù)據(jù)通過所述外部媒體流在所述端口發(fā)布。
[0007]第二方面,本發(fā)明的實施例提供一種多媒體數(shù)據(jù)的傳輸系統(tǒng),所述系統(tǒng)包括:主服務器、至少一個從服務器、源媒體數(shù)據(jù)的發(fā)布端和接收端,所述主服務器與所述至少一個從服務器相連,一個從服務器包括至少一種數(shù)據(jù)端口 ;
所述至少一個從服務器,用于創(chuàng)建的外部媒體流;
所述主服務器,用于連接發(fā)布端,并從所述發(fā)布端獲取所述源媒體數(shù)據(jù);并用于根據(jù)所述源媒體數(shù)據(jù)創(chuàng)建內(nèi)部媒體流;再將所述內(nèi)部媒體流綁定所述至少一個從服務器創(chuàng)建的外部媒體流; 所述主服務器,還用于將所述源媒體數(shù)據(jù),按照發(fā)送請求的從服務器的端口的協(xié)議和格式進行轉(zhuǎn)換,并向所述發(fā)送請求的從服務器傳輸;
所述發(fā)送請求的從服務器,用于將轉(zhuǎn)換后的源媒體數(shù)據(jù)通過所述外部媒體流在所述端口發(fā)布。
[0008]本發(fā)明實施例提供的多媒體數(shù)據(jù)的傳輸方法及系統(tǒng),通過采用單服務器(即主服務器)進行源媒體數(shù)據(jù)的協(xié)議和格式轉(zhuǎn)換,將源媒體數(shù)據(jù)轉(zhuǎn)換為不同格式的媒體流,保證了數(shù)據(jù)的一致性和轉(zhuǎn)換的高效性,并建立內(nèi)部媒體流。并采用至少一個從服務器,或者多服務集群技術(shù)(即多個從服務器),使得從服務器、多服務集群技術(shù)保證了高并發(fā)請求的響應和系統(tǒng)的負載均衡,實現(xiàn)了不同的協(xié)議環(huán)境的同步,降低了多用戶平臺的多媒體數(shù)據(jù)的實時交互的難度。
【附圖說明】
[0009]為了更清楚地說明本發(fā)明實施例中的技術(shù)方案,下面將對實施例中所需要使用的附圖作簡單地介紹,顯而易見地,下面描述中的附圖僅僅是本發(fā)明的一些實施例,對于本領(lǐng)域普通技術(shù)人員來講,在不付出創(chuàng)造性勞動的前提下,還可以根據(jù)這些附圖獲得其它的附圖。
[0010]圖1為本發(fā)明實施例提供的多媒體數(shù)據(jù)的傳輸方法的流程圖;
圖2為本發(fā)明實施例提供的多媒體數(shù)據(jù)的傳輸系統(tǒng)的架構(gòu)示意圖;
圖3、圖4、圖5為本發(fā)明實施例提供的多媒體數(shù)據(jù)的傳輸方法的具體實例的示意圖; 圖6為本發(fā)明實施例提供的一種應用于多媒體數(shù)據(jù)的傳輸系統(tǒng)的服務器的結(jié)構(gòu)示意圖。
【具體實施方式】
[0011]為使本領(lǐng)域技術(shù)人員更好地理解本發(fā)明的技術(shù)方案,下面結(jié)合附圖和【具體實施方式】對本發(fā)明作進一步詳細描述。下文中將詳細描述本發(fā)明的實施方式,所述實施方式的示例在附圖中示出,其中自始至終相同或類似的標號表示相同或類似的元件或具有相同或類似功能的元件。下面通過參考附圖描述的實施方式是示例性的,僅用于解釋本發(fā)明,而不能解釋為對本發(fā)明的限制。
[0012]本技術(shù)領(lǐng)域技術(shù)人員可以理解,除非特意聲明,這里使用的單數(shù)形式“一”、“一個”、“所述”和“該”也可包括復數(shù)形式。應該進一步理解的是,本發(fā)明的說明書中使用的措辭“包括”是指存在所述特征、整數(shù)、步驟、操作、元件和/或組件,但是并不排除存在或添加一個或多個其他特征、整數(shù)、步驟、操作、元件、組件和/或它們的組。應該理解,當我們稱元件被“連接”或“耦接”到另一元件時,它可以直接連接或耦接到其他元件,或者也可以存在中間元件。此外,這里使用的“連接”或“耦接”可以包括無線連接或耦接。這里使用的措辭“和/或”包括一個或更多個相關(guān)聯(lián)的列出項的任一單元和全部組合。
[0013]本技術(shù)領(lǐng)域技術(shù)人員可以理解,除非另外定義,這里使用的所有術(shù)語(包括技術(shù)術(shù)語和科學術(shù)語)具有與本發(fā)明所屬領(lǐng)域中的普通技術(shù)人員的一般理解相同的意義。還應該理解的是,諸如通用字典中定義的那些術(shù)語應該被理解為具有與現(xiàn)有技術(shù)的上下文中的意義一致的意義,并且除非像這里一樣定義,不會用理想化或過于正式的含義來解釋。
[0014]在下文的描述中,將以包括觸控顯示器的智能終端為實施例,其顯示器上配置有可觸控界面。在以下詳細描述中,許多具體細節(jié)被示出以提供對本發(fā)明的深入了解。然而,本發(fā)明可能在沒有這些具體細節(jié)的情況下被實施對于本領(lǐng)域的普通技術(shù)人員將是顯而易見的。在其他情況下,眾所周知的方法、規(guī)程、部件、電路和網(wǎng)絡未被詳細描述以免不必要地模糊實施例的各個方面
本發(fā)明實施例提供一種多媒體數(shù)據(jù)的傳輸方法,如圖1所示,包括:
101,根據(jù)源媒體數(shù)據(jù)創(chuàng)建內(nèi)部媒體流。
[0015]在本實施例中,源媒體數(shù)據(jù)可以由發(fā)布端向服務器發(fā)送,其中,發(fā)布端可以是視頻服務器、終端設備等,接收源媒體數(shù)據(jù)的服務器可以是如圖2所示系統(tǒng)中的主服務器。
[0016]102,將所述內(nèi)部媒體流關(guān)聯(lián)外部媒體流,并按照外部媒體流的協(xié)議和格式轉(zhuǎn)換源媒體數(shù)據(jù)。
[0017]其中,所述外部媒體流被用于在端口發(fā)布,所述端口傳輸數(shù)據(jù)的協(xié)議和格式為所述外部媒體流的協(xié)議和格式。在本實施例中,在多協(xié)議中實現(xiàn)視頻傳輸,需要實時解包AMF協(xié)議,并解碼FLV視頻幀數(shù)據(jù),并實時分裝為H264視頻格式幀,并在其他視頻協(xié)議通道中傳輸,其中,基于H264編碼格式的視頻數(shù)據(jù),可以在收到視頻連接時,首先解包協(xié)議,同時解碼視頻數(shù)據(jù),然后實時編碼為H264視頻格式數(shù)據(jù),最終根據(jù)訂閱協(xié)議,實時分包為特定協(xié)議。服務器可以根據(jù)性能的要求,利用多核運算提供高性能,高實時數(shù)據(jù)處理機制,并行計算的編碼設計,用多核CPU設計。協(xié)議底層可以均劃分為TCP連接和UDP連接,并分配內(nèi)部流和外部流,內(nèi)部流實現(xiàn)協(xié)議和格式轉(zhuǎn)換,外部流實現(xiàn)數(shù)據(jù)分發(fā)。這種設計減少了內(nèi)存消耗,和對象碎片問題。為了實現(xiàn)無縫連接,以及減少延遲,設計了虛擬流(在本實施例中也可稱為內(nèi)部媒體流)和等待流(在本實施例中也可稱為外部媒體流