| RTP /RTCP |
RTP 實行有序傳送,RTP中的序列號允許接收方重組發(fā)送方的包序列，同時序列號也能用于決定適當(dāng)?shù)陌恢茫缭谝曨l解碼中，就不需要順序解碼。RTCP的主要功能是為RTP所提供的服務(wù)質(zhì)量提供反饋，例如：RTP傳輸字節(jié)數(shù)，傳輸分組數(shù)，丟失分組數(shù)，單向和雙向網(wǎng)絡(luò)延遲等。網(wǎng)絡(luò)應(yīng)用程序可以利用RTCP所提供的信息來提高服務(wù)質(zhì)量，比如限制流量或改用壓縮比小的編解碼器 |
RTP載荷的最大尺寸為1460字 節(jié)。以H264 為例，如果一幀數(shù)據(jù)大于1460，則需要分片打包，然后到接收端再拆包，組合成一幀數(shù)據(jù)，進行解碼播放。 |
| RTSP:(Real Time Streaming Protocol)實時流協(xié)議 |
RTSP 是一種雙向?qū)崟r數(shù)據(jù)傳輸協(xié)議，它允許客戶端向服務(wù)器端發(fā)送請求，如回放、快進、倒退等操作。而且，RTSP 可基于RTP 來傳送數(shù)據(jù)，還可以選擇 TCP、UDP、組播 UDP 等通道來發(fā)送數(shù)據(jù)，具有很好的擴展性 |
1.服務(wù)端實現(xiàn)復(fù)雜。2.代理服務(wù)器弱：數(shù)量少，優(yōu)化少3. 無路由器防火墻穿透。4. 管流分離：需要1-3個通道 |
| RTMP協(xié)議(Real Time Messaging Protocol)實時消息傳輸協(xié)議 |
RTMP是Adobe Systems公司為Flash播放器和服務(wù)器之間音頻、視頻和數(shù)據(jù)傳輸開發(fā)的開放協(xié)議。該協(xié)議基于TCP，RTMP是一種設(shè)計用來進行實時數(shù)據(jù)通信的網(wǎng)絡(luò)協(xié)議，主要用來在Flash/AIR平臺和支持RTMP協(xié)議的流媒體/交互服務(wù)器之間進行音視頻和數(shù)據(jù)通信。1.速度快，誤碼率低，延遲低 。2.RTMP 是專為流媒體服務(wù)而生，協(xié)議在制定的時候就考慮到很多底層的優(yōu)化3.消息塊的傳輸能夠提供更加穩(wěn)定的直播環(huán)境，在硬件上要求會更高，但是卻能夠緩解http的繁瑣的傳輸介質(zhì) |
1.不支持Html5傳播、瀏覽器推送 2.基于TCP協(xié)議,雖然開發(fā)難度大，推廣度還不夠，對于開發(fā)人員來說門檻比較高 3.硬件要求相較于HLS較高。 4. 協(xié)議復(fù)雜：開發(fā)者寫起來累，效率也不行。5.Cache麻煩：流協(xié)議做緩存不方便。 |
| HTTP-FLV協(xié)議 |
FLV協(xié)議由Adobe公司主推，即將音視頻數(shù)據(jù)封裝成 FLV，然后通過 HTTP 協(xié)議傳輸給客戶端，格式極其簡單，只是在大塊的視頻幀和音視頻頭部加入一些標(biāo)記頭信息，在延遲表現(xiàn)和大規(guī)模并發(fā)方面都很成熟。但是在手機瀏覽器上的支持非常有限，但是用作手機端APP直播協(xié)議卻異常合適。 |
1.需要http長連接 2.h5中需要使用插件。3.需要flash技術(shù)支持，不支持多音頻流，多視頻流，不便于拖動 |
| HLS協(xié)議 |
HLS協(xié)議蘋果推出，將視頻分成5-10秒的視頻小分片，然后用m3u8索引表進行管理，由于客戶端下載到的視頻都是5-10秒的完整數(shù)據(jù)，故視頻的流暢性很好，但也同樣引入了很大的延遲(HLS的一般延遲在10-30s左右)。實際上還是純“文本協(xié)議”相比于FLV，HLS在iPhone和大部分android手機瀏覽器上的支持非常給力。HLS協(xié)議客戶端支持簡單, 只需要支持 HTTP 請求即可, HTTP 協(xié)議無狀態(tài), 只需要按順序下載媒體片段即可，而且網(wǎng)絡(luò)兼容性好, HTTP 數(shù)據(jù)包也可以方便地通過防火墻或者代理服務(wù)器。但是相比RTMP 這類長連接協(xié)議, 用到互動直播場景延時較高。 |
相比 RTMP 這類長連接協(xié)議, 延時較高, 難以用到直播場景。對于點播服務(wù)來說, 由于 TS 切片通常較小, 海量碎片在文件分發(fā), 一致性緩存, 存儲等方面都有較大挑戰(zhàn)，小文件碎片化嚴重 |
