iOS直播技術(shù)學(xué)習(xí)筆記-流媒體協(xié)議(七)

常見的流媒體協(xié)議

  • 常見的流媒體協(xié)議有很多比如:
    • RTP(Real-time Transport Protocol), 常用語電話會議, 網(wǎng)絡(luò)電話等場景, 但是缺點是不提供網(wǎng)絡(luò)保障
    • RTCP(Real-time Transport Control Protocol), 是實時傳輸協(xié)議(RTP)的一個姐妹協(xié)議, 也常用于語電話會議, 網(wǎng)絡(luò)電話等場景.
    • RTMP(Real Time Streaming Protocol), RTMP是Adobe開發(fā)的協(xié)議
    • HLS(HTTP Live Streaming)是蘋果公司(Apple Inc.)實現(xiàn)的基于HTTP的流媒體傳輸協(xié)議,可實現(xiàn)流媒體的直播和點播

HLS(HTTP Live Streaming)

  • HTTP Live Streaming(HLS)是蘋果公司實現(xiàn)的基于HTTP的流媒體傳輸協(xié)議,可實現(xiàn)流媒體的直播和點播。原理上是將視頻流分片成一系列HTTP下載文件。所以,HLS比RTMP有較高的延遲。HLS基于HTTP協(xié)議實現(xiàn),傳輸內(nèi)容包括兩部分,一是M3U8描述文件,二是TS媒體文件
    • 相對于常見的流媒體直播協(xié)議,例如RTMP協(xié)議、RTSP協(xié)議、MMS協(xié)議等,HLS直播最大的不同在于,直播客戶端獲取到的,并不是一個完整的數(shù)據(jù)流。HLS協(xié)議在服務(wù)器端將直播數(shù)據(jù)流存儲為連續(xù)的、很短時長的媒體文件(MPEG-TS格式),而客戶端則不斷的下載并播放這些小文件,因為服務(wù)器端總是會將最新的直播數(shù)據(jù)生成新的小文件,這樣客戶端只要不停的按順序播放從服務(wù)器獲取到的文件,就實現(xiàn)了直播。
    • 由此可見,基本上可以認(rèn)為,HLS是以點播的技術(shù)方式來實現(xiàn)直播。
  • 工作流程為:
    • 采集視頻源和音頻源的數(shù)據(jù)
    • 對原始數(shù)據(jù)進行H264編碼和AAC編碼
    • 視頻和音頻數(shù)據(jù)封裝為MPEG-TS包
    • HLS分段生成策略及m3u8索引文件
    • HTTP傳輸協(xié)議傳輸數(shù)據(jù)
工作流程.png
  • 使用FFmpeg命令將mp4文件切換成m3u8&ts切片
// 安裝Homebrew
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
// 安裝FFmpeg
brew install ffmpeg
// 執(zhí)行轉(zhuǎn)換命令
ffmpeg -i XXX.mp4 -c:v libx264 -c:a copy -f hls XXX.m3u8

  • m3u8索引頭解析
m3u8索引頭解析.png

RTMP

  • RTMP協(xié)議是 Adobe 公司開發(fā)的一個基于TCP的應(yīng)用層協(xié)議,Adobe 公司也公布了關(guān)于RTMP的規(guī)范
  • RTMP本質(zhì)上是流協(xié)議,主要的優(yōu)勢是:
    • 實時性高:RTMP的實時性在3秒之內(nèi),經(jīng)過多層CDN節(jié)點分發(fā)后,實時性也在3秒左右,在一些實時性有要求的應(yīng)用中以RTMP為主。
    • 支持加密:RTMPE和RTMPS為加密協(xié)議
    • 穩(wěn)定性高:HTTP也很穩(wěn)定,但HTTP是在協(xié)議上穩(wěn)定穩(wěn)定性不只是服務(wù)端的事情,在CDN分發(fā),服務(wù)器管理,客戶端的支持上
  • RTMP的使用
    • RTMP協(xié)議也要客戶端和服務(wù)器通過“握手”來建立基于傳輸層鏈接之上的RTMP Connection鏈接,在Connection鏈接上會傳輸一些控制信息
    • TMP協(xié)議傳輸時會對數(shù)據(jù)做自己的格式化,這種格式的消息我們稱之為RTMP Message
    • 而實際傳輸?shù)臅r候為了更好地實現(xiàn)多路復(fù)用、分包和信息的公平性,發(fā)送端會把Message劃分為帶有Message ID的Chunk,每個Chunk可能是一個單獨的Message,也可能是Message的一部分,在接受端會根據(jù)chunk中包含的data的長度,message id和message的長度把chunk還原成完整的Message,從而實現(xiàn)信息的收發(fā)。
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

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

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