本文分享了声网Agora 首席音频工匠高泽华在 RTC 2018 实时互联网大会上，以《SOLO X™：兼容 WebRTC 标准的抗丢包语音编码器》为题的演讲。主要介绍了声网推出的抗丢包语音编码器 Agora SOLO™ 的算法特点，以及第二代编解码器 Agora SOLO X™ 的新特性与测试效果。以下为演讲实录。

去年，我们在 RTC 大会上分享了自主研发的抗丢包编解码方案 Agora SOLO™ ，主要是面向抗丢包网络，解决实时通信传输 last mile 的问题。

关于Agora SOLO™

有时，大家对丢包问题会有一些误解。很多人认为随着 4G 的普及和 5G 的建设，是不是丢包问题变得不重要了？我认为并不是这样，因为在现有网络条件下，不论是 server 到 server，还是 sever 到 last mile 都存在着大量的丢包问题。

我们谈到丢包就涉及到丢包的概念，到底什么叫做丢包？其实任何没有按时到达的包都是丢包。如果把一个包的延时拉到足够大，一般来说，我们可以通过无数次重传来解决丢包问题。如果这个包没有在规定的时间到达，都算丢包。而且，丢包也不一定是网络原因导致，有时候是由于系统的调度等原因造成。

举个例子。通常，Android 系统上播放线程、解码线程和收包线程都可以不是一个线程。Android 并不是特别实时的操作系统。一旦系统比较忙的时候，就容易产生收包线程和解码线程的冲突，导致丢包产生。而这种丢包是由于系统产生的。甚至在解码时，解码器完成解码后交给播放器播放，其中的 buffer 也会导致卡顿。

丢包也与带宽限制相关。如果带宽足够大，可以通过无数次重传来实现抗丢包效果。但如果带宽很有限，就不能完全依靠无限制的重传来实现抗丢包效果。

比如说，曾经联通做过这样的事情，流量包月，但每个月的带宽只能在 128kbps，满足你对网页和音视频的基本需求。在这种服务下，如果你开一些高性能或者大码率的信源通讯的时候就会产生带宽拥塞，带宽拥塞首先导致延时增加，下一步就会产生丢包。所以，实际上带宽和丢包也相关。

由于我们声网在全球布网，非洲、东南亚、中东和印度的网络状况与中国的网络状况相差还比较远。即使在中国的网络环境下，上海和偏远地区的网络状况也是不一样的。所以，并不是以后上了 5G 就不存在丢包问题了，相反，我认为随着网络的差异化会导致丢包的问题变得越来越普遍。

More...

本文整理自声网数据平台首席架构师何丰在 RTC 2018 实时互联网大会的演讲内容。他的演讲内容主要包括，如何以数据来衡量实时通信质量，质量透明化背后的数据挑战，以及声网面向开发者免费推出的通信质量诊断分析产品“水晶球”（Agora Analytics）的应用与技术难点。以下为演讲实录。

我们是提供实时音视频服务的。我们希望让开发者们使用实时通信服务，就像使用水、电一样方便。用户的设备接入了我们的云服务后，就可以直接与全球其它国家和地区的用户进行实时的语音或视频互动。

在声网的实时通信云服务上，已经有很多种应用，比如直播与社交，像参加本次大会的 MeetMe 就是美国目前最大的约会社交平台；再比如教育，有很多教育类产品为国内学生与海外老师搭建了实时互动的教学平台；再比如游戏，此前游戏比较流行一起打怪升级，现在很多手游已经集成实时通信的功能，开始变得社交化。在前不久，我们已经开始为小天才儿童手表提供了实时语音、视频的服务，实际上也是 RTC 技术应用于 IoT 领域的一个典型案例。

一、为什么开发者需要实时通信服务的质量监控与质量透明？

More...

More...

本文是Janus 项目作者 Lorenzo Miniero撰写的， 2019 年 10 月 25 日他将来到北京 RTC 2019 大会，在「WebRTC Workshop」工作坊中分享WebRTC 服务端开发及 Janus 开发的技巧，并与听众小范围深入交流，名额有限，现在即可报名：2019.rtcexpo.org/（申请限时免费票，还可获得 Workshop 代金券~）

