2022年使用最多的流媒體協議和技術規范

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

我們將了解以下流協議，以便:

RTMP
RTSP
WebRTC
HLS
SRT
CMAF

RTMP 實時消息協議

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

流協議技術規范

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

RTMP 變化

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

RTSP 實時流協議

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

由于大多數 IP 攝像頭仍然支持 RTSP，它仍然是監控和閉路電視系統中使用的標準。

RTSP 技術規格

音頻編解碼器: 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 兼容移動設備)
優點: 低延遲和無處不在的 IP 攝像頭
缺點: 沒有針對經驗質量和可伸縮性進行優化
延遲2秒

RTSP 變化

整個 RTP 堆棧
實時控制協議
RTSP 通常被稱為 RTSP

網絡實時通信

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

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

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

流協議特性

超低延遲視頻流-延遲是0.5秒
與平臺和設備無關
先進的語音和視頻質量
加密語音和視頻
很容易縮放
適應網絡條件
數據通道

優點

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

缺點

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

HLS (HTTP Live Streaming)

HLS 是一種基于 HTTP 的自適應協議，用于將視頻和音頻數據/內容從媒體服務器傳輸到終端用戶的設備。

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

Features of HLS Video Streaming Protocol

字幕
快進和倒帶
音頻和視頻交替播放
F備用方案
定時元數據
插入廣告
內容保護

HLS Technical Specifications

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

安全可靠的傳輸

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

SRT 優點

專有協議的開源替代方案
高質量低延遲
設計用于在不可預測的公共網絡上進行現場視頻傳輸
解釋了數據包丟失和抖動

SRT 限制

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

CMAF 通用媒體應用格式

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

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

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

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

蘋果和微軟建議移動圖片專家組創建一個新的統一標準，稱為通用媒體應用格式(CMAF) ，以降低在線視頻傳輸的復雜性。

CMAF優勢

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

鋒網按：本文作者蔣海兵，趣拍產品總監，直播行業老兵。

移動直播行業的火熱會在很長一段時間內持續，通過和各行業的整合，從而成為具有無限可能性的行業。主要有以下三個原因：

第一，移動直播的UGC生產模式比PC端的直播更明顯，人人都有設備，隨時隨地開播，完全順應了互聯網時代的開放性原則，能刺激更多人去創造和傳播優質內容。

第二，網絡帶寬和速度在逐漸提高，網絡成本在逐漸下降，為移動直播提供一個極佳的發展環境。文字、聲音、視頻、游戲等都會在移動直播中呈現，創造出更加豐富的用戶體驗。直播可以以SDK的形式接入到自己的應用中，比如，教育領域中的課后輔導完全可以以直播的形式開展業務、電商也可借助直播讓用戶挑選商品，促進銷售。

第三，一個與VR/AR技術相結合的移動直播為整個行業的未來提供了新的發展空間。VR/AR直播能夠讓用戶身臨其境，帶動主播與觀眾更貼近真實的互動，大大提高平臺的用戶參與度。

當下，有技術實力和流量優勢的互聯網從業者都不愿錯過直播這個風口，如何快速搭建一個直播系統成了大家關心的問題，我想和大家分享下我的經驗。我從事于一家直播產品開發商，我們的產品為了快速趕上市場，使用了云服務提供商的直播SDK。

從業者都知道，一個完整直播產品應該包含以下環節：推流端（采集、前處理、編碼、推流）、服務端處理（轉碼、錄制、截圖、鑒黃）、播放器（拉流、解碼、渲染）、互動系統（聊天室、禮物系統、贊）。下面我就一一講述下直播SDK在各個環節所做的工作。

一、移動直播推流端需要做哪些工作？

直播推流端即主播端，主要通過手機攝像頭采集視頻數據和麥克風采集音頻數據，經過一系列前處理、編碼、封裝，然后推流到CDN進行分發。

1、采集

