H5直播系列四 RTMP HTTP-FLV HLS MPEG-DASH

參考
【騰訊Bugly干貨分享】從0到1打造直播 App
從入門到出家：流媒體協(xié)議—FLV
H5直播起航
全面進(jìn)階 H5 直播
HTML5 視頻直播（一）HLS 和 RTMP
HTML5 視頻直播（二）Web Sockets+Canvas
HTML5 視頻直播（三）WebRTC
直播服務(wù)器簡(jiǎn)單實(shí)現(xiàn) http_flv和hls 內(nèi)網(wǎng)直播桌面
RTMP、RTSP、HTTP視頻協(xié)議詳解（附：直播流地址、播放軟件）
帶你吃透RTMP
[總結(jié)]RTMP流媒體技術(shù)零基礎(chǔ)學(xué)習(xí)方法
直播云解決方案整理
直播未來(lái)屬于RTMP還是HTTP？

Paste_Image.png

一、HLS

HLS （HTTP Live Streaming）, 是由 Apple 公司實(shí)現(xiàn)的基于 HTTP 的媒體流傳輸協(xié)議。Apple 的全系列產(chǎn)品支持，由于 HLS 是蘋果提出的， 所以在 Apple 的全系列產(chǎn)品包括 iphone、 ipad、safari 都不需要安裝任何插件就可以原生支持播放 HLS， 現(xiàn)在Android 也加入了對(duì) HLS 的支持。但PC端目前除了Microsoft Edge外，Chrome、Firefox等瀏覽器均不支持該協(xié)議的播放。可直接采用網(wǎng)上一些比較成熟的方案，如：sewise-player、MediaElement、videojs-contrib-hls、jwplayer。

對(duì)于支持 HLS 的瀏覽器來(lái)說(shuō)，直接這樣寫就能播放了：

<video controls autoplay>  
    <source src="http://live.hkstv.hk.lxdns.com/live/hks/playlist.m3u8"
 type="application/vnd.apple.mpegurl" />  
    <p class="warning">Your browser does not support HTML5 video.</p>  
</video>

以上測(cè)試地址參考 m3u8直播測(cè)試地址，或者APPLE提供測(cè)試地址

HLS 的基本原理就是當(dāng)采集推流端將視頻流推送到流媒體服務(wù)器時(shí)，服務(wù)器將收到的流信息每緩存一段時(shí)間就封包成一個(gè)新的 ts 文件，同時(shí)服務(wù)器會(huì)建立一個(gè) m3u8 的索引文件來(lái)維護(hù)最新幾個(gè) ts 片段的索引。當(dāng)播放端獲取直播時(shí)，它是從 m3u8 索引文件獲取最新的 ts 視頻文件片段來(lái)播放，從而保證用戶在任何時(shí)候連接進(jìn)來(lái)時(shí)都會(huì)看到較新的內(nèi)容，實(shí)現(xiàn)近似直播的體驗(yàn)。相對(duì)于常見(jiàn)的流媒體直播協(xié)議，例如 RTMP 協(xié)議、RTSP 協(xié)議等，HLS 最大的不同在于直播客戶端獲取到的并不是一個(gè)完整的數(shù)據(jù)流，而是連續(xù)的、短時(shí)長(zhǎng)的媒體文件，客戶端不斷的下載并播放這些小文件。這種方式的理論最小延時(shí)為一個(gè) ts 文件的時(shí)長(zhǎng)，一般情況為 2-3 個(gè) ts 文件的時(shí)長(zhǎng)。HLS 的分段策略，基本上推薦是 10 秒一個(gè)分片，這就看出了 HLS 的缺點(diǎn)：

  • 通常 HLS 直播延時(shí)會(huì)達(dá)到 20-30s，而高延時(shí)對(duì)于需要實(shí)時(shí)互動(dòng)體驗(yàn)的直播來(lái)說(shuō)是不可接受的。
  • HLS 基于短連接 HTTP，HTTP 是基于 TCP 的，這就意味著 HLS 需要不斷地與服務(wù)器建立連接，TCP 每次建立連接時(shí)的三次握手、慢啟動(dòng)過(guò)程、斷開連接時(shí)的四次揮手都會(huì)產(chǎn)生消耗。

