當(dāng)前位置:首頁 > 芯聞號 > 充電吧
[導(dǎo)讀]互聯(lián)網(wǎng)上的兩種主要的分發(fā)方式:HLS和RTMP,什么時候用誰,完全決定于應(yīng)用場景。還有其他的分發(fā)方式,這些分發(fā)方式不屬于互聯(lián)網(wǎng)常見和通用的方式,不予以比較:UDP:譬如YY的實(shí)時應(yīng)用,視頻會議等等,或

互聯(lián)網(wǎng)上的兩種主要的分發(fā)方式:HLS和RTMP,什么時候用誰,完全決定于應(yīng)用場景。

還有其他的分發(fā)方式,這些分發(fā)方式不屬于互聯(lián)網(wǎng)常見和通用的方式,不予以比較:

UDP:譬如YY的實(shí)時應(yīng)用,視頻會議等等,或者RTSP之類。這類應(yīng)用的特點(diǎn)就是實(shí)時性要求特別高,以毫秒計算。TCP家族協(xié)議根本就滿足不了要求,所以HTTP/TCP都不靠譜。這類應(yīng)用沒有通用的方案,必須自己實(shí)現(xiàn)分發(fā)(服務(wù)端)和播放(客戶端)。P2P:譬如RTMFP或者各家自己的協(xié)議。這類應(yīng)用的特點(diǎn)是節(jié)省帶寬。目前PC/flash上的RTMFP比較成熟,Android上的P2P屬于起步群雄紛爭標(biāo)準(zhǔn)不一,IOS上P2P應(yīng)該沒有聽說過。RTSP:這種不是互聯(lián)網(wǎng)上的主要應(yīng)用,在其他領(lǐng)域譬如安防等有廣泛應(yīng)用。

另外,HTTP的也分為幾種:

HTTP progressive:早期流媒體服務(wù)器分發(fā)http文件時,以普通的http文件分發(fā),這種叫做漸進(jìn)式下載,意思就是如果文件很大譬如1小時時長1GB大小,想從中間開始播放是不行的。但這種方式已經(jīng)是作古了,很多http服務(wù)器支持http文件的seek,就是從中間開始播放。HTTP stream:支持seek的HTTP流,譬如各家視頻網(wǎng)站的點(diǎn)播分發(fā)方式。或者稍微復(fù)雜點(diǎn)的,譬如把一個大文件切幾段之后分發(fā)。目前在pc/flash上點(diǎn)播國內(nèi)的主流分發(fā)是這種方式。HLS:這種是現(xiàn)在適配方式最廣(除了flash, 需要額外的as庫支持),在PC上有vlc,Android/IOS原生播放器就支持播放HLS,HTML5里面的url可以寫HLS地址??傊?,在移動端是以HLS為主。HDS:adobe自己的HLS,一坨屎。DASH:各家提出的HLS,目前還沒有廣泛應(yīng)用。

對比以下互聯(lián)網(wǎng)上用的流媒體分發(fā)方式:

HLS:apple的HLS,支持點(diǎn)播和直播。HTTP:即HTTP stream,各家自己定義的http流,應(yīng)用于國內(nèi)點(diǎn)播視頻網(wǎng)站。RTMP:直播應(yīng)用,對實(shí)時性有一定要求,以PC為主。 RTMP

RTMP本質(zhì)上是流協(xié)議,主要的優(yōu)勢是:

實(shí)時性高:RTMP的實(shí)時性在3秒之內(nèi),經(jīng)過多層CDN節(jié)點(diǎn)分發(fā)后,實(shí)時性也在3秒左右。在一些實(shí)時性有要求的應(yīng)用中以RTMP為主。支持加密:RTMPE和RTMPS為加密協(xié)議。雖然HLS也有加密,但在PC平臺上flash對RTMPE/RTMPS支持應(yīng)該比較不錯。穩(wěn)定性高:在PC平臺上flash播放的最穩(wěn)定方式是RTMP,如果做CDN或者大中型集群分發(fā),選擇穩(wěn)定性高的協(xié)議一定是必要的。HTTP也很穩(wěn)定,但HTTP是在協(xié)議上穩(wěn)定;穩(wěn)定性不只是服務(wù)端的事情,在集群分發(fā),服務(wù)器管理,主備切換,客戶端的支持上,RTMP在PC分發(fā)這種方式上還是很有優(yōu)勢。編碼器接入:編碼器輸出到互聯(lián)網(wǎng)(還可以輸出為udp組播之類廣電應(yīng)用),主要是RTMP。譬如專業(yè)編碼器,或者flash網(wǎng)頁編碼器,或者FMLE,或者ffmpeg,或者安防攝像頭,都支持RTMP輸出。若需要接入多種設(shè)備,譬如提供云服務(wù);或者希望網(wǎng)頁直接采集攝像頭;或者能在不同編碼器之間切換,那么RTMP作為服務(wù)器的輸入?yún)f(xié)議會是最好的選擇。系統(tǒng)容錯:容錯有很多種級別,RTMP的集群實(shí)現(xiàn)時可以指定N上層,在錯誤時切換不會影響到下層或者客戶端,另外RTMP的流沒有標(biāo)識,切到其他的服務(wù)器的流也可以繼續(xù)播放。HLS的流熱備切換沒有這么容易。若對于直播的容錯要求高,譬如降低出問題的概率,選擇RTMP會是很好的選擇。可監(jiān)控:在監(jiān)控系統(tǒng)或者運(yùn)維系統(tǒng)的角度看,流協(xié)議應(yīng)該比較合適監(jiān)控。HTTP的流監(jiān)控感覺沒有那么完善。這個不算絕對優(yōu)勢,但比較有利。

