webrtc

这里记录每周值得分享的科技内容，周五发布。 本杂志开源（GitHub: ruanyf/weekly ），欢迎提交 issue，投稿或推荐你的项目。 周刊讨论区的帖子 《谁在招人？》 ，提供大量就业信息，欢迎访问或发布工作/实习岗位。 封面图 澳门去年11月举办龙马巡游，该大型机械装置为中法团队合作打造，上身为龙，下身为马，身体各部分都能动，还能喷火。（出处： Instagram ） 本周话题：保护你的 DNA，不要泄漏 上周，美国佛罗里达州通过了 《DNA 隐私法》 ，成为美国第一个对 DNA 立法的州。它明文规定 DNA 属于个人隐私，保险公司不得获取 DNA 测试的结果。 为什么 DNA 不能让保险公司知道？ 因为 DNA 包含了一个人所有的遗传信息，你有什么基因缺陷，一查 DNA 都能知道。保险公司拿到你的 DNA 以后，就能识别你可能会得哪些疾病，于是相应调整费率，或拒绝你投保人寿险和医疗险。 DNA 不仅对保险公司有用，对就业和招生也有用，可以用来找出基因上最合适的人选。所以，DNA 里面的个人信息可能不利于你，要注意保护，防止泄漏。 DNA 测序已经是一项常规技术了，普通实验室都能做，毫无难度。现在，新生儿出生前，医院都会建议孕妇做一下产前 DNA 检查，防止遗传病。2018年，湖南一个孕妇 起诉华大基因公司 ，原因就是该公司的 DNA 检查一切正常

一、WebRTC协议与SIP协议互通的需求来源 目前在国内需要WebRTC协议与SIP协议互通的场景主要集中在应用程序（App/Web）对接企业呼叫中心系统客服坐席、音视频会议对接PSTN/SIP音视频通话、企业内部App移动工作台（智能办公电话）、CRM系统集成电话呼叫功能、智能硬件（如：智能门禁设备、电梯救援设备、智能陪伴机器人）对接PSTN通话等落点电话场景。 详情可查看： www.webrtc2sip.com 二、协议互通的技术方案 SIP协议与RTC协议是分属两个音频编解码协议，WebRTC使用 JSEP 协议建立会话， SIP 协议是 IMS 网络广泛使用的信令协议，要实现webRTC协议和SIP协议互通，要从信令层和媒体层进行处理。以下为WebRTC和SIP协议互通的技术架构图。 三、影响通话质量的因素 1、语音通话网络传输设施。众所周知，IP侧的语音通话非常看网络环境。目前IP侧的语音通话有两种传输方案，公网传输和全球数据节点就近接入。公网传输属于尽力而为的机制，易丢包出现卡顿和延时情况，特别是国内与海外的公网传输更加明显。全球数据节点就近接入需要在全球建立数据节点，系统自动根据IP判定就近接入，专线传输时延低，稳定性高。对于公司内部会议、客服回访场景尤为重要。这个方案唯一的问题就是在全球建立数据节点成本极高。中小微企业自行建设性价比不高。 2

7月16日，亚太内容分发大会上，阿里云高级产品运营专家俞翔受邀出席，并分享了基于CDN网络构建超低延时直播的场景实践。以下为演讲原文。 近几年，直播带货已经逐渐走进大众视野。在今年上半年受疫情原因影响，直播营销市场被加速催熟，这倒逼着企业探索线上业务。传统高度依赖线下场景的行业也纷纷通过直播进行自救。“直播+”成为了趋势，不少商家利用直播平台与广大消费者互动，创造了新的服务与经营模式。 在这个过程中，无论是旅游、餐饮或者传统消费业，各行各业都会把直播作为新的营销手段触达最后的消费者。然而，与原来的秀场直播不同，电商直播过程中会面临更多挑战，如何把直播互动的环节做好，将观众和主播或者后台的管理人员、运营人员串联在一起，至关重要。 延迟让直播互动效果大打折扣 从最初的秀场直播开始到今天为止，整个直播的链路基本上已经实现标准化。主播在线下无论使用PC还是移动手机，都是在本地通过客户端实现采集编码，并通过推流的形式到直播中心，再经过转码等媒体处理，通过云厂商CDN网络，再经过RTMP实时的方案或者用FLV、HLS的方案，最终传递到观众侧。 这个流程是单向的过程，直接从主播到观众。过程中的互动比如评论，是在音视频流以外的旁路实现的。 很多观众希望跟主播有进一步的互动，比如音视频层面互动，延时就成了关键的制约因素。 我们现在推流都是用到RTMP，拉流观看有用到RTMP、HLS或FLV

