rtmp和声学回声消除调研

来源 http://www.qttaudio.com/rtmpandaec.html

一、应用场景

低延时应用场景包括：
  .  互动式直播：譬如2013年大行其道的美女主播，游戏直播等等
     各种主播，流媒体分发给用户观看。用户可以文字聊天和主播互动。
  .  视频会议：我们要是有同事出差在外地，就用视频会议开内部会议。
     其实会议1秒延时无所谓，因为人家讲完话后，其他人需要思考，
     思考的延时也会在1秒左右。当然如果用视频会议吵架就不行。
  .  其他：监控，直播也有些地方需要对延迟有要求，
     互联网上RTMP协议的延迟基本上能够满足要求。

二、RTMP和延时

1. RTMP的特点如下：

1) Adobe支持得很好：
   RTMP实际上是现在编码器输出的工业标准协议，基本上所有的编码器（摄像头之类）都支持RTMP输出。
   原因在于PC市场巨大，PC主要是Windows，Windows的浏览器基本上都支持flash，
   Flash又支持RTMP支持得非常好。
2) 适合长时间播放：
   因为RTMP支持的很完善，所以能做到flash播放RTMP流长时间不断流，
   当时测试是100万秒，即10天多可以连续播放。
   对于商用流媒体应用，客户端的稳定性当然也是必须的，否则最终用户看不了还怎么玩？
   我就知道有个教育客户，最初使用播放器播放http流，需要播放不同的文件，结果就总出问题，
   如果换成服务器端将不同的文件转换成RTMP流，客户端就可以一直播放；
   该客户走RTMP方案后，经过CDN分发，没听说客户端出问题了。
3）延迟较低：
   比起YY的那种UDP私有协议，RTMP算延迟大的（延迟在1-3秒），

采用UDP自己开发一套私有协议，可以大幅度减少延迟，缺点会有丢包，而且发送端包的顺序，到接收端会有乱码，需要自己实现一套排序机制，进行正确排序。
   比起HTTP流的延时（一般在10秒以上）RTMP算低延时。
   一般的直播应用，只要不是电话类对话的那种要求，RTMP延迟是可以接受的。
   在一般的视频会议应用中，RTMP延时也能接受，原因是别人在说话的时候我们一般在听，
   实际上1秒延时没有关系，我们也要思考（话说有些人的CPU处理速度还没有这么快）。
4) 有累积延迟：
   技术一定要知道弱点，RTMP有个弱点就是累积误差，原因是RTMP基于TCP不会丢包。
   所以当网络状态差时，服务器会将包缓存起来，导致累积的延迟；
   待网络状况好了，就一起发给客户端。
   这个的对策就是，当客户端的缓冲区很大，就断开重连。

2. RTMP延迟的测量

如何测量延时，是个很难的问题，
不过有个行之有效的方法，就是用手机的秒表，可以比较精确的对比延时。（网上说的方法，觉得不靠谱）
我是目前根据分段统计时间，Speex编码阶段耗时平均10ms，解码平均11ms，播放端最大80ms，播放端的播放队列目前buffer大小是80ms的数据流，4帧。服务器端大概有1-3s延时。这一块大概数据RTMP协议部分（包括Red5服务器）的延时。

延时测量方面，开始设想的是在发送数据的第二字节，加上一个当前time，传到播放端后进行解析，拿到time再和本地time比较时间差,发现让两台设备统一时间到ms，没有找到设置途径，时统问题。
经过测量发现，在网络状况良好时：
  . RTMP延时可以做到0.8秒左右。
  . 多级边缘节点不会影响延迟（和SRS同源的某CDN的边缘服务器可以做到）
  . Nginx-Rtmp延迟有点大，估计是缓存的处理，多进程通信导致？
  . GOP是个硬指标，不过SRS可以关闭GOP的cache来避免这个影响.
  . 服务器性能太低，也会导致延迟变大，服务器来不及发送数据。
  . 客户端的缓冲区长度也影响延迟。
   譬如flash客户端的NetStream.bufferTime设置为10秒，那么延迟至少10秒以上。

3. GOP-Cache

