兼容GB/T28181设备的WebRTC视频会议系统及媒体流转换方法

兼容gb/t28181设备的webrtc视频会议系统及媒体流转换方法
技术领域
1.本发明涉及计算机多媒体通信领域，尤其涉及一种优化拥塞控制与流转码方法的兼容gb/t28181设备的webrtc视频会议系统及媒体流转换方法。


背景技术：

2.视频会议系统是网络、通信和多媒体等多种技术综合的应用，在对实时信息需求日益强烈的现在，视频会议系统以其直观、真实、跨地域、低成本的交流特点，受到了人们越来越多的重视，被广泛用于各种组织活动的各个领域，如远程教育、远程谈判、远程医疗、远程诊断等。
3.特别是随着新型智慧城市基础设施的不断建设和发展，在城市管理的指挥调度应用中，需要指挥大厅指挥调度人员、现场操作人员、业务和技术专家通过多端视频会议开展协同工作，为指挥调度人员、现场操作人员、业务和技术专家在任何时间和任何区域提供直观、真实、跨地域的实时信息交流。但是传统的视频会议系统，由于成本过高，开发时间长，不利于推广，因此开发时间短，成本低的webrtc(网页实时通信)常作为视频会议的首选。
4.webrtc原有的gcc算法，兼顾基于延迟和基于丢包两种拥塞控制策略。网络发生拥塞时,在2至3秒内能估计出码率来适应网络状态，会有短时间的卡顿。对于网络发生间歇性丢包，在2秒左右能将传输码率适配到当前网络状态；在弱网环境下，容易将码率降到很低而造成图像失真；因此基于延迟的带宽估计模块在网络抖动场景下存在误认为网络过度使用而导致码率误降低的问题。并且原gcc算法从基于丢包率的候选发送速率和基于网络延迟变化的候选发送速率中选择较小的一个作为下一阶段的目标发送速率，所以强网环境下gcc对网络延迟的变化过于敏感。


技术实现要素：