来源： oschina 链接： https://my.oschina.net/u/4303372/blog/4349456

前面的博客里说过最近几个月我从传统语音（语音通信）切到了智能语音（语音识别）。刚开始是学语音识别领域的基础知识，学了后把自己学到的写了PPT给组内同学做了presentation（ 语音识别传统方法(GMM+HMM+NGRAM)概述 ）。一段时间后老板就布置了具体任务：在我们公司自己的ARM芯片上基于kaldi搭建一个在线语音识别系统，三个人花三个月左右的时间完成。由于我们都是语音识别领域的小白，要求可以低些，就用传统的GMM-HMM来实现。说实话接到这个任务我们心里是有点没底的，不知道能不能按时完成，毕竟我们对语音识别不熟，对kaldi不熟。既然任务下达了，硬着头皮也要上，并尽最大努力完成。我本能的先在网上用百度/google搜了搜，看有没有一些经验可供参考，好让我们少走弯路。遗憾的是没搜到有价值的东西。没办法，我们只能根据自己以前的经验摸索着前进。最终我们按计划花了不到三个月的时间完成了嵌入式平台上在线语音识别系统的搭建。虽然只是demo，但是为后面真正做商用的产品打下了良好的基础，累积了不少的经验。今天我就把我们怎么做的分享出来，给也想做类似产品的朋友做个参考。 既然作为一个项目来做，就要有计划，分几个阶段完成这个项目。我在学习语音识别基础知识时对kaldi有一个简单的了解（在做语音识别前就已知kaldi的大名，没办法这几年人工智能（AI）太热了

webrtc的自动增益模块在agc_legacy_c工程下： analog_agc.c analog_agc.h digital_agc.c digital_agc.h gain_control.h 主要函数包括： WebRtcAgc_AddMic WebRtcAgc_AddFarend WebRtcAgc_GetAddFarendError WebRtcAgc_VirtualMic WebRtcAgc_UpdateAgcThresholds WebRtcAgc_SaturationCtrl WebRtcAgc_ZeroCtrl WebRtcAgc_SpeakerInactiveCtrl WebRtcAgc_ExpCurve WebRtcAgc_ProcessAnalog WebRtcAgc_Process WebRtcAgc_set_config WebRtcAgc_get_config WebRtcAgc_Create WebRtcAgc_Free WebRtcAgc_Init WebRtcAgc_CalculateGainTable WebRtcAgc_InitDigital WebRtcAgc_AddFarendToDigital WebRtcAgc_ProcessDigital WebRtcAgc_InitVad WebRtcAgc_ProcessVad 核心函数介绍

一、回声的产生 无论是实际环境还是语音通话中，回声总是存在的。但是需要满足如下两个条件，我们才能感觉到回声的存在： 1、回波通路延时足够长 回波通路延时 效果 小于30ms 不易察觉 小于50ms 有感知 大于50ms 影响严重，需要干预 2、回波信号能量足够强 也就是说，返回的回波信号必须足够强到，能让用户能够听见。 在实时音频会议通话中，产生回声的主要来源有两点：电学回声、声学回声。回波消除的算法也有两种：EC、AEC。一般EC是电学回波消除，部署在PSTN网关或接入设备上。AEC指的是声学回波消除，用于终端设备。 二、回声的种类及抑制 1、电学回声 目前大家可能很少听说电学回声，过去使用固定座机电话时，会有电学回声问题。它的产生原理如下： 在几乎所有的通信网络中，信号的传递都是采用4线传输，也就是在接收和发送两个方向上，各使用两条线传输信号，其中一条是参考地，另一条是信号线。但是电话用户使用的话机都是通过2线传输的方式接入本地交换机，一条线是参考地，另一条信号线上同时传输收发双向的信号。所以需要在本地交换机中采用2/4线转换(hybrid)实现这两种传输方式之间的转换。 由于实际使用的2/4线变换器中混合线圈不可能做到理想状况，总是存在一定的阻抗不匹配，不能做到将发送端和接收端完全隔离，所以从4线一侧接收的信号总有一部分没有完全转换到2线一侧，部分泄露到了4线一侧的发送端