我們將回顧一些最常用的流協(xié)議: RTMP、 RTSP、 WebRTC、 HLS、 SRT 和 CMAF

我們將了解以下流協(xié)議，以便:

• RTMP
• RTSP
• WebRTC
• HLS
• SRT
• CMAF

RTMP 實時消息協(xié)議

RTMP 流媒體協(xié)議是 Macromedia 開發(fā)的一種基于 TCP 的技術，用于在 Flash 播放器和服務器之間通過互聯(lián)網(wǎng)進行音頻、視頻和數(shù)據(jù)的流媒體傳輸。Macromedia 于2005年12月3日被競爭對手 Adobe 收購，但隨著 Flash 在2020年逐步淘汰，它的使用越來越少地與面向觀眾的內(nèi)容交付有關，而更多地是通過支持 RTMP 的編碼器將實時流攝入到平臺中。

流協(xié)議技術規(guī)范

• 音頻編解碼器: AAC，AAC-LC，HE-AAC + v1 & v2，MP3，Speex
• 視頻編解碼器: H. 264，VP8，VP6，Sorenson Spark，Screen Video v1 & v2
• 播放兼容性:不再得到廣泛支持了限于 Flash 播放器，AdobeAIR，RTMP 兼容的播放器 不再被 iOS、 Android、大多數(shù)瀏覽器和大多數(shù)嵌入式播放器所接受
•  優(yōu)點: 低延遲和最小緩沖
•  缺點: 沒有針對經(jīng)驗質(zhì)量或可伸縮性進行優(yōu)化
• 等待時間: 5秒

RTMP 變化

• RTMP: 普通的基于 TCP 的協(xié)議
•  RTMPS: 使用安全的 SSL 連接來最小化基于云的流的風險
•  RTMPE: 使用 Adobe 的專有安全加密，并且是比 RTMPS 更輕量級的加密層
• RTMPT: 用 HTTP 封裝以繞過防火墻和公司流量過濾
• RTMFP: 使用 UDP 代替 TCP

RTSP 實時流協(xié)議

RTSP 建立并控制單個或多個時間同步的連續(xù)媒體流，如音頻和視頻。RTSP 本身通常不提供連續(xù)的流，盡管可以將連續(xù)的媒體流與控制流交織在一起。換句話說，RTSP 充當多媒體服務器的“網(wǎng)絡遠程控制”。

由于大多數(shù) IP 攝像頭仍然支持 RTSP，它仍然是監(jiān)控和閉路電視系統(tǒng)中使用的標準。

RTSP 技術規(guī)格

• 音頻編解碼器: AAC，AAC-LC，HE-AAC + v1 & v2，MP3，Speex，Opus，Vorbis
• 視頻編解碼: H. 265(預覽) ，H. 264，VP9，VP8
• 播放兼容性:不被廣泛支持，很少用于播放(Quicktime Player 和其他 RTSP/rTP 兼容播放器，VideoLAN VLC media Player，3gpp 兼容移動設備)
• 優(yōu)點: 低延遲和無處不在的 IP 攝像頭
• 缺點: 沒有針對經(jīng)驗質(zhì)量和可伸縮性進行優(yōu)化
• 延遲2秒

RTSP 變化

• 整個 RTP 堆棧
• 實時控制協(xié)議
•  RTSP 通常被稱為 RTSP

網(wǎng)絡實時通信

WebRTC 代表 Web 實時通信，它是一個非常令人興奮的、強大的、具有高度破壞性的尖端技術和流協(xié)議。

它與 HTML5兼容，你可以使用它直接在瀏覽器和設備之間添加實時媒體通信。另外，你可以做到這一點，而不需要在瀏覽器中安裝任何必備的插件。它正逐漸得到所有主要的現(xiàn)代瀏覽器供應商的支持，包括 Safari、 Google Chrome、 Firefox、 Opera 和其他瀏覽器。

感謝 WebRTC 視頻流技術，您可以直接將實時視頻嵌入到基于瀏覽器的解決方案中，為您的受眾創(chuàng)建一個迷人的互動流體驗，而不用擔心延遲。

流協(xié)議特性

