經常使用的流媒體協議及其應用場景等信息總結

近日一直被直播延時問題所困惑，爲此特整理一些關於經常使用流媒體的協議信息，但願能對本身解決直播延時有所幫助。

1.RTMP(Real Time Messaging Protocol)
Adobe推出的實時消息傳輸協議。該協議基於TCP，是一種設計用來進行實時數據通訊的網絡協議，主要用來在Flash/AIR平臺和支持RTMP協議的流媒體/交互服務器之間進行音視頻和數據通訊，默認端口1935。通常傳輸的是flv，f4v格式流

2.RTSP/RTP/RTCP協議族(Real-time Streaming Protocol)
實時流傳輸協議，由RealNetworks開發。RTSP在體系結構上位於RTP(實時傳輸協議)和RTCP(RTP控制協議)之上，它使用TCP或UDP完成數據傳輸。RTSP協議族與HTTP相比，優點在於能夠控制到視頻幀，所以能夠承載實時性很高的應用。默認端口554。通常傳輸的是ts,mp4格式的流

3.HLS(Http live streaming)
×××出的流媒體協議。採用m3u8做爲索引文件，視頻爲MPEG2-TS格式的片斷文件。若是爲直播視頻流，則採起更新m3u8文件，達到視頻直播的目的。由於最終視頻是片斷文件，存在列表視頻長度的延遲。所以只可用於對實時性要求沒有那麼高的準實時視頻流。文件存儲格式爲ts + m3u8

4.HDS（HTTP dynamic streaming）
Adobe推出的流媒體協議，這種方式本質和HLS的策略是相似的，就是經過索引文件+視頻片斷的方式。可是顯然採用的索引格式和視頻片斷格式都不同的。文件存儲格式爲flv/f4v/mp4 + f4m（相似m3u8）

5.Smooth Streaming
微軟也推出了Microsoft Smooth Streaming，也便是mss的視頻播出方式，採用的視頻格式是分段mp4格式。文件存儲格式爲ismv + isml（相似m3u8）

6.HTTP視頻協議
最初的HTTP視頻協議，沒有任何特別之處，就是通用的HTTP文件漸進式下載。本質就是下載視頻文件，而利用視頻文件自己的特色，就是存在頭部信息，和部分視頻幀數據，就徹底能夠解碼播放了。顯然這種方式須要將視頻文件的頭部信息放在文件的前面。

7.有關HTML5
同時HTML制定廠商也不寂寞，推出HTML5這種方式，這種方式本質上，和前面的HTTP視頻協議沒有任何區別。可是播放器端，再也不依賴於特定的插件如flash或者其餘播放軟件，而是能夠支持瀏覽器的直接視頻播放。採用的是html中嵌入video標籤，同時直接指明視頻的url。不過，不一樣的瀏覽器，對於音視頻的格式支持不徹底相同。

#幕後花絮：期間諮詢過老東家的研發同時，老大哥說「我司是從直播源辣的專線，不存在延時這麼一說啊」「咱們監控直播買的探針服務啊」 哈哈……好吧好吧，請原諒我忘了哈哈哈……