• 
    <ul id="o6k0g"></ul>
    <ul id="o6k0g"></ul>

    一種在互聯網發布和直播流媒體的系統技術方案

    技術編號:8582567 閱讀:216 留言:0更新日期:2013-04-15 06:05
    本實用新型專利技術公開一種在互聯網發布和直播流媒體的系統,包括發布客戶端、服務器端和播放客戶端;所述發布客戶端用于讀取和解析正在輸出的多媒體文件,合并并生成流媒體數據分塊,然后以HTTP方法上傳至所述服務器;所述服務器端儲存流媒體數據分塊并構建流媒體數據分段文件;同時,服務器端生成對應流媒體數據分段文件的索引;所述播放客戶端使用HTTP方法從服務器端獲取索引,然后根據索引下載流媒體分段并同時對流媒體分段進行播放。本實用新型專利技術的系統基于HTTP協議體系;能夠低耦合、非侵入、簡單的與采集端應用集成;易于在各種終端平臺上實現;實時直播的延時低、健壯性好、容錯性好;支持在互聯網大規模部署、支持CDN部署方式。(*該技術在2022年保護過期,可自由使用*)

    【技術實現步驟摘要】

    本技術涉及網絡
    ,尤其涉及一種互聯網流媒體的發布和直播技術。
    技術介紹
    互聯網流媒體技術是采用流式傳輸的方式在互聯網上傳輸多媒體文件,把連續的音視頻等多媒體信息經過壓縮處理后存儲于網絡媒體服務器,供互聯網客戶端在下載的同時回放,而無需等待全部多媒體文件下載完成。實時流媒體直播是在采集音視頻信息的同時,使用流媒體技術發布和傳輸正在采集的媒體信息,使客戶端能夠通過互聯網低延時地回放正在采集的媒體信息。現有技術的互聯網流媒體實時直播的實現主要包括如下環節采集和編碼(Encode):采集音視頻信息,采用具體編碼算法,對音頻和視頻信息進行壓縮;多路合并(Muxing):采用具體容器格式,將編碼后的音視頻信息合并于具體的流媒體文件容器;發布(Publish):采用具體傳輸和控制協議,將文件流式傳輸于網絡媒體服務器;交付(Delivery):采用具體傳輸和控制協議,客戶端下載網絡媒體服務器的流媒體;回放(Playback):客戶端根據流媒體的文件容器格式和音視頻信息的編碼算法進行解碼(Demuxing和Decode)并還原呈現所采集的音視頻信息。現有技術在互聯網,尤其是移動互聯網,流媒體實時直播的各個環節所廣泛采用的技術、標準和方案如下音頻編碼方式有AMR、AAC、MP3、Vorbis等;視頻編碼方式有MPEG-2、MPEG-4、H. 263、H. 264、VP6/8 等;文件容器包括MP4、3GPP、FLV、ASF、WebM、MPEG_TS等;流媒體發布所采用的方式完全依賴于流媒體服務器的實現,依據不同的流媒體服務器實現,可能采用的協議有RTP、RTMP、或私有協議;流媒體交付所廣泛采用的協議有RTP/RTSP, RTMP、MMS等;客戶端回放采用各類媒體播放器實現,如Flash Player, HTML5所支持的瀏覽器內置播放器、iPhone/iPad和Android等移動平臺內置播放器及其他播放器應用程序。現有技術中RTP協議采用UDP傳輸,涉及防火墻穿越等復雜性;RTMP協議是Adobe公司技術的基于TCP傳輸的低延時協議,默認端口為1935,而且其協議實現細節并沒有公開,因此完全依賴于其服務器和客戶端實現;同樣,MMS依賴于微軟的媒體服務器和客戶端實現,采用M)P/TCP傳輸,默認端口為1755,同樣涉及防火墻穿越的復雜性。以上這些交付協議在保證QoS (服務質量)時,均需采用較為復雜的控制協議,需要專有的流媒體服務器實現,以提供服務。因此,針對現有技術的不足,蘋果等公司又提出了一些基于HTTP協議的流媒體交付協議如,Http Live Streaming (請參照圖 l)、Http Dynamic Streaming 等。基于 HTTP協議的流媒體交付協議在交付媒體內容時,只依賴于普通的HTTP服務器,使用80端口,不涉及防火墻穿越的復雜性,同時可以采用HTTP協議族所支持的加密或證書等安全措施。其中相比采用了更多私有實現方式的Http Dynamic Streaming, Http Live Streaming的方案更為簡潔,目前在iPhone/iPad和Android 4.0以上的移動客戶端都有內置播放器的支持,并且有越來越多的播放器開始支持這一協議。Http Live Streaming提供了最為簡潔和優雅的,基于HTTP的流媒體交付方案。Http Live Streaming是由蘋果公司提出并實現的基于HTTP的流媒體通信協議。該協議將整個媒體流分成一組連續的可供HTTP下載的小文件分段,分段以MPEG-TS容器格式承載,滿足播放器流式回放的要求;同時提供以m3u8為標準格式的索引,作為這一組分段的索引。客戶端通過HTTP服務器請求m3u8播放列表,根據列表中的索引,依次下載分段。在下載完一個分段后,客戶端即可邊下載后續分段,邊進行播放。通常每個分段定位為承載10秒的音視頻媒體,可以保證在客戶端播放的連續性及合理的資源開銷,并能夠保持延時在30秒左右。另外,服務器可以根據不同的網絡速率提供可選的不同速率的分段組,以適應不同網絡速率的要求。播放列表可以在提供訪問的同時不斷進行更新,以實現實時直播。由于Http Live Streaming僅使用標準Http協議,因此與RTP不同,具備穿越防火墻和代理服務器的能力;同時能夠滿足⑶N (Content Delivery Network)部署的需求。Http Live Streaming系統由服務器端的分段程序、HTTP服務器和客戶端組成(參見附圖1)。服務器分段程序負責將已錄制好的流媒體文件或實時媒體流進行分段,并生成播放列表;HTTP服務器為播放列表和分段文件提供HTTP請求服務;客戶端通過HTTP請求獲取播放列表和流媒體分段文件進行回放。但是,Http Live Streaming并沒有定義和提供由媒體采集端向服務器實時發布流媒體的方法和系統。因此各種Http Live Streaming的發布仍然依賴于流媒體服務的具體實現,采用基于RTP、RTMP或私有協議的方式支持從采集端向媒體服務器實時發布流媒體。由此可見,Http Live Streaming還存在以下兩個缺陷1.完全依賴于特定流媒體服務器的實現,及其所提供的客戶端發布接口。對特定流媒體服務的引入破壞了 Http Live Streaming方案本身的簡潔和優雅;依賴于具體客戶端發布接口,造成采集端的實現和集成的復雜性;2.在采用依賴于RTP/RTSP流媒體通信協議的發布方案時,其控制協議實現復雜,造成采集端和服務器端的實現和集成均具有復雜性,容錯能力有限,系統不穩定。
    技術實現思路
    針對上述現有技術的不足,本技術提供一種延時、健壯性、容錯性好且能夠簡單地與采集端和客戶端集成的完全基于HTTP協議體系的在互聯網發布和直播流媒體的方法及系統。本技術解決其技術問題所采用的技術方案是一種在互聯網發布和直播流媒體的系統,包括服務器端和播放客戶端,其特征在于還包括發布客戶端,用于實時讀取和解析正在輸出的多媒體文件,重新以設定的格式進行媒體流的合并,并按預設的流媒體數據分塊時間生成流媒體數據分塊,然后以HTTP方法上傳至所述服務器;所述服務器端用于處理來自發布客戶端的流媒體數據分塊,儲存流媒體數據分塊并根據預設的流媒體數據分段時間構建流媒體數據分段文件;同時,服務器端生成對應流媒體數據分段文件順序和儲存位置的索引;所述播放客戶端使用HTTP方法從服務器端獲取所述索引,然后根據所述索引下載流媒體分段并同時對流媒體分段進行播放。優選的,所述的在互聯網發布和直播流媒體的系統還包括媒體采集端,用于采集并生成媒體數據并把媒體數據傳遞至所述發布客戶端。優選的,所述發布客戶端包括媒體輸入模塊、發布客戶端音頻編碼模塊、發布客戶端視頻編碼模塊、發布客戶端流媒體處理模塊和發布模塊;所述媒體輸入模塊讀取音頻流和/或視頻流數據并把該音頻流和/或視頻流數據傳輸至所述發布客戶端流媒體處理模塊;所述發布客戶端流媒體處理模塊調用發布客戶端音頻編碼模塊和/或發布客戶端視頻編碼模塊對音頻流和/或視頻流數據重新編碼并根據設定的格式進行媒體流的合并,并按預設的流媒體數據分塊時間生成流媒體數據分塊。優選的本文檔來自技高網
    ...

    【技術保護點】
    一種在互聯網發布和直播流媒體的系統,包括服務器端(2)和播放客戶端(3),其特征在于:還包括發布客戶端(1)包括媒體輸入模塊(11)、發布客戶端音頻編碼模塊(12)、發布客戶端視頻編碼模塊(13)、發布客戶端流媒體處理模塊(14)和發布模塊(15);所述媒體輸入模塊(11)讀取音頻流和/或視頻流數據并把該音頻流和/或視頻流數據傳輸至所述發布客戶端流媒體處理模塊(14);所述發布客戶端流媒體處理模塊(14)調用發布客戶端音頻編碼模塊(12)和/或發布客戶端視頻編碼模塊(13)對音頻流和/或視頻流數據重新編碼并根據設定的格式進行媒體流的合并,并按預設的流媒體數據分塊時間生成流媒體數據分塊;所述服務器端(2)包括網頁服務模塊(21)、服務器流媒體處理模塊(22)和服務器儲存模塊(23);發布客戶端(1)發布模塊(15)與網頁服務模塊(21)交互并上傳所述流媒體分塊,服務器流媒體處理模塊(22)根據設定的流媒體分段時間合并所述流媒體分塊為流媒體分段并生成對應流媒體數據分段文件順序和儲存位置的索引,分別儲存至服務器儲存模塊(23);所述播放客戶端(3)包括交付模塊(31)、播放客戶端流媒體處理模塊(32)、播放客戶端音頻編碼模塊(33)、播放客戶端視頻編碼模塊(34)和播放模塊(35);所述交付模塊(31)與所述服務器端(2)交互并根據索引從服務器端(2)下載流媒體分段文件,播放客戶端流媒體處理模塊(32)對流媒體進行分解獲取音頻流和/或視頻流,播放客戶端流媒體處理模塊(32)調用播放客戶端音頻編碼模塊(33)和/或播放客戶端視頻編碼模塊(34)對音頻流和/或視頻流所述進行解碼并通過播放模塊(35)進行播放。2.?根據權利要求1所述的在互聯網發布和直播流媒體的系統,其特征在于:還包括媒體采集端(4),所述媒體采集端(4)包括媒體采集模塊(41)、媒體處理模塊(42)、采集端音頻編碼模塊(43)和/或采集端視頻編碼模塊(44),所述的媒體處理模塊(42)調用所述的采集端音頻編碼模塊(43)和/或采集端視頻編碼模塊(44)生成特定格式的媒體文件。3.?根據權利要求2所述的在互聯網發布和直播流媒體的系統,其特征在于:所述的采集端(4)集成于所述的發布客戶端(1)中。4.?根據權利要求1至3任意一項所述的在互聯網發布和直播流媒體的系統,其特征在于:所述的服務器儲存模塊(23)為分布式存儲系統。...

    【技術特征摘要】
    1.一種在互聯網發布和直播流媒體的系統,包括服務器端(2)和播放客戶端(3),其特征在于 還包括發布客戶端(1)包括媒體輸入模塊(11)、發布客戶端音頻編碼模塊(12)、發布客戶端視頻編碼模塊(13)、發布客戶端流媒體處理模塊(14)和發布模塊(15);所述媒體輸入模塊(11)讀取音頻流和/或視頻流數據并把該音頻流和/或視頻流數據傳輸至所述發布客戶端流媒體處理模塊(14);所述發布客戶端流媒體處理模塊(14)調用發布客戶端音頻編碼模塊(12)和/或發布客戶端視頻編碼模塊(13)對音頻流和/或視頻流數據重新編碼并根據設定的格式進行媒體流的合并,并按預設的流媒體數據分塊時間生成流媒體數據分塊; 所述服務器端(2 )包括網頁服務模塊(21)、服務器流媒體處理模塊(22 )和服務器儲存模塊(23);發布客戶端(1)發布模塊(15)與網頁服務模塊(21)交互并上傳所述流媒體分塊,服務器流媒體處理模塊(22)根據設定的流媒體分段時間合并所述流媒體分塊為流媒體分段并生成對應流媒體數據分段文件順序和儲存位置的索引,分別儲存至服務器儲存模塊(23); 所述播放客戶端(3)包括交付模塊(31)、播放客戶端流媒體處...

    【專利技術屬性】
    技術研發人員:樊志巖李洋
    申請(專利權)人:北京對角巷科技發展有限公司
    類型:實用新型
    國別省市:

    網友詢問留言 已有0條評論
    • 還沒有人留言評論。發表了對其他瀏覽者有用的留言會獲得科技券。

    1
    主站蜘蛛池模板: 五月丁香六月综合缴清无码| 毛片一区二区三区无码| 久久精品无码专区免费 | 无码 免费 国产在线观看91 | 亚洲一区无码精品色| 色噜噜综合亚洲av中文无码 | 成在人线AV无码免费| 无码精品人妻一区二区三区人妻斩 | 免费VA在线观看无码| 日韩精品人妻系列无码专区 | 国产午夜无码视频免费网站| 无码人妻精品中文字幕| 亚洲AV无码乱码精品国产| 亚洲国产av高清无码| 亚洲精品无码高潮喷水在线| 亚欧无码精品无码有性视频| 亚洲av中文无码乱人伦在线观看| 午夜不卡久久精品无码免费| 久久久人妻精品无码一区| 好了av第四综合无码久久| 日韩精品无码熟人妻视频 | 日韩精品无码一本二本三本| 亚洲成AV人在线播放无码| 精品人体无码一区二区三区| 久久久g0g0午夜无码精品 | 亚洲人成国产精品无码| 国产精品无码亚洲一区二区三区 | 精品无码国产自产拍在线观看 | 无码人妻丰满熟妇区免费| 日韩AV高清无码| 中文字幕无码AV波多野吉衣| 午夜无码中文字幕在线播放| 日韩激情无码免费毛片| 国产精品白浆无码流出| 激情无码人妻又粗又大| 免费无码一区二区三区蜜桃 | 无码毛片一区二区三区中文字幕| 18禁超污无遮挡无码免费网站国产 | 台湾无码AV一区二区三区| 中文字幕无码无码专区| 无码人妻精品一区二区三区夜夜嗨|