方案一
- 采用 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;
}
}
}
方案二
- 采用 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)？
