目录
前言
低延迟研究
设备兼容性
webRtc调试
播放器
体系结构
结论
问题
rtc_player.html点击播放报错
局域网RTC黑屏
附件
前言
上一篇我们通过单机版的srs服务器，验证了srs确实具备作为直播服务器的能力。但是验证后，我们其实也发现了一个问题就是srs基于rtmp协议来拉流的的延迟度很高。（因为我查找过资料srs的直播延迟最主要原因不是推流侧导致的，而是拉流导致的，所以直播延迟研究不考虑推流一侧）
上一篇：传送门
低延迟研究srs直播的低延迟原因，通过官方给的提示：
我们大致知道了：
webRTC的延迟最低flv延迟次之hls最慢所以，我们立马选定下一步要研究的方向为基于webRTC协议的srs低延迟直播。
注：很多人可能会问，笔者上面的这个图片是怎么得到的：
http://localhost:8080/players/rtc_player.html
通过访问上面这个链接得到的，因为当srs启动的时候，默认的一个srs播放器就有了。这个player.html是部署在srs服务器上的，所以当srs启动了，这个页面就可以访问了。而上面的这个提示就在我用这个播放页面来播放rtmp协议的拉流的时候提示的。
设备兼容性查看更多资料后知道了，使用webrtc速度可以降低到1s以内，缺点是啥，后续再了解。
同时了解到了未来项目里头直播需要在微信上通过h5网页就要可以直接打开，而webrtc刚好就满足这一个要求。
Srs在SRS4.0.14之后才开始支持webrtc的。
webRtc调试
上一篇，我们已经搭建好的srs直播服务器我们使用的是rtc2rtmp.conf这个配置文件，这个配置文件本身就支持了webRTC协议，所以，我们无需再搭建webRTC协议的srs直播服务器了，直接沿用上篇的环境就可以了。
播放器使用srs提供的播放器页面：http://localhost:8080/players/rtc_player.html
url输入webrtc://ip/live/1，然后点击播放就可以了。
体系结构基于webRTC协议的srs直播的模式是利用obs来推流，然后利用rtc_player.html来拉流。
结论经过 试验，发现基于webRTC协议的直播，延迟一般在0.5s之内，这个是肉眼估计出来的。不过因为是基于本地环境来做的，没有部署在公网上，我也查找了一些有公网部署经验的人说，公网上的延迟也是在1s以内，那基本上是很快了。
问题其实在部署过程也出现了很多问题。上面是在写博客给大家看，所以看起来非常的顺利，其实实际上并没有这么顺利。每次遇到一个问题都要解决老半天才可以。
rtc_player.html点击播放报错实际在验证webRTC的时候，因为想要对比rpc和rtmp的延迟，所以新开了一个docker容器，并把srs对外的端口改了，但是rtc的调试台，默认传输端口就是1985，如下：
所以自己默认的docker对外的映射端口改成1986之后，调试平台访问就报错了，这个问题，调试了近3个小时，才发现。
上面这个问题的解决方案是：
原先webRTC的url为：webrtc://ip/live/1
改成webrtc://ip:1986/live/1
局域网RTC黑屏直播可以了，之后就很开心，就想让同事来体验下这种直播的感觉，所以就把rtc_player.html的地址复制给同事，同事可以正常打开这个播放页面，但是输入播放的地址点击播放之后，整个播放器只是出于加载中的黑屏状态。（注：同事跟我处于同一局域网）
经过了解主要是因为candidate参数的缘故。
解决方案：
方案1：需要设置candidate的值，在docker启动的时候设置为当前宿主机的ip
如：docker run -d --env CANDIDATE=172.22.224.1 -p 1935:1935 -p 8080:8080 -p 1985:1985 -p 80:80 -p 8000:8000/udp --privileged=true 5de52d772a3c /usr/sbin/init
方案2：将rtc2rtmp.conf文件的candidate配置成*，在访问rpc的时候加参数eip，取值宿主机的ip。
如：webrtc://172.20.124.241:1985/live/1?eip=172.20.124.241
附件自己封装的webRTC的播放器，大家可以用这个播放器来播放webRTC:
播放器下载
下一篇：基于srs-bench对直播服务器压测