最近要给一个在澳洲运营的赛马网站做在线直播,要求超低延时,并且支持手机和PC端直接播放,不安装任何播放插件。
由于这种业务的特殊性,直播延时必须在500ms以内才能接受,否则通过网络参与的游戏玩家会比现场玩家迟后看到结果,影响决策的准确性和游戏的公平性。为此,我们考察了N多种方案对其进行比较。
通过考察,目前主流的实现方案主要有以下几种:
1. 使用rtmp流媒体服务器实现直播分发,客户端用hls协议播放;
优点:集成方便,支持度高,兼容性好,主流手都支持,是目前直播主流技术。
缺点:延时大,一般服务器可以控制切片时长(延时可以控制在10-30秒之间)。
结论:无法满足要求。
2. 基于HTML5浏览器的MSE扩展技术,采用HTTP协议的FLV直播流进行分发,客户端通过浏览器端的格式转封装进行解码播放,服务器端使用支持HTTP FLV的流媒体服务器。
优点:集成方便,兼容性一般,延时可以控制在3秒内。
缺点:(主要是部分浏览器不支持mse,),目前IOS平台的内置浏览器不支持,iOS端的微信内也不能播放,延时稍大。
结论:无法满足要求。
3. 基于WebRTC方式实现直播功能,这方面google已经在大力支持,主流的浏览器也已经支持(Chrome、Firefox、IE11、Safari、Android移动端),直播端到端延时可以控制在0.5秒以内,网络状况好的时候可以达到0.2秒。
优点:终端兼容性好,延时超低并且可控。
缺点:当前的主流CDN还不支持,需要自建流媒体服务器。
结论:符合要求,是当前最为可行的运营方案。
通过以上方案比较,最终确定选用第三种方案来实现这个网络博彩的直播应用。
接下来是具体实现方案的选型。
通过实际测试比较发现,第3种方案的主要技术难点在流媒体服务器端的实现上,不同厂商有不同的技术实现方式,下面做一比较:
1. 采用Java语言来实现。
这种实现方式,需要在操作系统之上安装一个Java虚拟机,由于java虚拟机的性能实在太低,大大影响了平台的整体性能,所以该方案被否定了。
2. 采用PHP语言来实现。
PHP是一种解释型语言,虽然它比java语言性能更高,但是与编译型语言相比性能仍然有很大差距。因此影响了服务器端的整体性能表现。
3. 采用C++语言来实现。
这种实现方式是所有方案中效率最高的,对比测试后发现,它的性能是PHP的十倍,是java的30倍。
因此,最终我们确定找一款基于C++语言来实现的流媒体服务器。经过朋友推荐,由微软亚洲研究院流媒体研发团队开发的一款低延时直播服务器性能优异,服务器端的流转发延时在3毫秒以内,同时,对其进行性能测试发现,在一台普通配置的硬件服务器环境下(Dell R730/E5-2650x2,32GB内存,10GE网络),它可以支持720P@2Mb/s 5000并发访问,而其它流媒体服务器最高支持到1000并发访问。
其次,直播延时的产生不仅与服务器和客户端有关,还有编码延时有关。为此,我们测试了多种直播编码方案,包括:
1. 硬件H.264编码器。
2. 软件编码器,有“串流直播”、“OBS”、“Adobe FMLE”。
3. 使用带有直播功能的IP摄像机。
综合比较下来,只有“串流直播”这款专业软件编码器最符合使用需要,因为它支持的直播协议最为丰富、编码延时最低、而且可以根据我们的特殊应用为我们提供个性化改造,包括调整GOP结构,减少H.264编码中的B帧数量,直播数据加密。
因此,我们通过前端采用“串流直播”软件来降低编码延时,同时服务器端采用微软亚洲研究院开发的流媒体服务器来降低数据转发延时,同时在接收端采用WebRTC播放技术降低解码延时,从而将端到端的延时控制在了500ms以内,在网络条件理想的情况下甚至达到了300ms以内的延时。
方案架构:
信号采集端:采用HD-SDI接口的高清摄像机+工控主机(内接多路高清采集卡);
流媒体服务端:采用微软亚洲研究院开发的低延时流媒体服务器;
播放端:采用WebRTC实时解码播放技术;