方案一

• 采用 nginx + nginx-rtmp-module. 作为RTMP 服务器，用 ffmpeg 做直接摄像头采集推流，用VLC 拉流。
• 硬件环境：T44OP笔记本上搞了个virtual box虚拟机(2个CPU，2G内存，网络桥接）,ubuntu 16.04 TLS 版本。
• ffmpeg 和 vlc都运行在本机的win 10环境下。
• nginx 配置脚本简单如下（这里没有研究那些低延迟配置）

rtmp{
        server{
                listen 1883;
                application mylive{
                        live on;
                        record off;
                }
        }
}

• 测试起来效果并不好，延时大概10来秒。

方案二

• 采用 simple rtmp server 作为RTMP 服务器，用 ffmpeg 做直接摄像头采集推流，用VLC 拉流。
• 硬件环境：T44OP笔记本上搞了个virtual box虚拟机(2个CPU，2G内存，网络桥接）,ubuntu 16.04 TLS 版本。
• ffmpeg 和 vlc都运行在本机的win 10环境下。
• simple rtmp server 配置脚本简单如下

listen              1935;
max_connections     1000;
vhost __defaultVhost__ {
        enabled         on;
        gop_cache       off;
        queue_length    5;
        mw_latency      350;
}

• 测试起来效果比nginx-rtmp-module 这个要好，这里已经有些低延迟的一些，配置，比如GOP 处理，缓冲队长度等。延时大概5秒左右，偶尔有时候可在1~2秒范围内。

• ** 因此对于像直接做类似直播秀之类的场景来说，选择srs 是一个更好的选择**

有些疑问,哪天有空研究一下

• 如果对于多个拉流的场景，似乎每个点看到时间点是不一样的？比如你看到得是2秒前的，他看到有可能是5秒前的？他们怎么解决这个问题？不过这个不同步似乎也没有关系。
• 客户端推流时，编码器，GOP应该怎么选择，涉及到视频流的质量和效果？一般我们做RTP流大概2秒强制一个I帧，甚至如果在变化不大的流里面，为了降低网络流量，会采取一定的策略来拉长I帧间隔。延迟和GOP设置也是有很大的关联的。这个TCP流，不同于UDP。是不是开始之前有个测试网络环境流程？
• 关于连麦，是不是推和拉之间直接建立一个链接（类似P2P)？