•  超低延遲視頻流-延遲是0.5秒
• 與平臺和設備無關
• 先進的語音和視頻質(zhì)量
• 加密語音和視頻
• 很容易縮放
• 適應網(wǎng)絡條件
•  數(shù)據(jù)通道

優(yōu)點

• 簡單，基于瀏覽器的貢獻
• 對等點直接打開彼此之間的連接
• 低延遲并支持500毫秒交付的交互性
• 可以在某些用例中端到端使用

缺點

• 不是廣播質(zhì)量流的最佳選擇，因為某些特性支持接近實時的傳輸

HLS (HTTP Live Streaming)

HLS 是一種基于 HTTP 的自適應協(xié)議，用于將視頻和音頻數(shù)據(jù)/內(nèi)容從媒體服務器傳輸?shù)浇K端用戶的設備。

合肥光源于2009年由蘋果公司創(chuàng)建。蘋果發(fā)布 HLS 的時間與傳奇設備 iPhone3差不多。早期的 iPhone3有直播播放問題，蘋果希望通過 HLS 解決這個問題。

Features of HLS Video Streaming Protocol

• 字幕
• 快進和倒帶
• 音頻和視頻交替播放
• F備用方案
• 定時元數(shù)據(jù)
• 插入廣告
•  內(nèi)容保護

HLS Technical Specifications

•  音頻編解碼器: AAC-LC，HE-AAC + v1 & v2，xHE-AAC，無損蘋果，F(xiàn)LAC
•  視頻編解碼器: H. 265，H. 264
• 播放兼容性: 它是為 iOS 設備創(chuàng)建的，然而，現(xiàn)在所有的 Google Chrome 瀏覽器，Android，Linux，Microsoft 和 macOS 設備; 一些機頂盒，智能電視和其他播放器支持 HLS，因為它是一個通用協(xié)議
• 優(yōu)點: 支持自適應比特率、可靠性和廣泛支持
•  缺點: 視頻質(zhì)量和觀眾體驗優(yōu)先于延遲
• 延遲: HLS 允許我們有5-20秒的延遲，但是低延遲的 HLS 擴展現(xiàn)在已經(jīng)被合并為 HLS 的一個特性集，承諾提供2秒以下的延遲

安全可靠的傳輸

SRT 是一種開源技術，用于在不可預測的公共網(wǎng)絡上進行可靠且低延遲的流媒體傳輸。它直接與 RTMP 和 RTSP 競爭，作為第一英里的解決方案，但仍被采用作為編碼器，解碼器和播放器添加支持。SRT 在2020年的一個互動用例被證明是第一個虛擬 NFL 草案ーー確保高質(zhì)量的流媒體和在任何有互聯(lián)網(wǎng)連接的地方的操作靈活性。

SRT 優(yōu)點

• 專有協(xié)議的開源替代方案
• 高質(zhì)量低延遲
• 設計用于在不可預測的公共網(wǎng)絡上進行現(xiàn)場視頻傳輸
• 解釋了數(shù)據(jù)包丟失和抖動

SRT 限制

• 不受所有編碼器的本機支持
• 作為新技術仍在被采用
• 沒有廣泛的播放支持

CMAF 通用媒體應用格式

CMAF 是一種簡化基于 HTTP 的流媒體交付的新格式。它是一個新興的標準，有助于降低成本和復雜性，并提供大約3-5秒的延遲流。CMAF 可用于 DASH 或 HLS。

由于 RTMP 的地位不斷下降，其他基于 HTTP (超文本傳輸協(xié)議)的自適性串流技術也應運而生。但是，不同的流標準需要不同的文件容器。例如，當 MPEG-DASH 使用。MP4集裝箱，HLS 流交付在。其格式。

因此，每個想要接觸更多觀眾的廣播公司都必須對同一個視頻文件進行兩次編碼和存儲，因為加密創(chuàng)建了完全不同的文件組。

這兩個版本的同一個視頻流應提前或立即進行。這兩個過程都需要額外的存儲和處理成本。

蘋果和微軟建議移動圖片專家組創(chuàng)建一個新的統(tǒng)一標準，稱為通用媒體應用格式(CMAF) ，以降低在線視頻傳輸?shù)膹碗s性。

CMAF優(yōu)勢

•  削減成本
•  最小化工作流復雜性
• 減少延遲