通過私有化部署自建一套視訊流媒體伺服器平臺如何解決視訊播放延時卡頓問題（二）之不同視訊流延時說明

針對私有化部署一套流媒體伺服器軟體的視訊延時問題，我們在上文為大家介紹了視訊低延時主要影響因素之網路情況、前端裝置的碼流、前端裝置的數量、直播流協議的選擇四大要素，本文主要為為大家介紹最後一個，直播流協議的選擇。

每年這麼多使用者需求，我們發現關於視訊直播，延時是使用者特別關注的問題。基於這些使用者的需求，我們之前給大家出過一篇延時測試的博文：EasyNVR如何進行延遲測試。

不同的網路現場會有不同的延遲，但是除了這個外界因素影響之外，不同的直播流自身帶的就會有延時，這種延時不可逆，本文就分別為大家介紹一下：

RTMP

優勢：

RTMP 對底層的優化比其它協議更加優秀，同時它 Adobe Flash 支援好，基本上所有的編碼器（攝像頭之類）都支援 RTMP 輸出。另外 RTMP 適合長時間播放，曾經有過測試，連續 100 萬秒，即 10 天多連續播放沒有出現問題。最後 RTMP 的延遲相對較低，一般延時在 1-3s 之間，一般的視訊會議、互動式直播完全夠用。

缺點：

當然 RTMP 並沒有盡善盡美，它也有不足的地方。一方面是它是基於 TCP 傳輸，非公共埠，可能會被防火牆阻攔；另一方面，也是比較坑的一方面是 RTMP 為 Adobe 私有協議，很多裝置無法播放，特別是在 iOS 端，需要使用第三方解碼器才能播放。

HLS

優勢：

HLS 是由蘋果公司提出的基於 HTTP 的流媒體網路傳輸協議。是蘋果公司 QuickTime X 和 iPhone 軟體系統的一部分。它的工作原理是把整個流分成一個個小的基於TS的檔案來下載，每次只下載一部分。當媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應不同的資料速率。效能高，可以通過 CDN 進行網路分發。

缺點：

HLS的劣勢也非常明顯，首先 HLS 實時性差，延遲高，HLS 的延遲基本在 10s+ 以上。另外由於 HLS 請求的並不是完整的資料流，導致它產生檔案碎片多。ts 切片較小，會造成海量小檔案，對儲存和快取都有一定的挑戰。

FLV

優勢：

FLV是一種在網路上傳輸的流媒體資料儲存容器格式。而我們所說的 HTTP-FLV 即將流媒體資料封裝成 FLV 格式，然後通過 HTTP 協議傳輸給客戶端。HTTP-FLV 能夠很好的穿透防火牆，它是基於 HTTP/80 傳輸，有效避免被防火牆攔截。另外，它可以通過 HTTP 302 跳轉靈活排程/負載均衡，支援使用 HTTPS 加密傳輸，也能夠相容支援 Android，iOS 的移動端。

缺點：

FLV 也有一個缺點，由於它的傳輸特性，會讓流媒體資源快取在本地客戶端，在保密性方面不夠好。

RTSP

優勢：

RTSP在體系結構上位於RTP和RTCP之上，它使用TCP或UDP完成資料傳輸。使用RTSP時，客戶機和伺服器都可以發出請求，即RTSP可以是雙向的。RTSP是用來控制聲音或影像的多媒體串流協議，並允許同時多個串流需求控制，傳輸時所用的網路通訊協定並不在其定義的範圍內，伺服器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP 1.1類似，但並不特別強調時間同步，所以比較能容忍網路延遲。因為與HTTP1.1的運作方式相似，所以代理伺服器〈Proxy〉的快取功能〈Cache〉也同樣適用於RTSP，並因RTSP具有重新導向功能，可視實際負載情況來轉換提供服務的伺服器，以避免過大的負載集中於同一伺服器而造成延遲。

缺點：RTSP直播流協議一般使用udp 作為傳輸層，適合IPTV場景。

比較

• 傳輸協議上：RTMP→TCP，HTTP-FLV→HTTP，HLS→HTTP，RTSP→UDP；
• 視訊封裝格式：RTMP→FLV/TAG，HTTP-FLV→FLV，HLS→M3U8/TS，RTSP→TS/MP4；
• 延時：RTMP→2S，HTTP-FLV→2S，HLS→10S+，RTSP→3S；
• 資料分段：RTMP→連續流，HTTP-FLV→連續流，HLS→切片，RTSP→切片。

總結

TSINGSEE青犀視訊通過智慧排程、鏈路保障、追幀處理、丟幀處理以及業界首創的 HLS+ 技術，將 RTMP直播延遲控制在1秒內，將HTTP-FLV 、WS-FLV、RTSP直播流延時控制在3秒內，將 HLS 直播延時控制在 10秒左右。

所以，當排除網路、碼流、裝置效能的情況下，在不同的直播場景中，選用合適的直播協議，能大大降低直播的延遲。當然，真正在私有化部署的過程中，以上幾點都需要綜合考量，保障視訊流的流暢播放。