不過(guò) HLS 也有它的優(yōu)點(diǎn)：

  • 數(shù)據(jù)通過(guò) HTTP 協(xié)議傳輸，所以采用 HLS 時(shí)不用考慮防火墻或者代理的問(wèn)題。
  • 使用短時(shí)長(zhǎng)的分片文件來(lái)播放，客戶端可以平滑的切換碼率，以適應(yīng)不同帶寬條件下的播放。
  • HLS 是蘋果推出的流媒體協(xié)議，在 iOS 平臺(tái)上可以獲得天然的支持，采用系統(tǒng)提供的 AVPlayer 就能直接播放，不用自己開發(fā)播放器。
  • HLS有一個(gè)非常大的優(yōu)點(diǎn)：HTML5可以直接打開播放；這個(gè)意味著可以把一個(gè)直播鏈接通過(guò)微信等轉(zhuǎn)發(fā)分享，不需要安裝任何獨(dú)立的APP，有瀏覽器即可，所以流行度很高。社交直播APP，HLS可以說(shuō)是剛需

以下參考直播協(xié)議 HTTP-FLV 詳解
這里首先要說(shuō)一下，HLS其實(shí)是一個(gè)“文本協(xié)議”，而并不是一個(gè)流媒體協(xié)議。那么，什么樣的協(xié)議才能稱之為流媒體協(xié)議呢？
流（stream）： 數(shù)據(jù)在網(wǎng)絡(luò)上按時(shí)間先后次序傳輸和播放的連續(xù)音/視頻數(shù)據(jù)流。之所以可以按照順序傳輸和播放連續(xù)是因?yàn)樵陬愃?RTMP，F(xiàn)LV協(xié)議中， 每一個(gè)音視頻數(shù)據(jù)都被封裝成了包含時(shí)間戳信息頭的數(shù)據(jù)包。而當(dāng)播放器拿到這些數(shù)據(jù)包解包的時(shí)候能夠根據(jù)時(shí)間戳信息把這些音視頻數(shù)據(jù)和之前到達(dá)的音視頻數(shù)據(jù)連續(xù)起來(lái)播放。MP4，MKV等等類似這種封裝，必須拿到完整的音視頻文件才能播放，因?yàn)槔锩娴膯蝹€(gè)音視頻數(shù)據(jù)塊不帶有時(shí)間戳信息，播放器不能將這些沒(méi)有時(shí)間戳信息數(shù)據(jù)塊連續(xù)起來(lái)，所以就不能實(shí)時(shí)的解碼播放。

二、MPEG DASH(Dynamic Adaptive Streaming over HTTP)

參考
MPEG-DASH 流媒體技術(shù)介紹（上）
MPEG-DASH 流媒體技術(shù)介紹（中）
MPEG-DASH 流媒體技術(shù)介紹（下）
MPEG DASH 和 HLS

1.在基于HTTP提供流媒體的方面，到目前為止已經(jīng)看到了三種方案，蘋果的HLS，Adobe HTTP Dynamic Streaming (HDS)和Microsoft Smooth Streaming (MSS)，當(dāng)然，各家用的協(xié)議，格式神馬的都不會(huì)一樣。于是每次做支持都要來(lái)三人份的?？吹竭@三倍工作量，再想想老板不給加工資，碼農(nóng)們的心都寒了...MPEG的同志們體察到了這份疾苦，呼吁大家來(lái)個(gè)標(biāo)準(zhǔn)點(diǎn)的玩意唄，于是就有了MPEG DASH 。這里有一篇綜述，寫的比我好還圖文并茂的，去那看吧～

2.B站在2018.8.2發(fā)布的我們?yōu)槭裁词褂肈ASH中提到以后點(diǎn)播會(huì)使用DASH方案，直播因?yàn)檠舆t問(wèn)題仍然使用FLV(評(píng)論回復(fù)中有提到)

文中有提到B站二壓，這個(gè)可以參考【教程向】教你怎樣壓制出“B站直傳“的清晰視頻