移動直播SDK通過手機攝像頭和麥克風直接采集音視頻數據。其中，視頻采樣數據一般采用RGB或YUV格式、音頻采樣數據一般采用PCM格式。采集到的原始音視頻的體積是非常大的，需要經過壓縮技術處理來提高傳輸效率。

2、前處理

在這個環節主要處理美顏、水印、模糊等效果。美顏功能幾乎是直播的標配功能。我們調研中發現太多case是因為沒有美顏功能被拋棄使用的。另外國家明確提出了，所有直播都必須打有水印并回放留存15天以上。

美顏實際上是通過算法去識別圖像中的皮膚部分，對皮膚區域進行色值調整。通過顏色對比找到皮膚區域，可以進行色值調整、添加白色圖層或調整透明度等來達到美白效果。在美顏處理方面，最著名的GPUImage提供了豐富的效果，同時可以支持iOS和Android，支持自己寫算法實現自己最理想的效果。GPUImage內置了120多種常見濾鏡效果，添加濾鏡只需要簡單調用幾行代碼就可以了。

3、編碼

為了便于手機視頻的推流、拉流以及存儲，通常采用視頻編碼壓縮技術來減少視頻的體積，現在比較常用的視頻編碼是H.264。在音頻方面，比較常用的是AAC編碼格式，其它如MP3、WMA也是可選方案。視頻經過編碼壓縮大大提高了視頻的存儲和傳輸效率，當然，經過壓縮后的視頻在播放時必須進行解碼。

相較于之前的H.264，2012年誕生的H.265編解碼標準有了相當大的改善，做到了僅需要原來一半帶寬即可播放相同質量的視頻，低于1.5Mbps的網絡也能傳輸1080p的高清視頻。像阿里云、金山云都在推自己的H.265編解碼技術，隨著直播的快速發展和對帶寬的依賴，H.265編解碼技術已有全面取代H.264的趨勢。

H264和H265個模塊技術差異：

另外，硬件編碼已經成為移動直播的首選方案，軟編碼處理在720p以上的視頻頹勢非常明顯。在iOS平臺上硬件編碼的兼容性比較好，可以直接采用，但在Android平臺上，Media Codec編碼器針對不同的芯片平臺表現差異還是非常大的，要完全實現全平臺兼容的成本還是非常高的。

4、推流

要想用于推流還必須把音視頻數據使用傳輸協議進行封裝，變成流數據。常用的流傳輸協議有RTSP、RTMP、HLS等，使用RTMP傳輸的延時通常在1–3秒，對于移動直播這種實時性要求非常高的場景，RTMP也成為移動直播中最常用的流傳輸協議。最后通過一定的Qos算法將音視頻流數據推送到網絡斷，通過CDN進行分發。在直播場景中，網絡不穩定是非常常見的，這時就需要Qos來保證網絡不穩情況下的用戶觀看直播的體驗，通常是通過主播端和播放端設置緩存，讓碼率均勻。另外，針對實時變化的網絡狀況，動態碼率和幀率也是最常用的策略。

當然，在網絡傳輸方面全部自己來做基本不現實，找提供推流服務的CDN服務商提供解決方案是最好的選擇。據了解，阿里云是國內唯一能自研CDN緩存服務器的廠商，性能非常有保障。當然，大多數直播平臺都會同時接入多個視頻云服務提供商，這樣可以做拉流線路互備，對推流后視頻集群再進行優化也可提高直播的流暢性和穩定性。

二、服務端處理需要做哪些工作？

要想適配各終端和平臺，服務端還需要對流進行轉碼，如支持RTMP、HLS、FLV等格式拉流，支持一路轉多路適配不同網絡和分辨率的終端設備。

1、截圖、錄制、水印

像阿里云等云服務商都提供了實時轉碼技術，將用戶推流碼率較高（比如720P）實時轉化成較低清晰度（比如360P）的流以適應播放端的需求。如果要自己搭建實時轉碼系統，這個成本是極高的，一臺8核設備只能實時轉10路流，如果一個正常的直播平臺有1000路流，就需要100臺設備，加上后期的運維成本，一般公司就吃不消了。

