需求比協(xié)議重要，理解你的需求在前，選擇應(yīng)用的協(xié)議在后！

第一、是什么？

解釋這個(gè)問題有很大的難度，你所處的角度不同，決定了所需答案的不同。不管怎么樣，協(xié)議是為了解決問題而生的，它有著天然的指向性。同時(shí)，也有著它自身的局限。這三個(gè)協(xié)議的背后，有著一段凄美的愛情故事。我說說，你聽聽，在想當(dāng)初….

千禧年的鐘聲敲響了，人們邁進(jìn)了一個(gè)新的世紀(jì)。當(dāng)時(shí)的移動(dòng)和聯(lián)通還不能互發(fā)信息，手機(jī)是什么樣咱們心里也多少有點(diǎn)兒數(shù)。就在這樣的環(huán)境里，就在這樣一個(gè)網(wǎng)絡(luò)生存條件下，一小撮內(nèi)心躁動(dòng)的人開始不安了！它就是Macromedia。

Macromedia

對(duì)，就是它。不知道沒關(guān)系，這個(gè)公司就活到2005年。這是一個(gè)短命的公司，但它拿出了一個(gè)長(zhǎng)命協(xié)議，影響了之后的網(wǎng)上生活，也為全民直播奠定了基礎(chǔ)。這就是RTMP，一個(gè)實(shí)時(shí)消息傳輸協(xié)議，一個(gè)讓在線看片成為可能得協(xié)議，一個(gè)讓東京.熱了的協(xié)議….

就這樣，一個(gè)新的時(shí)代開始了！

當(dāng)時(shí)間撥到了2012年， Adobe 正式發(fā)布 RTMP specification v1.0 的時(shí)候。本以為拿著媒體服務(wù)的金鑰匙，可以在未來世界縱橫馳騁。但Adobe錯(cuò)了，未來已來，但那是一個(gè)Html5的世界，一個(gè)不需要Flash的世界。

在這種大背景下，RTMP被替換是遲早的，不是它不帥，只是這個(gè)世界變化快！

HttpFlv的出現(xiàn)最早是2008年，從它的協(xié)議本身我們能看到Adobe的影子，就是flv協(xié)議本身。也可以說，httpflv是爭(zhēng)奪與放棄之間妥協(xié)的產(chǎn)物。人們?cè)僖膊辉敢饪吹紸dobe，但又不得不面對(duì)海量Flv歷史文檔。在仇恨與無奈的交織中，httpflv誕生了。

HttpFlv 就是 http+flv ，將音視頻數(shù)據(jù)封裝成FLV格式，然后通過 HTTP 協(xié)議傳輸給客戶端。理解HttpFlv協(xié)議，這就話就是關(guān)鍵。

但聰明地你馬上就會(huì)發(fā)現(xiàn)，雖然傳輸協(xié)議變了，但在flv數(shù)據(jù)格式下，脫離FlashPlayer還是無稽之談。但在2016年，這一切都發(fā)生了改變，因?yàn)閒lv.js問世了！

Bilibili，也就是傳說中的B站，不僅貢獻(xiàn)了彈幕，為我們提供了另一種觀影交互體驗(yàn)。更重要的，Flv.js的誕生，讓我們?cè)谝曨l播放領(lǐng)域徹底告別Adobe時(shí)代。一個(gè)全新、干凈的HTML5就這樣向我們走來了。

關(guān)于HLS

現(xiàn)實(shí)世界就是這么殘酷，伴隨協(xié)議更迭的，是一個(gè)巨頭倒下，另一個(gè)巨頭崛起的故事。談HLS 就不得不談蘋果，談蘋果就不得不提喬幫主。

我總是不想刻意拔高一個(gè)人，但這逼 …. 哎，不說了。就記住吧，悲劇的開端，往往是榮耀的起點(diǎn)。是悲劇還是榮耀，只取決于你！

好，返回頭繼續(xù)說HLS，HLS就是“HTTP Live Streaming”的縮寫，它誕生自2009年，QuickTime和iPhone3GS黃金搭檔下的一個(gè)標(biāo)準(zhǔn)，一個(gè)意在顛覆流媒體產(chǎn)業(yè)的新協(xié)議。

它的工作原理簡(jiǎn)單來說就是把一段視頻流，分成一個(gè)個(gè)小的基于HTTP的文件來下載。當(dāng)媒體流正在播放時(shí)，客戶端可以根據(jù)當(dāng)前網(wǎng)絡(luò)環(huán)境，方便地在不同的碼率流中做切換，以實(shí)現(xiàn)更好的觀影體驗(yàn)。

HLS的出現(xiàn)是為了解決蘋果原生環(huán)境中的流媒體播放，這個(gè)協(xié)議可以方便地讓Mac和iPhone播放視頻流，不依賴Adobe，更不用去管什么標(biāo)準(zhǔn)委員會(huì)。依賴自己，永遠(yuǎn)是最大力量的保障。

RFC 8216

但幸運(yùn)之神就是這么奇怪，當(dāng)它給你打開一扇門的時(shí)候，也在不經(jīng)意間給你關(guān)上了一個(gè)。就蘋果來說，HLS經(jīng)過10年的發(fā)展，RFC 8216發(fā)布了HLS的第七個(gè)版本。Adobe早已是昨日黃花，未來已來，這是一個(gè)Html5的世界。在視頻播放領(lǐng)域，全民直播已經(jīng)開啟，這是一個(gè)實(shí)時(shí)性需求強(qiáng)于穩(wěn)定性的播放環(huán)境。蘋果也跟曾經(jīng)的Adobe一樣，猜中了故事的開始，卻踩空了這個(gè)故事的結(jié)局。