DASH，又叫MPEG DASH，DASH：Dynamic Adaptive Streaming over HTTP ，是一種在互聯(lián)網(wǎng)上傳送動(dòng)態(tài)碼率的Video Streaming技術(shù)，類似于蘋果的HLS，DASH會(huì)通過(guò)media presentation description (MPD)將視頻內(nèi)容切片成一個(gè)很短的文件片段，每個(gè)切片都有多個(gè)不同的碼率，DASH Client可以根據(jù)網(wǎng)絡(luò)的情況選擇一個(gè)碼率進(jìn)行播放，支持在不同碼率之間無(wú)縫切換。YouTube采用DASH。其網(wǎng)頁(yè)端及移動(dòng)端APP都使用了DASH。DASH的其他采用者包括：Netflix, Hulu。

DASH是由MPEG (Moving Picture Experts Group)組織制定，2010年開始啟動(dòng)，2011年11月發(fā)布Draft版本，2012年4月發(fā)布第一稿Version（ISO/IEC 23009-1:2012），2014年5月發(fā)布第二稿（ISO/IEC 23009-1:2014），最新稿（ISO/IEC 23009-3:2015）。

目前3GPP?Release 10已經(jīng)將DASH納入其中；在HbbTV 1.5中也支持DASH；DVB-DASH也將DASH納入到DVB（ETSI TS 103 285 v.1.1.1）。目前DASH Industry Forum由發(fā)起廠家組成，致力于推進(jìn)DASH產(chǎn)品生態(tài)，將DASH產(chǎn)業(yè)化和業(yè)界最佳實(shí)踐推向批量應(yīng)用。

15年的B站我們使用整段的FLV和MP4，這種方案的好處是簡(jiǎn)單且兼容性高，抖音與今日頭條就是用該方案。但缺點(diǎn)也很明顯，隨著視頻時(shí)長(zhǎng)的增長(zhǎng)，整段的MP4的頭部過(guò)于復(fù)雜，體積過(guò)于龐大，導(dǎo)致拉取與加載極為緩慢。

16年的B站為了規(guī)避這個(gè)問(wèn)題，使用了分段的FLV來(lái)提升加載速度，這種方案的好處是視頻頭部小，加載速度高。愛(ài)奇藝和優(yōu)酷也使用類似方案。這種方案簡(jiǎn)單且兼容性高，而且與直播流統(tǒng)一了格式，所以一直沿用至今，中間由于flv.js的出現(xiàn) ，把這種方案帶向了全平臺(tái)。

但隨著用戶的增加，用戶的網(wǎng)絡(luò)種類和情況也變得更加復(fù)雜，如果我們需要在各種場(chǎng)景下都需要給用戶較好的體驗(yàn)，我們需要選擇一種能在不同網(wǎng)絡(luò)下都能流暢播放的方案。我們需要引入Dynamic Adaptive Streaming/ Bitrate 技術(shù)，以進(jìn)一步提升用戶體驗(yàn)。我們也需要對(duì)多音軌和多視頻軌

在評(píng)估了一些行業(yè)內(nèi)使用的方案后，我們選中了DASH，DASH也可以更靈活的實(shí)現(xiàn)用戶與產(chǎn)品的新增需求。


image.png

image.png

對(duì)于普通看視頻的用戶，我們期待部署Dash有以下改進(jìn)：

  • 觀看視頻更為流暢，如下圖所示，我們會(huì)在網(wǎng)速不佳時(shí)無(wú)縫切換至較低清晰度視頻，在網(wǎng)速充足時(shí)無(wú)縫切換至高清晰度視頻，切換過(guò)程對(duì)于用戶無(wú)感。
  • 可以很容易的支持音頻模式，滿足聽相聲/音樂(lè)的你
  • 在退到后臺(tái)后，可以自動(dòng)切換至只拉取音頻，更節(jié)省你的流量，播放更加流暢。(恢復(fù)回來(lái)可能黑屏，所以上傳視頻時(shí)，會(huì)做GOP對(duì)齊，并嘗試將GOP縮減到5s)
  • 可以很容易的支持視頻新增多音軌，多視頻軌，多字幕軌的任意切換 ，原聲，中配，多版本字幕任君選擇。