5.针对上述问题，本发明提兼容gb/t28181设备的webrtc视频会议系统及媒体流转换方法。实现了gb28181设备的ps流转码成webrtc的流，使gb28181的设备也可以接入会议系统。又为了优化gcc算法在网络抖动场景下的表现，提升音视频体验效果，本发明提出了igcc-a算法,igcc-a算法基于webrtc当前最新的版本中的gcc算法进行改进。该算法为了避免突发delay导致带宽下降,在检测拥塞变化后，加性增乘性减的速率控制器中不会立刻进行降低带宽，而是会观察6次来回时间，如果仍然出现过度使用状态，才去降低带宽，连续降低3次，直到降低到成功接收速率0.85倍。同时该算法在gcc获得两个候选发送速率后和决定目标发送速率前，添加一个强网的限制条件,降低gcc在强网下对网络延迟的敏感程度，减少因为网络延迟的小幅波动造成的发送速率的频繁抖动。
6.本发明提供如下技术方案：一种兼容gb/t28181设备的webrtc视频会议系统，所述系统采用分层的架构体系，包括业务层、stun/turn服务器、信令层和媒体层；
7.业务层：用于为webrtc客户端提供业务接口，存储业务数据；
8.stun/turn服务器：用于实现nat穿越；
9.信令层包含webrtc信令模块、信令协议转换模块和gb/t28181信令模块；其中，webrtc信令模块实现视频会议系统与客户端之间的信令交互；信令协议转换模块实现webrtc信令与gb/t28181信令之间的转换；gb/t28181信令模块实现与gb/t28181终端采集设备之间的会话建立；
10.媒体层包含webrtc媒体模块、媒体转码模块、拥塞控制模块和gb/t28181媒体模块；其中，webrtc媒体模块实现视频监控设备与webrtc客户端之间的媒体传输；媒体转码模块实现webrtc媒体流与gb/t28181媒体流之间的转换；gb/t28181媒体模块实现与终端采集设备的媒体传输；在转码模块到webrtc媒体模块之间的拥塞控制模块，用于减少在网络中流媒体包的丢包率,降低网络延时。
11.媒体层接口的实现包括本地媒体流获得getmedia、建立实时通信连接rtcpeerconnection、实时通信数据通道rtcdatachannel、创建gb/t28181rtp包接收端口openrtpserver；
12.本地媒体流获得getmedia用于获取从本地摄像头和麦克风采集的媒体流；这个接口在不同的浏览器中名字不相同，在chrome中是webkitgetusermedia,在firefox中是mozgetusermedia。因此在使用时应做好浏览器兼容的工作getmedia接口使用格式是getusermedia，包括constraints,successcallback,errorcallback，其中constraints表示对音频和视频是否支持的设置，格式是一个json串；successcallback是一个函数，表示若获取成功将执行的函数；errorcallback是一个函数,表示若获取失败将执行的函数。
13.调用getmedia得到媒体流之后，需要将其绑定到video标签上，并将其autoplay属性设置为ture，否则屏幕上只能展示一张图片。同时根据window.url.createobjecturl函数将通过getmedia获得的本地媒体流数据转换成一个url,并把它作为video标签的视频源。
14.建立实时通信连接rtcpeerconnction接口用来在两个节点间建立一条传输数据流的连接；rtcpeerconnection可以作为浏览器事件目标接口的参数。而事件event是html默认类，目标target会返回触发事件的元素本身。
15.实时通信数据通道rtcdatachannel在两个用户之间可靠高效地传输任意格式数据，还实现了获取网络线程负载的接口getthreadsload，gb/t28181流的rtp包接收端口openrtpserver，关闭gb/t28181流的rtp包接收端口closertpserver，获取rtp推流端信息接口getrtpinfo，rtp包处理接口processinterface；
16.创建gb/t28181rtp包接收端口openrtpserver，该端口接收数据超时，则会自动被回收，关闭gb/t28181rtp接收端口closertpserver、获取rtp推流端信息接口getrtpinfo、rtp包处理接口processinterface接口。
17.一种基于上述会议系统的媒体流转换方法，所述媒体流转换用于实现gb/t28181媒体流转webrtc流，具体步骤如下：
18.步骤1：收流端口接收荷载ps流的rtp数据包，gb28181媒体流是rtp数据包荷载的ps流，先查找第一个荷载着ps包头的rtp包，然后将荷载着ps包的rtp包放到ps包缓存中；
19.步骤2：检查rtp包的sequence是否连续，如果连续，则进入步骤3，如果不连续则ps缓存清空，同时清空主h.264缓存和帧缓存，同时跳到第5步；
20.步骤3：ps包缓存中rtp包解析，同时继续不断接受rtp包放到ps包缓存中，直到接收完一个完整的ps包，将完整ps包中荷载的视频数据解析成es流，放到视频主h.264缓存和副h.264缓存中；
21.步骤4：对主h.264缓存中的es流进行拆帧，将拆分出的每一个完整的h.264帧放到帧缓存中；
22.步骤5：对ps包中拆出的es流进行拆帧，拆帧时对副h.264缓存的最后一个缓存进行拆帧，将拆分出的每一个完整的h.264帧放到帧缓存中，保证播放端始终有画面；
23.步骤6：通过打包模块将帧缓存中完整的h.264帧打包成webrtc的流；
24.步骤7：根据拥塞控制模块中igcc-a算法反馈的发送码率，通过url推流模块将打包好的流推给webrtc流媒体模块。
25.所述的igcc-a算法为gcc算法的优化算法，谷歌拥塞控制算法(google congestion control，gcc)，该算法包含两部分：基于丢包的码率控制和基于延迟的码率控制。这两种部分都是通过调节数据发送端码率来达到拥塞控制的目的。
26.基于丢包的码率控制,其基本思想是：丢包产生说明网络已经开始发生拥塞，如果丢包率为0或者非常小，则说明网络状态良好，可以适当增大码率，提高清晰度。如果丢包率变大，说明网络质量出现恶化要减少向网络中发送的数据量，降低发送端编码码率，其它情况发送码率保持不变。发送端的码率控制是根据丢包率来计算预期的发送码率，丢包率的信息包含在接收到的rtcp报告报文中。计算公式如下，其中f
l
(tk)表示tk时刻的丢包率，as(tk)表示tk时刻的发送码率：
[0027][0028]
基于延迟的码率控制,其基本思想是：rtp数据包的到达时间延迟反映网络拥塞状况。当延迟很小时，说明网络拥塞不严重，可以适当增大目标码率；当延迟变大时，说明网络拥塞变严重，需要减小目标码率；当延迟维持在一个低水平时，目标码率维持不变。
[0029]
发送端的码率控制是根据延迟来计算预期的发送码率。计算公式如下，其中ti表示第i个视频帧被接收的时间，η＝1.05，α＝0.85，rr(ti)表示最近500ms中测量的接收码率，ar(ti)表示ti时刻的发送码率：
[0030][0031]
在新近的webrtc的实现中，所有的带宽估计都放在了发送端，也就说发送端除了做基于丢包的带宽估计，同时也做基于延迟梯度的带宽估计。为了能够在接受端做基于延迟梯度的带宽估计，webrtc扩展了rtp/rtcp协议，其一是增加了rtp扩展头部，添加了一个session级别的sequence number,目的是基于一个session做反馈信息的统计，而不紧紧是一条音频流或视频流；其二是增加了一个rtcp反馈信息transport-cc-feedback，该消息负责反馈接受端收到的所有媒体包的到达时间。接收端根据包间的接受延迟和发送间隔可以计算出延迟梯度，从而估计带宽。
[0032]
webrtc原有的gcc算法，兼顾基于延迟和基于丢包两种拥塞控制策略。网络发生拥塞时,在2至3秒内能估计出码率来适应网络状态，会有短时间的卡顿。对于网络发生间歇性丢包，在2秒左右能将传输码率适配到当前网络状态；在弱网环境下，容易将码率降到很低而造成图像失真；因此基于延迟的带宽估计模块在网络抖动场景下存在误认为网络过度使用而导致码率误降低的问题。并且原gcc算法从基于丢包率的候选发送速率和基于网络延迟变化的候选发送速率中选择较小的一个作为下一阶段的目标发送速率，而强网下由于gcc对网络延迟的变化过于敏感。
[0033]
为了需要针对性的优化gcc算法在网络抖动场景下的表现，提升音视频体验效果，本文提出了igcc-a算法,igcc-a算法基于webrtc当前最新的版本中的gcc算法进行改进。算法详细内容如下：
[0034]
1)在检测拥塞变化后，加性增乘性减的速率控制器中不会立刻进行降低带宽，而是会观察6次来回时间，如果仍然出现过度使用状态，去降低带宽，连续降低3次，直到降低到成功接收速率0.85倍；igcc-a算法对于到达时间接近的归到一个包组,只计算一个延迟变化量,而相距较远的分到不同的组，这样能避免突发抖动到来时，按原算法以包组计算单向时延变化，基于延迟的速率控制器误认为拥塞而下降带宽。
[0035]
2)在gcc分别根据丢包率和延迟变化算出ti时刻的两候选发送速率as(ti)和ar(ti)后，igcc-a按照下面的方式做出决策：
[0036][0037]
其中a(ti)为ti时刻的发送码率，限制条件函数p(ti)的值代表igcc-a允许当前的拥塞算法忽略微小的延迟波动，当前会话的通话质量足够可靠时，即p(ti)》0时，igcc-a直接选择基于丢包率的速率控制器给出的速率作为当前的目标发送速率；一旦限制条件函数的值不满足要求，即p(ti)≤0时，igcc-a收回允许并按照原gcc的算法规则进行拥塞控制，
[0038]
为了让限制条件函数更灵活地适应不同的丢包率和延迟波动，我们按照如下的方式来定义限制条件函数：
[0039][0040]
其中fr(ti)和f
l
(ti)代表ti时刻的rtt和丢包率，和代表附加因素对限制条件函数的影响，同时，一旦丢包率超过3％，认为此时的直播频道的网络质量不够理想，并停止忽略微小的延迟波动，在p(ti)》0时。
[0041]
通过上述描述可以看出本方案中可以使gb28181的设备也可以接入会议系统，实现了gb/t28181的ps流转webrtc流。同时采用了igcc-a算法，igcc-a算法为优化gcc算法在网络抖动场景下的表现，提升音视频体验效果,igcc-a算法基于webrtc当前最新的版本中的gcc算法进行改进。该算法为了避免突发delay导致带宽下降,在检测拥塞变化后，加性增乘性减的速率控制器中不会立刻进行降低带宽，而是会观察6次来回时间，如果仍然出现过度使用状态，才去降低带宽，连续降低3次，直到降低到成功接收速率0.85倍。同时该算法在gcc获得两个候选发送速率后和决定目标发送速率前，添加一个强网的限制条件,降低gcc在强网下对网络延迟的敏感程度，减少因为网络延迟的小幅波动造成的发送速率的频繁抖
动。
附图说明
[0042]
图1为本发明具体实施方式的视频会议系统示意图；
[0043]
图2是媒体流转换流程图；
[0044]
图3是流媒体服务中流转换结构示意图；
[0045]
图4是加性增乘性减的速率控制器优化图。
具体实施方式
[0046]
下面将结合本发明具体实施方式中的附图，对本发明具体实施方式中的技术方案进行清楚、完整地描述，显然，所描述的具体实施方式仅仅是本发明一种具体实施方式，而不是全部的具体实施方式。基于本发明中的具体实施方式，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他具体实施方式，都属于本发明保护的范围。
[0047]
通过附图可以看出，本方案提供了一种兼容gb/t28181设备的webrtc视频会议系统，所述系统采用分层的架构体系，如图1所示，包括业务层、stun/turn服务器、信令层(信令服务器)和媒体层(流媒体服务器)；各层级内部采用低耦合、高内聚的模块化设计。
[0048]
业务层：用于为webrtc客户端提供业务接口，存储业务数据。
[0049]
stun/turn服务器：用于实现nat穿越。
[0050]
信令层包含webrtc信令模块、信令协议转换模块和gb/t28181信令模块；其中，webrtc信令模块实现视频会议系统与客户端之间的信令交互；信令协议转换模块实现webrtc信令与gb/t28181信令之间的转换；gb/t28181信令模块实现与gb/t28181终端采集设备之间的会话建立；利用webrtc2sip网关实现了webrtc客户端app侧基于websocket传输的sip协议到基于udp/tcp传输的sip协议的转换,实现了sip会话消息的互通。
[0051]
媒体层包含webrtc媒体模块、媒体转码模块、拥塞控制模块和gb/t 28181媒体模块；其中，webrtc媒体模块实现视频监控设备与webrtc客户端之间的媒体传输；媒体转码模块实现webrtc媒体流与gb/t28181媒体流之间的转换；gb/t28181媒体模块实现与终端采集设备的媒体传输；在转码模块到webrtc媒体模块之间的拥塞控制模块，用于减少在网络中流媒体包的丢包率,降低网络延时。
[0052]
媒体层接口的实现包括本地媒体流获得getmedia、建立实时通信连接rtcpeerconnection、实时通信数据通道rtcdatachannel、创建gb/t28181 rtp包接收端口openrtpserver；
[0053]
本地媒体流获得getmedia用于获取从本地摄像头和麦克风采集的媒体流；
[0054]
建立实时通信连接rtcpeerconnction接口用来在两个节点间建立一条传输数据流的连接；
[0055]
实时通信数据通道rtcdatachannel在两个用户之间可靠高效地传输任意格式数据，还实现了获取网络线程负载的接口getthreadsload，gb/t28181流的rtp包接收端口openrtpserver，关闭gb/t28181流的rtp包接收端口closertpserver，获取rtp推流端信息接口getrtpinfo，rtp包处理接口processinterface；
[0056]
创建gb/t28181 rtp包接收端口openrtpserver，该端口接收数据超时，则会自动
被回收，关闭gb/t28181 rtp接收端口closertpserver、获取rtp推流端信息接口getrtpinfo、rtp包处理接口processinterface接口。
[0057]
getmedia接口使用格式是getusermedia，包括constraints,successcallback,errorcallback，其中constraints表示对音频和视频是否支持的设置，格式是一个json串；successcallback是一个函数，表示若获取成功将执行的函数；errorcallback是一个函数,表示若获取失败将执行的函数。
[0058]
一种基于上述系统的媒体流转换方法，如图2所示，实现的gb/t28181的ps流转webrtc流的实时转换步骤如下：，具体步骤如下：
[0059]
步骤1：收流端口接收荷载ps流的rtp数据包，gb28181媒体流是rtp数据包荷载的ps流，先查找第一个荷载着ps包头的rtp包，然后将荷载着ps包的rtp包放到ps包缓存中；
[0060]
步骤2：检查rtp包的sequence是否连续，如果连续，则进入步骤3，如果不连续则ps缓存清空，同时清空主h.264缓存和帧缓存，同时跳到第5步；
[0061]
步骤3：ps包缓存中rtp包解析，同时继续不断接受rtp包放到ps包缓存中，直到接收完一个完整的ps包，将完整ps包中荷载的视频数据解析成es流，放到视频主h.264缓存和副h.264缓存中；
[0062]
步骤4：对主h.264缓存中的es流进行拆帧，将拆分出的每一个完整的h.264帧放到帧缓存中；
[0063]
步骤5：对ps包中拆出的es流进行拆帧，拆帧时对副h.264缓存的最后一个缓存进行拆帧，将拆分出的每一个完整的h.264帧放到帧缓存中，保证播放端始终有画面；
[0064]
步骤6：通过打包模块将整的h.264帧打包成webrtc的流；
[0065]
步骤7：根据拥塞控制模块中igcc-a算法反馈的发送码率，通过url推流模块将打包好的流推给webrtc流媒体模块。
[0066]
如图3所示，应用gb/t28181的ps流转webrtc直播流的实时转换方法搭建的转换系统的模块组件包括ps流接收模块、rtp荷载的ps包缓存模块、媒体流缓存模块、h.264帧打包模块和url推流模块；
[0067]
ps流接收模块负责接收荷载ps流的rtp数据包。rtp荷载的ps包缓存模块负责对荷载ps流的rtp数据包解析，先查找第一个荷载着ps包头的rtp包,然后将荷载着ps包的rtp包放到ps包缓存中；并检查rtp包的sequence是否连续，如果连续，则在媒体流缓存模块中对主h.264缓存进行拆帧，如果不连续则ps缓存清空，同时清空主h.264缓存和帧缓存，对副h.264缓存的最后一个es流进行拆帧，保证播放端始终有画面。ps包解析模块负责对ps包缓存中rtp包解析,同时继续不断接受rtp包放到ps包缓存中，直到接收完一个完整的ps包,将这个完整ps包中荷载的视频数据解析出来，放到主h.264缓存和副h.264缓存中。媒体流缓存模块负责将主h.264缓存和副h.264缓存中的h.264数据(es流)进行拆帧，将拆分出的每一个完整的h.264帧放到帧缓存中。h.264帧打包模块负责将完整的h.264帧打包成webrtc。拥塞控制模块通过webrtc流媒体模块反馈transportfeedback报文，根据igcc-a算法预估出发送码率，并将发送码率给url推流模块。最后url推流模块根据拥塞模块预估的发送码率通过url地址推流给webrtc流媒体模块。
[0068]
所述的igcc-a算法为gcc算法的优化算法，优化包括：
[0069]
1)延迟抖动问题的改进，gcc算法是对包进行分组，每5ms间隔内的包为一组，通过
第i组包的第一个包的发送时间，以及这一组时间内最后收到的那个包的时间，分组计算单向传输时延。然后交由trendline滤波器就进行计算出延时变化的线性斜率。
[0070]
改进方法,因网络会使一些包到达时乱序,有的相距很近,有的相距较远，而并非按照发送时5ms间隔的分组，所以igcc-a算法对于到达时间接近的归到一个包组,只计算一个延迟变化量,而相距较远的分到不同的组，这样能避免突发抖动到来时，按原算法以包组计算单向时延变化，基于延迟的速率控制器误认为拥塞而下降带宽。
[0071]
原算法基于延迟的速率控制器由于比较敏感，发生网络抖动时带宽直接下降,所以igcc-a算法对此问题进行了优化：在检测拥塞变化后，加性增乘性减的速率控制器中不会立刻进行降低带宽，而是会观察6次来回时间，如果仍然出现过度使用状态，去降低带宽，连续降低3次，直到降低到成功接收速率0.85倍；igcc-a算法对于到达时间接近的归到一个包组,只计算一个延迟变化量,而相距较远的分到不同的组，这样能避免突发抖动到来时，按原算法以包组计算单向时延变化，基于延迟的速率控制器误认为拥塞而下降带宽，如图4所示。
[0072]
2)在gcc分别根据丢包率和延迟变化算出ti时刻的两候选发送速率as(ti)和ar(ti)后，igcc-a按照下面的方式做出决策：
[0073][0074]
其中a(ti)为ti时刻的发送码率，限制条件函数p(ti)的值代表igcc-a允许当前的拥塞算法忽略微小的延迟波动，当前会话的通话质量足够可靠时，即p(ti)》0时，igcc-a直接选择基于丢包率的速率控制器给出的速率作为当前的目标发送速率；一旦限制条件函数的值不满足要求，即p(ti)≤0时，igcc-a收回允许并按照原gcc的算法规则进行拥塞控制；
[0075]
为了让限制条件函数更灵活地适应不同的丢包率和延迟波动，我们按照如下的方式来定义限制条件函数：
[0076][0077]
其中fr(ti)和f
l
(ti)代表ti时刻的rtt和丢包率，和代表附加因素对限制条件函数的影响，同时，一旦丢包率超过3％，认为此时的直播频道的网络质量不够理想，并停止忽略微小的延迟波动，在p(ti)》0时。
[0078]
以上所述仅为本公开的优选具体实施方式，并不用于限制本公开，对于本领域的技术人员来说，本公开可以有各种更改和变化。凡在本公开的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。