這也許就是商業(yè)世界最精彩的地方，即便你沖到萬億市值，對(duì)于未來而言，你我依然一無所知！

HLS 就先說到這，貼兩張 WIKI的截圖鎮(zhèn)樓，下一章的內(nèi)容馬上開始。

HLS Usage

HLS Clients

第二、為什么

我始終認(rèn)為，認(rèn)識(shí)一個(gè)新的事務(wù)，不管它是無形的技術(shù)還是有型的實(shí)體，都要從正反兩面去觀察。在聚光燈下，它標(biāo)榜的是什么？謝幕之后，它的無奈又是什么。只有這樣，才能保持我們的謙卑與疑惑，理性地分析，得到一個(gè)較為全面的認(rèn)識(shí)。

在本小節(jié)，我將通過解答一個(gè)問題的過程，建立對(duì)這三個(gè)協(xié)議的基本認(rèn)識(shí)。

兩端加一服

在開始之前，我先把流媒體服務(wù)中的雙端關(guān)系說一下。在一個(gè)完整的流媒體服務(wù)框架中，角色就是"兩端加一服"。推流端、拉流端加上媒體服務(wù)器。

同時(shí)按照應(yīng)用場(chǎng)景的不同，協(xié)議又分：

• 推流協(xié)議；

• 拉流播放協(xié)議；

大部分教程在介紹這三個(gè)協(xié)議的時(shí)候，都忽略了一點(diǎn)，就是協(xié)議的應(yīng)用場(chǎng)景到底是什么？RTMP 可以用在雙端，但 HLS 只能用在拉流端，記住這層關(guān)系。

帶著問題找答案：為什么RTMP比HLS快？

首先，這個(gè)問題發(fā)生在拉流端，協(xié)議也都是拉流協(xié)議。分別對(duì)RTMP和HLS的拉流播放進(jìn)行抓包，能得到以下兩張截圖。

RTMP

HttpFlv

通過報(bào)文數(shù)據(jù)我們能看出：
? 在RTMP下，從Handshake到第一個(gè)VideoData用了700ms的時(shí)間；
? 在HLS下，從Get m3u8到response ts Data只有300ms！

問題來了，HLS的響應(yīng)效率這么高，怎么就比RTMP還慢了呢？這都要從HLS的實(shí)現(xiàn)方案說起。

HLS拉流方案

在上圖的生產(chǎn)環(huán)境中，以RTMP協(xié)議推流，HLS拉流。端到端的時(shí)間消耗是：

• RTMP 推流端的聯(lián)通成本是 700ms ，注意此時(shí)的 700 毫秒包含了 connect 和 send Video Data ；

• 推流端聯(lián)通之后的時(shí)間成本，主要是采集編碼封包的成本，不需要再次connect；

• HLS的請(qǐng)求響應(yīng)成本是300ms；

• flvto ts的成本，用ffmpeg切一個(gè)10秒的碼率500的視頻，算上磁盤的寫入時(shí)間最多 200ms；

所以說，HLS的慢的原因只有一個(gè)，就是等數(shù)據(jù)！

Get Frist m3u8

以 demo 中的這個(gè) m3u8 來說，在直播的環(huán)境里媒體服務(wù)器要等到這 12 秒的數(shù)據(jù)推上來，我才有可能輸出。即使切片成本降為零，拉流端看到的數(shù)據(jù)也是12秒之前的內(nèi)容。

能不能優(yōu)化？能！
縮短ts間隔與個(gè)數(shù)，HLS也能做到3秒+的延遲。但這個(gè)結(jié)果也拼不過RTMP這種不需切片的解決方案。

第三、怎么選

當(dāng)您真正了解這三個(gè)協(xié)議之后，對(duì)于選擇的問題我相信您已經(jīng)有了自己的答案。我寫這篇博客的初衷，也是想以歷史背景入手，避免一上來就拋概念、甩結(jié)果。

希望我寫的這些內(nèi)容對(duì)您能有幫助，視頻解決方案很復(fù)雜，它涉及的內(nèi)容太多，在學(xué)習(xí)之初建立起清晰的脈絡(luò)至關(guān)重要。為他人易，為自己難！祝大家在多媒體服務(wù)上，選你所選，愛你所愛。

三協(xié)議小結(jié)

參考：
https://en.wikipedia.org/wiki/Real-Time_Messaging_Protocol
https://en.wikipedia.org/wiki/HTTP_Live_Streaming
http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf
https://datatracker.ietf.org/doc/rfc8216/
https://www.villainhr.com/page/2017/08/05/RTMP%20H5%20%E7%9B%B4%E6%92%AD%E6%B5%81%E6%8A%80%E6%9C%AF%E8%A7%A3%E6%9E%90

作者：北塔資訊
鏈接：https://www.jianshu.com/p/32417d8ee5b6
來源：簡(jiǎn)書
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

最后祝各位老板早生貴子！

怎么開心怎么來！怎么好玩怎么來！

歡迎各位老師投稿或者推薦分享文章、教程、故事等！一律保留版權(quán)

下面是小編微信，添加小編微信，我拉你進(jìn)群、可以學(xué)習(xí)、交流、交易直播周邊產(chǎn)品技術(shù)等！

1群已滿(中級(jí)玩家)

2群已滿(初級(jí)玩家)

3群新開(VMIX興趣新手訓(xùn)練班，謝絕純賣貨，平臺(tái)、擼毛黨)

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的ffmpeg rtmp 不清晰_知识储备：理解RTMP、HttpFlv和HLS的正确姿势的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。