3.兼容性
參考
新時(shí)代的點(diǎn)播與直播
wikipedia DASH
Why YouTube & Netflix use MPEG-DASH in HTML5

MSE(Media Source Extensions)是目前Youtube使用的DASH的基礎(chǔ)。

image.png

dash.js是Dash行業(yè)論壇官方參考和生產(chǎn)播放器。
shaka-player是出自Google的開源dash播放器。

三、RTMP

RTMP協(xié)議是Real Time Message Protocol(實(shí)時(shí)信息傳輸協(xié)議)的縮寫，它是由Adobe公司提出的一種應(yīng)用層的協(xié)議，用來(lái)解決多媒體數(shù)據(jù)傳輸流的多路復(fù)用（Multiplexing）和分包（packetizing）的問(wèn)題。

使用RTMP技術(shù)的流媒體系統(tǒng)有一個(gè)非常明顯的特點(diǎn)：使用 Flash Player 作為播放器客戶端，而Flash Player 現(xiàn)在已經(jīng)安裝在了全世界將近99%的PC上，因此一般情況下收看RTMP流媒體系統(tǒng)的視音頻是不需要安裝插件的。用戶只需要打開網(wǎng)頁(yè)，就可以直接收看流媒體，十分方便。

相對(duì)于 HLS 來(lái)說(shuō)，采用 RTMP 協(xié)議時(shí)，從采集推流端到流媒體服務(wù)器再到播放端是一條數(shù)據(jù)流，因此在服務(wù)器不會(huì)有落地文件。這樣 RTMP 相對(duì)來(lái)說(shuō)就有這些優(yōu)點(diǎn)：

  • 延時(shí)較小，通常為 1-3s。
  • 基于 TCP 長(zhǎng)連接，不需要多次建連。

因此業(yè)界大部分直播業(yè)務(wù)都會(huì)選擇用 RTMP 作為流媒體協(xié)議。通常會(huì)將數(shù)據(jù)流封裝成 FLV 通過(guò) HTTP 提供出去。但是這樣也有一些問(wèn)題需要解決：

Paste_Image.png
       public function simplest_as3_rtmp_player()
        {
            nc = new NetConnection();
            nc.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);
            nc.connect("rtmp://localhost/live");
        }
        private function netStatusHandler(event:NetStatusEvent):void
        {
          trace("event.info.level: " + event.info.level + "\n", 
          "event.info.code: " + event.info.code);
            switch (event.info.code)
            {
                case "NetConnection.Connect.Success":
                    doVideo(nc);
                    break;
                case "NetConnection.Connect.Failed":
                    break;
                case "NetConnection.Connect.Rejected":
                    break;
                case "NetStream.Play.Stop":
                    break;
                case "NetStream.Play.StreamNotFound":
                    break;
            }
        }
        // play a recorded stream on the server
        private function doVideo(nc:NetConnection):void {
            ns = new NetStream(nc);
            ns.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);

            video = new Video(640,480);
            video.attachNetStream(ns);

            ns.play("myCamera");
            addChild(video);
        }
四、HTTP-FLV協(xié)議：

即使用HTTP協(xié)議流式的傳輸媒體內(nèi)容。相對(duì)于RTMP，HTTP更簡(jiǎn)單和廣為人知，而且不擔(dān)心被Adobe的專利綁架。內(nèi)容延遲同樣可以做到2~5秒，打開速度更快，因?yàn)镠TTP本身沒(méi)有復(fù)雜的狀態(tài)交互。所以從延遲角度來(lái)看，HTTP-FLV要優(yōu)于RTMP。

http_flv&rtmp這兩個(gè)協(xié)議實(shí)際上傳輸數(shù)據(jù)是一樣的，數(shù)據(jù)都是flv文件的tag。http_flv是一個(gè)無(wú)限大的http流的文件，相比rtmp就只能直播，而rtmp還可以推流和更多的操作。但是http有個(gè)好處，就是是以80http通信的，穿透性強(qiáng)，而且rtmp是非開放協(xié)議。這兩個(gè)協(xié)議是如今直播平臺(tái)主選的直播方式，主要原因就是延時(shí)極低。