2、鑒黃

2016年4月14日，文化部查出了斗魚、虎牙、YY、熊貓TV、六間房、9158等涉嫌提供含宣揚淫穢、暴力、教唆犯罪的網絡直播平臺，被列入查處名單。政府介入管制有利于直播行業打造健康的生態，進入良性發展。這也意味著為了安全直播產品鑒黃成了必需環節，使用技術手段去鑒黃是移動直播平臺必然采用的方案。

市面上提供鑒黃服務的方案主要有兩種：

第一種是對視頻進行截圖，然后對圖片進行鑒黃，返回鑒黃結果和分值。典型的企業有阿里（綠網）、圖譜科技，他們目前都支持直接傳入視頻，經過服務端分析返回結果。通常由業務系統接入鑒黃服務，根據鑒黃結果對直播流進行控制，如切斷直播流、封禁賬號等。

第二種是和CDN結合，直接對直播流進行分析，識別結果分為色情、疑似色情、性感和正常，業務系統根據識別結果直接控制直播流。典型的企業是Viscovery，這套方案的優點是實時性保證比較好，缺點是必須部署到CDN或自己的機房，使用成本相對高一些。

還有一種一站式直播解決方案提供商，他們的做法是，用戶只需在控制臺對鑒黃服務進行配置就可以針對每個應用、每一路直播流進行實時審核。在控制臺中，云服務商實時將鑒黃結果返回，用戶可以直接查看色情直播和違規界面的截圖，同時可以對直播流進行控制，切斷問題直播流。該服務商還提供了短信、郵件和站內信功能，避免漏掉任何一個非法視頻，給平臺造成損失，我們就使用了這種方式。

三、播放器端需要做哪些工作？

在播放器端如何做到秒開，直播過程中保證畫面和聲音清晰度的同時，穩定、流程、無卡頓的直播流量，這些工作都需要播放器端配合服務端來做優化，做到精確調度。

1、拉流

拉流實際是推流的逆過程。首先通過播放端獲取碼流，標準的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的專利協議，開源軟件和開源庫都支持的比較好，如開源的librtmp庫，播放端只要支持flashPlayer的就能非常簡單的播放RTMP直播，直播延遲一般在1–3秒。

HLS是蘋果提出的基于HTTP的流媒體傳輸協議，HTML5可以直接打開播放，通過微信、QQ等軟件分享出去，用戶也可以直接觀看直播，可以說移動直播app，HLS拉流協議是必須支持的，缺點是延遲通常大于10秒。FLV（HTTP-FLV）協議是使用HTTP協議傳輸流媒體內容的一個協議，也不用擔心被Adobe的專利綁架，直播延遲同樣可以做到1–3秒。

各拉流協議的差異：

我們使用的云服務的直播拉流技術提供了以上三種格式，滿足不同業務場景的需求，如對即時性要求較高或有互動需求的可以采用RTMP或FLV格式進行直播拉流播放；對于有回放或跨平臺需求的，推薦使用HLS。當然，三種協議是可以同時使用的，分別用到自己的場景就可以了。

2、解碼和渲染

拉流獲取封裝的視頻數據后，必須通過解碼器解碼、渲染后才能在播放器上播放。它是編碼的逆過程，是指從音視頻的數據中提取原始數據。前面介紹的H.264和H.265編碼格式都是有損壓縮，所以在提取后的原始數據，并非原始采樣數據，存在一定的信息丟失。因此，在視頻體積最小的情況下通過各種編碼參數保留最好的原始畫面，成為了各視頻公司的核心機密。

考慮對高清的支持，解碼肯定還是要選擇硬解碼的。前面介紹過，iOS系統由于硬件比較單一、比較封閉，支持的比較好，Android系統由于平臺差異非常大，編解碼要完全兼容各平臺還需要很多工作要做。

四、移動直播中的交互系統

