WebRTC简介（一）

Posted 2023-04-30

参考技术A WebRTC（Web Real-Time Communication）也被称为网络实时通信，是由 Google、Mozilla 和其他公司推动的一个开源项目，它通过 javascript API 实现无插件的实时通信，以及在不需要中介的情况下在浏览器之间交换任意数据。

WebRTC的优点：

WebRTC技术的诞生，有一个很重要的原因在于，在浏览器实现实时音视频通话，需要依赖相关插件或程序，而插件安全漏洞问题则更为关键。浏览器开发人员无法控制这些插件以及更新，因此插件带来的安全风险也相对较大。

在WebRTC诞生之前，开发实时音视频应用的成本是非常高，需要考虑的技术问题很多，如音视频的编解码，数据传输延时、丢包、网络抖动、回音处理和消除等，如果要兼容浏览器端的实时音视频通信，还需要额外安装插件。当然，可以考虑使用第三方成熟技术，比如当时世界顶级的互联网音视频方案GIPS(Global IP Solutions)，支付相应的费用就行。很多知名的应用或者软件服务商也都在用GIPS，如Yahoo，AOL，IBM，SKYPE，QQ等。

WebRTC项目的愿景：实时通信web化，让WebRTC成为互联网音视频实时通信的规范，让开发者基于此规范快速开发出安全、可靠的应用。未来的音视频实时通信，必定是现代化生产活动中极其重要的板块。以下是WebRTC的部分应用场景：

两个不同网络环境的（具备摄像头/麦克风多媒体设备的）客户端（浏览器或APP），要实现点对点的实时音视频对话，难点在哪里？

要实现P2P通信，首先需要了解彼此是否都支持相同的媒体能力，WebRTC默认使用V8编解码器，如果要连接的对方不支持V8解码，如果没有媒体协商过程。那么即使连接成功，把视频数据发给对方，对方也无法播放
比如：Peer-A端可支持VP8、H264多种编码格式，而Peer-B端支持VP9、H264，要保证二端都正确的编解码，最简单的办法就是取它们的交集H264
有一个专门的协议 ，称为Session Description Protocol (SDP)，可用于描述上述这类信息，在WebRTC中，参与视频通讯的双方必须先交换SDP信息，这样双方才能知根知底，而交换SDP的过程，也称为"媒体协商"。

交换数据会通过一个中间服务来完成，在这里，我们称之为信令服务器
在建立P2P连接时，需要交换的信息有：

最理想的场景

然而，在大多数情况下，两个对等端都是各自处于某个局域网之中，相互之间隔着NAT与防火墙

NAT(Network Address Translation)即为网路地址转换协议

局域网-->公网

公网-->局域网

可以借助STUN服务器.，穿越NAT

在NAT四种主要类型中有三种是可以使用STUN穿透：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT。但大型公司网络中经常采用的对称型 NAT（又称为双向NAT）则不能使用STUN穿透，这类路由器会透过 NAT 布署所谓的「Symmetric NAT」限制。也就是说，路由器只会接受之前连线过的节点所建立的连线。

可以点对点连接的情况与需要中转的情况（数据来源于Google）

不过在国内大部分局域网无法穿越。

拓展 - Webrtc 的回声抵消(aecaecm)算法简介

webrtc 的回声抵消(aec、aecm)算法简介

 

     webrtc 的回声抵消(aec、aecm)算法主要包括以下几个重要模块：1.回声时延估计 2.NLMS(归一化最小均方自适应算法) 3.NLP（非线性滤波） 4.CNG(舒适噪声产生），一般经典aec算法还应包括双端检测(DT)。考虑到webrtc使用的NLMS、NLP和CNG都属于经典算法范畴，故只做简略介绍，本文重点介绍webrtc的回声时延估计算法,这也是webrtc回声抵消算法区别一般算法(如视频会议中的算法)比较有特色的地方。

 

1) 回声时延估计

     回声延时长短对回声抵消器的性能有比较大的影响(此处不考虑pc上的线程同步的问题)，过长的滤波器抽头也无法实际应用，因此时延估计算法就显得比较重要了。常用且容易想到的估计算法是基于相关的时延估计算法（学过通信原理的应该不会陌生），另外相关算法在语音编码中也得到广泛的应用，如 amr系列，G.729系列 ，G.718等编码器。在语音信号自相关求基音周期时，由于编码器一般按帧处理，帧长度一般是10或20ms，在该时延范围内搜索基音周期运算量较小，然而对于回声抵消的应用场合，延时搜索范围比较大，带来很高的运算复杂度。在手持终端设备上，我们需要考虑移动环境的变化对算法性能的影响，比如时延是否随机变化，反射路径线性还是非线性，以及运算量(电池)是否符合要求，则更为复杂。

 

     回到webrtc的回声时延估计，它采用的是gips首席科学家Bastiaan的算法。下面介绍一下该算法的主要思想：

