前主流的流媒體服務器主要有 nginx-rtmp、crtmpd、wowza、red5、adobe fms等。

支持的網(wǎng)絡協(xié)議對比

協(xié)議是服務器的基礎，協(xié)議決定了關鍵應用場景，譬如毫秒級別延時只能用udp，秒級別延遲用RTMP，十秒級別可以用HLS。

1、RTMP延時特點

延遲較低：

比起YY的那種UDP私有協(xié)議，RTMP算延遲大的（延遲在1-3秒），比起HTTP流的延時（一般在10秒以上）RTMP算低延時。

一般的直播應用，只要不是電話類對話的那種要求，RTMP延遲是可以接受的。在一般的視頻會議（參考SRS的視頻會議延時）應用中，RTMP延時也能接受，原因是別人在說話的時候我們一般在聽，實際上1秒延時沒有關系，我們也要思考（話說有些人的CPU處理速度還沒有這么快）。

有累積延遲：

技術一定要知道弱點，RTMP有個弱點就是累積誤差，原因是RTMP基于TCP不會丟包。所以當網(wǎng)絡狀態(tài)差時，服務器會將包緩存起來，導致累積的延遲；待網(wǎng)絡狀況好了，就一起發(fā)給客戶端。這個的對策就是，當客戶端的緩沖區(qū)很大，就斷開重連。當然SRS也提供配置。

2、延時影響因素

• GOP
• SRS可以關閉GOP的cache來避免這個影響
• 服務器性能太低
• 服務器來不及發(fā)送數(shù)據(jù)
• 播放端
• 譬如flash客戶端的NetStream.bufferTime設置為10秒，那么延遲至少10秒以上
• 推流端
• GOP、Profile、Tune等編碼參數(shù)

SRS集群（邊緣）不會增加延遲

C++音視頻學習資料免費獲取方法：關注音視頻開發(fā)T哥，點擊「鏈接」即可免費獲取2023年最新C++音視頻開發(fā)進階獨家免費學習大禮包！

3、編寫配置文件

配置SRS為低延時模式，可以將RTMP延遲降低到0.8-3秒：

# conf/realtime.conf
listen              1935;
max_connections     1000;
vhost __defaultVhost__ {
    tcp_nodelay     on;
    min_latency     on;

    play {
        gop_cache       off;
        queue_length    10;
        mw_latency      100;
    }

    publish {
        mr off;
    }
}

低延時模式影響性能，更多參考如下：

github.com/ossrs/srs/w…

可以將HLS延遲降低到3-5秒：

listen              1935;
max_connections     1000;
vhost __defaultVhost__ {
    hls {
        enabled            on;
        hls_path           ./objs/nginx/html;
        hls_fragment       0.2;
        hls_window         2;
        hls_wait_keyframe  off;
    }
}

HLS還可考慮使用FLV協(xié)議替換

4、編碼參數(shù)設置

GOP = 1；Profile = baseline； Tune = zerolatency (主要是GOP編碼參數(shù))，例如OBS的編碼設置如下：

測試結果，RTMP為1秒、m3u8為3秒：

作者：郎涯技術 鏈接：https://juejin.cn/post/6996664571117174798

#音視頻開發(fā)#

LS，HTTP，RTSP，RTMP協(xié)議的區(qū)別：

• 用HTTP方式： 先通過服務器將FLV下載到本地緩存，然后再通過NetConnection的本地連接來播放這個FLV，這種方法是播放本地的視頻，并不是播放服務器的視頻。因此在本地緩存里可以找到這個FLV。其優(yōu)點就是服務器下載完這個FLV，服務器就沒有消耗了，節(jié)省服務器消耗。其缺點就是FLV會緩存在客戶端，對FLV的保密性不好。

是一種將直播流模擬成FLV文件，通過HTTP協(xié)議進行下載的模式來實現(xiàn)流媒體傳輸?shù)膮f(xié)議，端口號80
一般建議使用HTTP FLV，實時性和RTMP相等。
優(yōu)點：HTTP相比于RTMP省去了一些協(xié)議交互時間，首屏時間更短。HTTP可拓展的功能更多。

• 用RTMP方式： 通過NetConnection連接到FMS(Flash Media Server)或Red5服務器，并實時播放服務器的FLV文件，這種方式可以任意選擇視頻播放點，并不象HTTP方式需要緩存完整個FLV文件到本地才可以任意選擇播放點，其優(yōu)點就是在本地緩存里是找不到這個FLV文件的。其優(yōu)點就是FLV不會緩存在客戶端，F(xiàn)LV的保密性好，其缺點就是消耗服務器資源，連接始終是實時的。
• 由以上分析可知，Http方式是本地播放，而RTMP方式是服務器實時播放.

Adobe公司的流媒體傳輸協(xié)議，端口號1935
普通網(wǎng)絡用戶均可使用，包括非IOS平臺用戶，對非80端口（如1935）無限制的網(wǎng)絡環(huán)境用戶。
優(yōu)點：防HTTP下載，延時短。

• RTSP: RTSP 1.0標準的制訂者沒有充分預測到互聯(lián)網(wǎng)帶寬的快速增長，以及由于IPv4地址短缺導致的NAT技術的廣泛使用，還有代理服務器的大量存在，它在傳輸可靠性和易用性上都存在一定的缺陷。雖然各家廠商都做了一定程度的修補，比如支持RTSP over HTTP，支持NAT穿透等，但仍然于事無補。在2005之后網(wǎng)絡視頻大爆炸的幾年中，RTSP 1.0并沒有得到y(tǒng)outube, hulu, 土豆，優(yōu)酷等視頻服務提供商的青睞，相反，Adobe公司開發(fā)的私有流媒體技術RTMP以其優(yōu)秀的易用性和富媒體的一體化集成，得到了多數(shù)視頻服務提供商的追捧，成為了事實上的標準.

缺點：web端播放rtsp流的話，需要寫插件，而且對瀏覽器也很挑剔，flash不支持rtsp，需要做activeX插件

目前的CDN都是基于RTMP的

• HLS(Http Living Streaming): 從2010年起，蘋果開始在iOS設備上支持一種叫做”Live HTTP”的流媒體技術，并宣布在iOS上不會支持RTSP和Flash技術。Live HTTP本質(zhì)上跟基于HTTP的文件分段下載很接近。在帶寬充裕的前提下，live HTTP能夠實現(xiàn)跟RTSP和RTMP同樣的流媒體播放效果，同時得到了更好的易用性，更簡單的控制。
  在最新一代的超文本標識語言HTML5中，視頻文件的點播，同樣也采用了HTTP作為其承載協(xié)議。

HLS
IOS平臺下的流媒體傳輸協(xié)議 ，端口號80
優(yōu)點：H5瀏覽器支持比較好，IOS，安卓原生支持。
缺點：延遲性比較大。樓上說的切片，關鍵幀改變后切片時間可以縮短，而且可以自己設定首次產(chǎn)生多少分片。

音視頻開發(fā)教學視頻：【免費】FFmpeg/WebRTC/RTMP/NDK/Android音視頻流媒體高級開發(fā)-學習視頻教程-騰訊課堂