本文摘要：抓取WebRTC流量看起来相对简单，大多数情况下确实是这样：你只需要在其中一人的机器上安装类似tcpdump或wireshark的抓包工具，然后查看产生的文件，大多数情况会是.pcap或.pcapng文件。这些活动对于诊断连接问题或其它与WebRTC相关的问题很有用：实际上，wireshark可以自动检测出STUN，DTLS之类的标准协议，这些是WebRTC PeerConnections所关注的。

本文关键是什么？

抓取WebRTC流量的唯一问题就是，媒体内容会被加密。当检查了STUN连接或DTLS握手之后，这不是一个问题，但是当你想要查看RTP或RTCP包的时候，这将会成为一个问题，它将会被加密成SRTP和SRTCP。实际上,尽管SRTP标题没有被加密，你可以任何形式抓取流量，但是SRTP负载不是，意味着你不能查看它的内容。

大多数情况下你不需要查看内容。正如期待的那样，你依然可以查看加密RTP包的标题，也就是最常被用到的信息。不管怎样，对于RTCP并不能这样说：实际上，一条RTCP信息可能实际上包含不止一个包，并且不存在一个共享的标题。除此之外，查看RTP负载可能会有效。

这意味着抓取加密流量是可行的，但是为了诊断目的抓取无加密数据效果可能更好。不幸的是，无其它帮助下这是不可能的：实际上，WebRTC情况下浏览器经常发送加密数据，即使有一些允许你抓取无加密数据进行测试，但是你还是需要依靠其它工具来获取媒体流，才能进行这项工作。

More...

TensorFlow是目前最流行的机器学习框架之一。TensorFlow的一大优势是，它的很多库都有人积极进行维护和更新。而我最喜欢的其中一个库就是TensorFlow对象检测API。Tensorflow对象检测API可以对一张图形上的多个对象进行分类，并提供它们的具体位置。该API在将近1000个对象类上进行了预先训练，可提供各种经过预先训练的模型，让你可以在速度与准确性之间权衡取舍。

有这些模型的指引固然很好，但所有这些模型都要使用图像才能发挥作用，而这些图像则需要你自行添加到一个文件夹中。我其实很想将其与实时的WebRTC流配合到一起，通过网络实现实时的计算机视觉。由于未能找到这方面的任何例子或指南，我决定写这篇博文来介绍具体的实现方法。对于使用RTC的人，可以将本文作为一篇快速指南加以参考，了解如何使用TensorFlow来处理WebRTC流。对于使用TensorFlow的人士，则可以将本文作为一份快速简介，了解如何向自己的项目中添加WebRTC。使用WebRTC的人需要对Python比较熟悉。而使用TensorFlow的人则需要熟悉网络交互和一些JavaScript。

本文不适合作为WebRTC或TensorFlow的入门指南使用。如需这样的指南，应参考TensorFlow入门指南、WebRTC入门指南等，网上的相关介绍与指南数不胜数。

More...

在基于IP网络的多媒体通信系统(比如WebRTC)中，网络丢包对多媒体通信质量有非常严重的影响：例如造成视频的马赛克、图像模糊、帧率下降等问题，造成音频的声音失真、噪声干扰、音频中断等问题。这都会严重影响系统的通信质量，造成非常差的用户体验。

WebRTC主要采取两种手段对抗网络丢包：丢包重传(NACK)和前向纠错(FEC)。丢包重传在之前文章中有专门论述[1]，本文集中注意力于FEC。FEC是一种前向纠错技术，发送端将负载数据加上一定的冗余纠错码一起发送，接收端根据接收到的纠错码对数据进行差错检测，如果发现差错，则利用纠错码进行纠错。而ULPFEC(Uneven Level Protection FEC，直译为非均等保护前向纠错)则是WebRTC实现的FEC方案之一，本文深入学习ULPFEC的理论基础和实现细节。

More...