设1表示有说话音，0表示无说话音(静音或者很弱的声音)，参考端(远端)信号x(t)和接收端(近端)信号y(t)可能的组合方式有以下几种：(0,0),(0,1),(1,0),(1,1),

 (0,0)表示远端和近端都是比较弱的声音，(1,1)表示远端和近端都是比较强的声音，webrt的c代码默认其它两种情况是不可能发生的。设在时间间隔p上，即p=1,2,...,P,  频带q，q=1,2,...,Q上，输入信号x加窗(如汉宁窗)后的功率谱用Xw(p,q)来表示，对每个频带中的功率谱设定一个门限Xw(p,q)_threshold,

如果 Xw(p,q)  >= Xw(p,q)_threshold  ,   则Xw(p,q) =1；

如果 Xw(p,q) <    Xw(p,q)_threshold  ,   则Xw(p,q) =0；

同理，对于信号y(t),加窗信号功率谱Yw(p,q)和门限Yw(p,q)_threshold，

如果 Yw(p,q) >= Yw(p,q)_threshold   ,   则Yw(p,q) =1；

如果 Yw(p,q) < Yw(p,q)_threshold ,        则Yw(p,q) =0；

考虑到实际处理的方便，在webrtc的c代码中，将经过fft变换后的频域功率谱分为32个子带，这样每个特定子带 Xw(p,q)的值可以用1个比特来表示，总共需要32个比特，只用一个32位数据类型就可以表示了。

webrtc对参考信号定义了75个32位binary_far_history的数组存放历史远端参考信号，定义了16个32位binary_near_history的数组存放历史近端参考信号，最近的值都放在下标为0的数组中，使用binary_near_history[15]的32位bit与binary_far_history数组中75个32位bit分别按位异或，得到75个32位比特数据，32位bit的物理意义是近似地使用功率谱来统计两帧信号的相关性。统计32位结果中的1的个数存于bit_counts中，接下来用对bit_counts进行平滑防止延时突变，得到mean_bit_count,可以看出  mean_bit_count 越小，则表明近端数据与该帧的远端数据越吻合，两者的时延越接近所需要的延时数值，用value_best_candidate表示。剩下的工作是对边界数值进行保护，如果value_best_candidate接近最差延时(预设)，则表明数值不可靠，这时不更新延时数据；如果数据可靠，则进一步使用一阶markvo模型，比照上一次时延数据确定本次最终的更新时延last_delay.

 Bastiaan的专利本身要比现有的c代码实现更为复杂，比如在异或的时候(0,0),(0,1),(1,0),(1,1)四种组合可以附加代价函数，而c代码相当于默认给(0,0),(1,1)附加权值为1，给(0,1),(1,0)附加权值为0；

 另外c代码算法是按帧顺序依次对远端和近端数组异或，实际应用时也可以每隔1帧或2帧做异或，这样可以扩大搜索范围。

 总的来说webrtc的时延估计算法复杂度比求相关大大简化，尤其适用于移动终端等对运算量比较敏感的场合进行回声消除。针对实际应用场合，算法还有提升的空间。

 

 2) NLMS(归一化最小均方自适应算法

      LMS/NLMS/AP/RLS等都是经典的自适应滤波算法，此处只对webrtc中使用的NLMS算法做简略介绍。

      设远端信号为x(n),近段信号为d(n),W(n),则误差信号e(n)=d(n)-w‘(n)x(n)  (此处‘表示转秩），NLMS对滤波器的系数更新使用变步长方法，即步长u=u0/(gamma+x‘(n)*x(n));其中u0为更新步长因子，gamma是稳定因子，则滤波器系数更新方程为 W(n+1)=W(n)+u*e(n)*x(n);  NLMS比传统LMS算法复杂度略高，但收敛速度明显加快。LMS/NLMS性能差于AP和RLS算法。

     另外值得一提的是webrtc使用了分段块频域自适应滤波(PBFDAF)算法，这也是自适应滤波器的常用算法。

     自适应滤波的更多资料可以参考simon haykin 的《自适应滤波器原理》。

 

 

 3) NLP（非线性滤波）

     webrtc采用了维纳滤波器。此处只给出传递函数的表达式，设估计的语音信号的功率谱为Ps(w)，噪声信号的功率谱为Pn(w)，则滤波器的传递函数为H(w)=Ps(w)/(Ps(w)+Pn(w))。

 

 4)CNG(舒适噪声产生）

    webrtc采用的舒适噪声生成器比较简单，首先生成在[0 ,1 ]上均匀分布的随机噪声矩阵，再用噪声的功率谱开方后去调制噪声的幅度。

 

总的说来，webrtc的aec算法简单、实用、易于商业化，另一方面猜测c代码还有所保留。

 

由于工作需要，最近一直在研究WebRTC里的AEC算法。根据源码里面的fullaec.m文件，

总体来说，我认为该AEC算法是属于分段快频域自适应滤波算法，Partioned block frequeney domain adaPtive filter(PBFDAF)。具体可以参考Paez Borrallo J M and Otero M G

使用该AEC算法要注意两点：

1）延时要小，因为算法默认滤波器长度是分为12块，每块64点，按照8000采样率，也就是12*8ms=96ms的数据，而且超过这个长度是处理不了的。

2）延时抖动要小，因为算法是默认10块也计算一次参考数据的位置（即滤波器能量最大的那一块），所以如果抖动很大的话找参考数据时不准确的，这样回声就消除不掉了。