針對私有化部署一套流媒體服務器軟體的視頻延時問題，我們在上文為大家介紹了視頻低延時主要影響因素之網路情況、前端設備的碼流、前端設備的數量、直播流協議的選擇四大要素，本文主要為為大家介紹最后一個，直播流協議的選擇，
每年這么多用戶需求，我們發現關于視頻直播，延時是用戶特別關注的問題，基于這些用戶的需求，我們之前給大家出過一篇延時測驗的博文：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秒左右，
所以，當排除網路、碼流、設備性能的情況下，在不同的直播場景中，選用合適的直播協議，能大大降低直播的延遲，當然，真正在私有化部署的程序中，以上幾點都需要綜合考量，保障視頻流的流暢播放，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/125720.html
標籤：其他