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

支持的网络协议对比

协议是服务器的基础，协议决定了关键应用场景，譬如毫秒级别延时只能用udp，秒级别延迟用RTMP，十秒级别可以用HLS。

1、RTMP延时特点

延迟较低：

比起YY的那种UDP私有协议，RTMP算延迟大的（延迟在1-3秒），比起HTTP流的延时（一般在10秒以上）RTMP算低延时。一般的直播应用，只要不是电话类对话的那种要求，RTMP延迟是可以接受的。在一般的视频会议（参考SRS的视频会议延时）应用中，RTMP延时也能接受，原因是别人在说话的时候我们一般在听，实际上1秒延时没有关系，我们也要思考（话说有些人的CPU处理速度还没有这么快）。

C++音视频开发学习资料：点击领取→音视频开发（资料文档+视频教程+面试题）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）

C++程序员必看，抓住音视频开发的大浪潮！冲击年薪60万

有累积延迟：

技术一定要知道弱点，RTMP有个弱点就是累积误差，原因是RTMP基于TCP不会丢包。所以当网络状态差时，服务器会将包缓存起来，导致累积的延迟；待网络状况好了，就一起发给客户端。这个的对策就是，当客户端的缓冲区很大，就断开重连。当然SRS也提供配置。

2、延时影响因素

• GOP SRS可以关闭GOP的cache来避免这个影响
• 服务器性能太低 服务器来不及发送数据
• 播放端 譬如flash客户端的NetStream.bufferTime设置为10秒，那么延迟至少10秒以上
• 推流端 GOP、Profile、Tune等编码参数

SRS集群（边缘）不会增加延迟

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;
    }
}

可以将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协议替换

4、编码参数设置

GOP = 1；Profile = baseline； Tune = zerolatency (主要是GOP编码参数)，例如OBS的编码设置如下：

测试结果，RTMP为1秒、m3u8为3秒：