以下參考直播http-flv小調(diào)研
HTTP協(xié)議中有個(gè)約定：content-length字段，http的body部分的長(zhǎng)度
服務(wù)器回復(fù)http請(qǐng)求的時(shí)候如果有這個(gè)字段，客戶端就接收這個(gè)長(zhǎng)度的數(shù)據(jù)然后就認(rèn)為數(shù)據(jù)傳輸完成了，如果服務(wù)器回復(fù)http請(qǐng)求中沒(méi)有這個(gè)字段，客戶端就一直接收數(shù)據(jù)，直到服務(wù)器跟客戶端的socket連接斷開。

http-flv直播就是利用第二個(gè)原理，服務(wù)器回復(fù)客戶端請(qǐng)求的時(shí)候不加content-length字段，在回復(fù)了http內(nèi)容之后，緊接著發(fā)送flv數(shù)據(jù)，客戶端就一直接收數(shù)據(jù)了。

五、其它

1.直播整體流程大致可分為：

  • 視頻采集端：可以是電腦上的音視頻輸入設(shè)備、或手機(jī)端的攝像頭、或麥克風(fēng)，目前以移動(dòng)端手機(jī)視頻為主。
  • 直播流視頻服務(wù)端：一臺(tái)Nginx服務(wù)器，采集視頻錄制端傳輸?shù)囊曨l流(H264/ACC編碼)，由服務(wù)器端進(jìn)行解析編碼，推送RTMP/HLS格式視頻流至視頻播放端。
  • 視頻播放端：可以是電腦上的播放器（QuickTime Player、VLC），手機(jī)端的native播放器，還有就是 H5 的video標(biāo)簽等，目前還是以手機(jī)端的native播放器為主。

2.以下參考基于rtmp協(xié)議等的流媒體服務(wù)器是否可以被取代
flash已經(jīng)死了，但是在手機(jī)平臺(tái)上還是有很多人用C++來(lái)解析rtmp協(xié)議做直播流。因?yàn)閷?duì)比其他直播流協(xié)議，rtmp的實(shí)時(shí)延遲可以做到1秒以內(nèi)。hls的延遲基本有10秒左右。幾年前，我做過(guò)一個(gè)菲律賓賭場(chǎng)的直播APP，賭場(chǎng)的荷官發(fā)牌，然后客戶端同時(shí)顯示開牌信息，如果不同步或者超過(guò)1秒內(nèi)的延遲，會(huì)給用戶一種作弊的感覺(jué)。使用rtmp，就算在美國(guó)看這個(gè)直播，延遲也是在1秒以內(nèi)。找了很多視頻直播協(xié)議，實(shí)時(shí)性最好就是rtmp，暫時(shí)找不到能代替rtmp的協(xié)議。
3.以下參考前主流視頻網(wǎng)站視頻點(diǎn)播都是使用的哪些協(xié)議
幾乎所有主流直播平臺(tái)網(wǎng)站幾乎都是主線路為cdn提供的httpflv，其他線路大部分都是rtmp。上面有人說(shuō)httpflv的延遲比rtmp高一點(diǎn)，那是瞎扯，httpflv理論延時(shí)至少是與rtmp差不多的。至于HLS，我以前倒是在web上見(jiàn)到過(guò)，只不過(guò)現(xiàn)在沒(méi)見(jiàn)到了，幾乎都是rtmp+httpflv。至于hls相對(duì)rtmp及httpflv的優(yōu)點(diǎn)，我想僅僅是能夠html5播放，僅此而已，hls本身有很多不好的設(shè)計(jì)，比如ts文件，ts文件是不停的在http請(qǐng)求，這就相當(dāng)于http和長(zhǎng)連接的區(qū)別，不僅帶來(lái)服務(wù)器的資源消耗，還有http報(bào)文頭一堆冗余信息。這對(duì)流媒體直播那金貴流量費(fèi)來(lái)說(shuō)，這不不是一個(gè)好選擇。hls還有個(gè)致命的問(wèn)題，那就是延時(shí)，本身就是分文件塊傳輸?shù)模訒r(shí)自然比rtmp高出許多。如果將hls的ts文件縮小，或許稍許降低延時(shí)。但hsl真的不是面向大眾直播的第一選擇。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容