RTMP的劣勢是:

協(xié)議復(fù)雜:RTMP協(xié)議比起HTTP復(fù)雜很多,導(dǎo)致性能低下。測試發(fā)現(xiàn)兩臺服務(wù)器直連100Gbps網(wǎng)絡(luò)中,HTTP能跑到60Gbps,但是RTMP只能跑到10Gbps,CPU占用率RTMP要高很多。復(fù)雜協(xié)議導(dǎo)致在研發(fā),擴(kuò)展,維護(hù)軟件系統(tǒng)時都沒有HTTP那么方便,所以HTTP服務(wù)器現(xiàn)在大行其道,apache/nginx/tomcat,N多HTTP服務(wù)器;而RTMP協(xié)議雖然早就公開,但是真正在大規(guī)模中分發(fā)表現(xiàn)良好的沒有,adobe自己的FMS在CDN中都經(jīng)常出問題。Cache麻煩:流協(xié)議做緩存不方便。譬如點(diǎn)播,若做RTMP流協(xié)議,邊緣緩存RTMP會很麻煩。如果是HTTP,緩存其實(shí)也很麻煩,但是HTTP服務(wù)器的緩存已經(jīng)做了很久,所以只需要使用就好。這是為何點(diǎn)播都走HTTP的原因。 HTTP

HTTP說的是HTTP流,譬如各大視頻網(wǎng)站的點(diǎn)播流。

HTTP本質(zhì)上還是文件分發(fā),主要的優(yōu)勢是:

性能很高:HTTP的性能沒得說,協(xié)議簡單,各種HTTP高性能服務(wù)器也完善。如果分發(fā)的量特別大,譬如點(diǎn)播視頻網(wǎng)站,沒有直播的實(shí)時性要求,HTTP協(xié)議是最好選擇。沒有碎片:HTTP比HLS沒有碎片,HTTP分發(fā)大文件會比小文件分發(fā)方便很多。特別是存儲,小文件的性能超低,是個硬傷。穿墻:互聯(lián)網(wǎng)不可能不開放HTTP協(xié)議,否則就不叫互聯(lián)網(wǎng)。所以任何端口封掉,也不會導(dǎo)致HTTP流看不了。(不過RTMP也能穿墻,用RTMPT協(xié)議)。

HTTP的劣勢是:

實(shí)時性差:基本上沒有實(shí)時性這個說法。原生支持不好:就PC上flash對于HTTP流支持還可以,Android/IOS上似乎只能mp4,總之移動端對于HTTP的支持不是很完善。 HLS

HLS是Apple的開放標(biāo)準(zhǔn),在Android3?以上也原生支持.

HLS的主要優(yōu)勢是:

性能高:和HTTP一樣。穿墻:和HTTP一樣。原生支持很好:IOS上支持完美。Android上支持差些。PC/flash上現(xiàn)在也有各種as插件支持HLS。

HLS的主要劣勢是:

實(shí)時性差:基本上HLS的延遲在10秒以上。文件碎片:若分發(fā)HLS,碼流低,切片較小時,小文件分發(fā)不是很友好。特別是一些對存儲比較敏感的情況,譬如源站的存儲,嵌入式的SD卡。 應(yīng)用方式

參考HTTP和RTMP

推薦的方式是:

編碼器輸出RTMP協(xié)議。流媒體系統(tǒng)接入使用RTMP協(xié)議。流媒體系統(tǒng)內(nèi)部直播分發(fā)使用RTMP。PC+直播+實(shí)時性要求高:使用flash播放RTMP。PC+直播+沒有實(shí)時性要求:使用RTMP或者HLS均可。PC+點(diǎn)播:使用HTTP或者HLS。Apple IOS/OSX:都使用HLS(實(shí)時性要求高得自己解析RTMP,或者使用外部庫,譬如https://www.vitamio.org)


Andorid:和IOS一樣,不過可以確定的是可以自己開發(fā)支持RTMP。
原文鏈接:https://github.com/ossrs/srs/wiki/v1_CN_RTMP.PK.HTTP


本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫?dú)角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運(yùn)行,同時企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險,如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機(jī) 衛(wèi)星通信

要點(diǎn): 有效應(yīng)對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實(shí)提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅持高質(zhì)量發(fā)展策略,塑強(qiáng)核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運(yùn)營商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術(shù)學(xué)會聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(shù)(集團(tuán))股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