移動直播中最常見的交互有聊天室（彈幕）、點贊、打賞和禮物等，交互系統涉及消息的實時性和互動性，在技術實現上大多是使用IM的功能來實現的。對于在線人數比較多的房間，彈幕消息量是非常大，主播與用戶其實都看不過來，為了緩解服務器壓力，在產品策略需要做一些必要的優化。

1、聊天室

移動直播中的彈幕交互是用戶和主播互動的主要方式，實際上就是IM中的聊天室功能。聊天室和群聊功能類似，但聊天室的消息是不需要分發給不在線的用戶的，歷史消息也不需要查看，用戶只有進入聊天室后才能查看聊天消息和群成員信息。面對復雜多變的網絡狀況，還需要根據用戶位置就近選擇近對應運營商的單線機房接入彈幕消息服務，讓彈幕更及時。

2、禮物系統

禮物系統更是絕大多數移動直播平臺的標配了，它是這些平臺主要的收入來源。送禮物的形式也增強了用戶和主播之間的互動交流，也是主播依賴平臺的最主要原因。

禮物的收發在技術實現上也是用聊天室接口做的，通常采用IM中的自定義消息實現，當用戶收到或發送禮物時將自定義消息對應的禮物圖形渲染出來。

以上就是我們在使用了第三方SDK服務后總結出來的直播產品經驗，希望能幫助到創業者和從業者們。

境部署

1、配置、安裝 Nginx；

# ./configure --sbin-path=/usr/local/nginx/nginx --conf-path=/usr/local/nginx/nginx.pid --with-http_ssl_module --with-pcre=/usr/local/src/pcre-8.39 --with-zlib=/usr/local/src/zlib-1.2.11 --with-openssl=/usr/local/openssl/
# make
# make install
# /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf  //啟動Ngnix
# netstat -ano | grep 80

2、擴展 Nginx-rtmp-module

C++音視頻開發學習資料：點擊領取→音視頻開發（資料文檔+視頻教程+面試題）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）

# ./configure --add-module=/usr/local/src/nginx-rtmp-module-master --with-openssl=/usr/local/openssl/
# make
# make install
# vim /usr/local/ngnix/conf/ngnix.conf
include /usr/localcinx-rtmp-module-master/testinx.conf;
# vim /usr/localcinx-rtmp-module-master/testinx.conf
rtmp {
    server {
        listen 1935;

        application myapp {
            live on;

            #record keyframes;
            #record_path /tmp;
            #record_max_size 128K;
            #record_interval 30s;
            #record_suffix .this.is.flv;

            #on_publish http://localhost:8080/publish;
            #on_play http://localhost:8080/play;
            #on_record_done http://localhost:8080/record_done;
        }

            application hls {
            live on;
            hls on;
            hls_path /tmp/hls;
            hls_fragment 10s;     #每個視頻切片的時長。
            hls_playlist_length 60s;  #總共可以回看的事件，這里設置的是1分鐘。
            #hls_continuous on; #連續模式。
            #hls_cleanup on;    #對多余的切片進行刪除。
            #hls_nested on;     #嵌套模式。
        }
    }
}

http {
    server {
        listen      8080;

        location /stat {
            rtmp_stat all;
            rtmp_stat_stylesheet stat.xsl;
        }

        location /stat.xsl {
            root /usr/local/src/nginx-rtmp-module-master/;
        }

        location /control {
            rtmp_control all;
        }

        location /rtmp-publisher {
            root /usr/local/src/nginx-rtmp-module-master/test;
        }

            location /hls {
            #server hls fragments
            types{
                application/vnd.apple.mpegurl m3u8;
                video/mp2t ts;
            }
            #alias /tmp/app;
            root /tmp;
            expires -1;
        }

        location / {
            root /usr/local/src/nginx-rtmp-module-master/test/rtmp-publisher;
        }
    }
}
# /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
# netstat -ltn  #查看端口的監聽情況

3、安裝 ffmpeg

# ./configure --prefix=/usr/local/ffmpeg
# make
# make install