安防互聯網直播服務中爲何HTML5目前尚未實時的低延遲視頻流協議？

咱們最多見的流媒體協議的RTMP協議，在網絡和硬件正常好的狀況下，延遲能夠達到1-3s左右，它也是目前主流視頻直播中最多見的協議，像咱們的安防流媒體服務器也支持這種協議的視頻流輸出。

爲何到如今尚未 HTML5 上的實時（延遲 < 3s）視頻流協議？理論上利用 websocket + AVC TS 是能夠實現的，可是正常總會遇到不少現實的問題。

在h5頁面中，若是要用RTMP或HTTP-FLV，須要基於瀏覽器開發插件，然而瀏覽器有不少種，同時，基於別人的瀏覽器作插件，基本是不可能的。蘋果公司開放了HLS協議，這種協議在h5中不須要插件便可進行播放，解決了在h5頁面中直播的問題。

然而，對於直播來講，HLS協議仍是存在不少問題：

一、播放時須要屢次請求，對於網絡質量的要求更高
二、延遲在10s左右
三、同時還存在延時累積，好比一分鐘內的延遲有5s，看了10分鐘後，延遲可能會達到50s
四、只能支持拉流，不支持推流

H5中播放直播的場景主要是，以ios、安卓爲主要平臺，分享到第三方應用中，經過hls協議拉流，來爲app引流。此外，要想作到HLS小於3秒的延時，理論上是能夠的，這須要看你ts分片的大小，和一個m3u8存儲多少個ts的分片的索引。

若是一個m3u8存儲6個ts的分片索引，每一個分片爲5s，那麼就起碼有30s的延時。只要把分片的時長減小，好比減小到250ms每一個分片，一個m3u8只存儲一個ts分片，那麼理論延時就只有250ms。可是這樣的話，每秒鐘至少有4次的HTTP請求，而且由於每個ts分片都有I幀，大大增大了須要傳送的帶寬。

會給服務器帶來不少壓力，也會增長流量上的消耗，因此整體上很難有兼顧帶寬，延時和減輕服務器壓力的HLS方案。