什么是GOP？就是视频流中两个I帧的时间距离。
GOP有什么影响？
Flash（解码器）只有拿到GOP才能开始解码播放。
也就是说，服务器一般先给一个I帧给Flash。
可惜问题来了，假设GOP是10秒，也就是每隔10秒才有关键帧，
如果用户在第5秒时开始播放，会怎么样？
第一种方案：等待下一个I帧，
也就是说，再等5秒才开始给客户端数据。
这样延迟就很低了，总是实时的流。
问题是：等待的这5秒，会黑屏，现象就是播放器卡在那里，什么也没有，
有些用户可能以为死掉了，就会刷新页面。
总之，某些客户会认为等待关键帧是个不可饶恕的错误，延时有什么关系？
我就希望能快速启动和播放视频，最好打开就能放！

第二种方案：马上开始放，
放什么呢？
你肯定知道了，放前一个I帧。
也就是说，服务器需要总是cache一个gop，
这样客户端上来就从前一个I帧开始播放，就可以快速启动了。
问题是：延迟自然就大了。

有没有好的方案？
有！至少有两种：
编码器调低GOP，譬如0.5秒一个GOP，这样延迟也很低，也不用等待。
坏处是编码器压缩率会降低，图像质量没有那么好。

4. 累积延迟

除了GOP-Cache，还有一个有关系，就是累积延迟。
服务器可以配置直播队列的长度，服务器会将数据放在直播队列中，
如果超过这个长度就清空到最后一个I帧：


当然这个不能配置太小，
譬如GOP是1秒，queue_length是1秒，这样会导致有1秒数据就清空，会导致跳跃。


有更好的方法？有的。
延迟基本上就等于客户端的缓冲区长度，因为延迟大多由于网络带宽低，
服务器缓存后一起发给客户端，现象就是客户端的缓冲区变大了，
譬如NetStream.BufferLength=5秒，那么说明缓冲区中至少有5秒数据。

处理累积延迟的最好方法，是客户端检测到缓冲区有很多数据了，如果可以的话，就重连服务器。

积累延时这个需要测试后调整。

本人实际测量，先将red5.property修改send_buffer，receive_buffer

数据头加上时间码,测量后传输层延时几乎为0.

三、声学回声消除

Speex 简介

Speex 语音是一个开源、免费软件专利的自由音频压缩格式的语音设计。该项目旨在降低Speex语音处理的免费性，来替代昂贵的专有语音编码及应用进入壁垒。此外，Speex 可适应互联网的应用，并提供有用的功能。

Speex 是GNU工程的一部分，是根据经修订的BSD许可证发布的。

技术实现：

Speex 是基于CELP（码激励线性预测编码）的，旨在将语音压缩比特率降到从2到44kbps。

功能：

窄带（8kHz），宽带（16kHz）和超宽带（32kHz）在同一个码流压缩。

强度立体声编码

数据包丢失隐藏

可变比特率（VBR）

语音活动检测（VAD）

间断变速器（DTX）

定点模式

声学回声消除（AEC）

噪音抑制（NOISE）

Speex本身自带了一些回声消除算法接口。大概实现思路，

1.是先取得当前扬声器的声音player。

2.是从Mic采集声音recorder。

3.是进行回音消除，得到OutBuffer。消除回声的buffer发给接收端。

目前问题是扬声器播放端buffer是一个queue结构，采集端数据存储也是一个queue结构，现在分别在两个线程中维持着，如何能够同步的获取player和recorder的buffer是一个难题。因为稍稍有些不同步，声学回声消除器中的自适应滤波器就会发散，不但消除不了回声，还会破坏原始采集到的声音。

Speex 1.2

speex的窄带编码算法是基于 8k 16bit 单声道,每帧数据160个采样
speex内部将160个采样点,分成了4个子帧,每个子帧40个(…)

计算8000 frequency 下的 framesize 160个采样点，filter_length = 160*8;

 

 

Framesize 采样的帧长一般是80,160，320

Filter 回音消除的尾长 一般是80*10,160*10,320*10

这些需要实际验证。

SpeexEchoState*echo_state = speex_echo_state_init(frame_size, filter_length);

frame_size 的取值最好是一个编码的frame大小， 在低带宽条件下，一般延迟20ms，而大小为160
filter_length,最好是房间内反射时间的1/3
如: 一个房间的反射时延为300ms
    那么这个filter_length就最好是100ms(这个长度又被称为tail length).