对于实时音视频应用来讲，媒体数据从采集到渲染，在数据流水线上依次完成一系列处理。流水线由不同的功能模块组成，彼此分工协作：数据采集模块负责从摄像头/麦克风采集音视频数据，编解码模块负责对数据进行编解码，RTP模块负责数据打包和解包。数据流水线上的数据处理速度是影响应用实时性的最重要因素。与此同时，从服务质量保证角度讲，应用需要知道数据流水线的运行状态，如视频采集模块的实时帧率、当前网络的实时速率、接收端的数据丢包率，等等。各个功能模块可以基于这些运行状态信息作相应调整，从而在质量、速度等方面优化数据流水线的运行，实现更快、更好的用户体验。</br>

More...

A curated list of awesome WebRTC modules and resources. Inspired by awesome-python.

More...

作为Google开源的技术，WebRTC并不是一个可以拿来就用并且性能很好的产品，需要工程师们对其进行较多的改善。本文主要来谈一谈WebRTC的优缺点。

WebRTC的优点：

1. 方便。对于用户来说，在WebRTC出现之前想要进行实时通信就需要安装插件和客户端，但是对于很多用户来说，插件的下载、软件的安装和更新这些操作是复杂而且容易出现问题的，现在WebRTC技术内置于浏览器中，用户不需要使用任何插件或者软件就能通过浏览器来实现实时通信。对于开发者来说，在Google将WebRTC开源之前，浏览器之间实现通信的技术是掌握在大企业手中，这项技术的开发是一个很困难的任务，现在开发者使用简单的HTML标签和JavaScript API就能够实现Web音/视频通信的功能。

2. 免费。虽然WebRTC技术已经较为成熟，其集成了最佳的音/视频引擎，十分先进的codec，但是Google对于这些技术不收取任何费用。

3. 强大的打洞能力。WebRTC技术包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿透技术，并支持代理。

WebRTC的缺点：

More...

getStats是WebRTC一个非常重要的API，用来向开发者和用户导出WebRTC运行时状态信息，包括网络数据接收和发送状态、P2P客户端媒体数据采集和渲染状态等[1]。这些信息对于监控WebRTC运行状态、排除程序错误等非常重要。<br />
本文首先描述W3C定义的getStats标准，然后展示如何在JS层调用getStats，最后深入分析WebRTC源代码中getStats的实现。全文从标准到实现，全方位透彻展示getStats的细节。<br />

一 getStats标准

getStats的标准由W3C定义，其接口很简单，但是却返回丰富的WebRTC运行时信息。其返回信息的主要内容如下[2]：<br />

1. 发送端采集统计：对应于媒体数据的产生，包括帧率，帧大小，媒体数据源的时钟频率，编解码器名称，等等。<br />
2. 发送端RTP统计：对应于媒体数据的发送，包括发送数据包数，发送字节数，往返时间RTT，等等。<br />
3. 接收端RTP统计：对应于媒体数据的接收，包括接收数据包数，接收字节数，丢弃数据包数，丢失数据包数，网络抖动jitter，等等。<br />
4. 接收端渲染统计：对应于媒体数据的渲染，包括丢弃帧数，丢失帧数，渲染帧数，渲染延迟，等等。<br />

另外还有一些杂项统计，如DataChannel度量，网络接口度量，证书统计等等。在众多信息中，有一些反映WebRTC运行状态的核心度量，包括往返时间RTT，丢包率和接收端延迟等，分别表述如下：<br />

• 往返时间RTT：表示数据在网络上传输所用的时间，一般通过RTCP 的SR/RR数据包中的相关域进行计算。该度量直接反映网络状况的好坏。<br />
• 丢包率影响接收端音视频质量，在严重的情况下可能导致声音跳变或者视频马赛克，从侧面反映网络状况的好坏。<br />
• 音视频数据到达接收端之后，要经历收包、解码、渲染等过程，该过程会带来延迟。接收端延迟是数据从采集到渲染单向延迟的重要组成部分。<br />

通过以上分析可知，getStats的返回信息包含WebRTC数据管线的各个阶段的统计信息，从数据采集、编码到发送，再到数据接收、解码和渲染。这为监控WebRTC应用的运行状态提供第一手数据。<br />

More...