WebRTC -- SDP格式解析
2019-11-26 10:57:08WebRTC getStats详解 － 从标准、调用到实现
2019-11-24 14:00:11前言
getStats是WebRTC一个非常重要的API，用来向开发者和用户导出WebRTC运行时状态信息，包括网络数据接收和发送状态、P2P客户端媒体数据采集和渲染状态等[1]。这些信息对于监控WebRTC运行状态、排除程序错误等非常重要。<br />
本文首先描述W3C定义的getStats标准，然后展示如何在JS层调用getStats，最后深入分析WebRTC源代码中getStats的实现。全文从标准到实现，全方位透彻展示getStats的细节。<br />
一 getStats标准
getStats的标准由W3C定义，其接口很简单，但是却返回丰富的WebRTC运行时信息。其返回信息的主要内容如下[2]：<br />
- 发送端采集统计：对应于媒体数据的产生，包括帧率，帧大小，媒体数据源的时钟频率，编解码器名称，等等。<br />
- 发送端RTP统计：对应于媒体数据的发送，包括发送数据包数，发送字节数，往返时间RTT，等等。<br />
- 接收端RTP统计：对应于媒体数据的接收，包括接收数据包数，接收字节数，丢弃数据包数，丢失数据包数，网络抖动jitter，等等。<br />
- 接收端渲染统计：对应于媒体数据的渲染，包括丢弃帧数，丢失帧数，渲染帧数，渲染延迟，等等。<br />
另外还有一些杂项统计，如DataChannel度量，网络接口度量，证书统计等等。在众多信息中，有一些反映WebRTC运行状态的核心度量，包括往返时间RTT，丢包率和接收端延迟等，分别表述如下：<br />
- 往返时间RTT：表示数据在网络上传输所用的时间，一般通过RTCP 的SR/RR数据包中的相关域进行计算。该度量直接反映网络状况的好坏。<br />
- 丢包率影响接收端音视频质量，在严重的情况下可能导致声音跳变或者视频马赛克，从侧面反映网络状况的好坏。<br />
- 音视频数据到达接收端之后，要经历收包、解码、渲染等过程，该过程会带来延迟。接收端延迟是数据从采集到渲染单向延迟的重要组成部分。<br />
通过以上分析可知，getStats的返回信息包含WebRTC数据管线的各个阶段的统计信息，从数据采集、编码到发送，再到数据接收、解码和渲染。这为监控WebRTC应用的运行状态提供第一手数据。<br />
探索面部识别与WebRTC
2019-11-24 13:56:32近几年来，面部识别技术一直在智能手机创新的周围徘徊。随着苹果公司在iPhone X上推出Face ID，人们开始更多的关注面部识别技术。
我们团队向来喜欢实验和探索未来技术的潜力。所以我们与Cristiano一同利用WebRTC做一些关于面部识别的研究和探索。
在这篇文章中，我们会分享Cristiano的一些成果，他学到的东西，以及他对这种技术挑战和局限性的看法。
什么是WebRTC？
WebRTC是一个开源的网络框架，支持浏览器中的实时通信。它包括Web上高质量通信的基础构建模块，如用于语音和视频聊天应用程序的网络，音频和视频组件。
用Cristiano的话来说就是“一种可以通过浏览器调用麦克风，音频和摄像头的方法”。
Cristiano使用WebRTC，Canvas，微软Cognitive Services以及他们的Emotion API来创建了一个原型工具，该工具可以通过网络摄像头在浏览器中通过面部表情来检测情绪。
通过监控发现的TURN中的bug
2019-11-24 13:55:38
WebRTC中的完美协商（三）
2019-11-24 13:54:23但是，这并不完美！
原因有两点：
第一点：这就是为什么我这么早就对此发表博客。我提出了3个规范说明，希望这些说明可以消除对Promise.all和“stable”测试的依赖。其实归根到底是用一种与执行rollback略有不同的API，其用于以防闪退的方式设置一个新的端描述。在某种程度上它也是重启ICE的方式，且不会干扰negotiationneeded。
第二点：关键是要编写一次代码，以抽象出该状态机。一旦正确完成操作，那么我们就不必再担心这种复杂性会影响该应用程序的其余部分。可以在应用上方标明“让行端”。现在只需在对等端连接上调用方法，而无需再担心此状态机。
如果您想知道为什么WebRTC无法自动处理此问题，很大一部分原因是有些人想要一个高级API，而其他人想要一个低级API。开发组无法生成适合所有人的“一刀切”产品。具体来说，如果不借助应用程序去解决当前体系结构中的问题，需要WebRTC定义自己的信令通道方式并将其强加给每个人，而这并不能满足大家不同的需求。
好消息是，高级别的API可以跳过这一步进行编写。这篇文章会向大家说明一种编写方法。
为什么要追求完美？
WebRTC中的完美协商（一）
2019-11-24 13:53:48写在前面：如果你不必担心连接状态、闪退问题（信号冲突）、角色（你处于哪一方），就可以在实时WebRTC连接中添加和删除媒体，你会怎么做呢？不受时间和地点限制，你可以很容易地调用pc.addTrack（track，stream），并且你的连接路径只会显示在另一侧，不会有终端连接失败的风险。这是个白日梦？还有很多问题亟待解决？实际上，现在Chrome已经基本完成了协商，上述操作几乎可以运行！但是这样的操作并没有广泛应用，可能是因为“几乎”这两个字。这代表该操作有5%的时间无法工作，并且若Chrome闪退，风险太高了（无法从该操作回滚，只能运用pc.close（））。但API最初的承诺仍然有效。我们只需要一个除Firefox以外的浏览器来实现回滚，并用规范允许的方法修复一些明显的竞赛问题。
WebRTC中的完美协商（二）
2019-11-24 13:52:42这是一种有助于操作的API！
令人惊讶的是，这在两端都有效！到目前为止，我们只是以一种方式发送媒体，但是另一端可以通过调用pc.addTrack（track，stream）以相同的方式发送媒体。这里的协商也是自动进行的。在这种情况下，提供者/应答者的角色只是颠倒了。
你可以继续对你的对等连接对象进行你所需的任何更改，API将在下一次JavaScript tick时根据需要重新协商。你再也不必担心协商问题了！
如果两端在同一时间进行更改，那就另当别论了。
那么，Glare问题呢？
“Glare”是指双方同时互相发送offer，破坏了两端的状态机。他们的线路交叉缠绕在一起。就像你和朋友同时开始说话，“你听说了……吗？啊，你先说吧！”计算机都会持续这样做且永远不会停止。除非这台计算机没有神经网络。
所有操作都无法进行了，只能回到手动协商！ ——等等，让我们看看是否可以修复这个问题。
Rollback解决远程更改问题
Glare是一个应用问题，因为我们可以用多种方法解决它。例如：如果我们使用外数据通道，使所有更改始终仅来自一端，则可以完全避免Glare问题。但我们使用的这个API很难缠，但我们距离解决问题只有一步之遥了。因此，我们使用Rollback来节省时间，旨在达成完美的协商。
礼貌让行
简而言之，我们将使其中一端“礼让”一些，对另一端说“对不起，您先请！”也就是说，其中一端会拒绝收到的offer。我们很幸运，因为这是“rollback”的作用：
涉及WebRTC，React以及Redux的文件传输demo
2019-11-24 13:51:30
人类一直以来都在努力寻找与别人沟通的新方式，但即使我们不断获得进展，像共享文件这种至关重要的事情仍然非常繁琐。我们总是需要将文件上传到服务器上，然后再发回给我们以备后用。所以我们需要面对现实，文件传输并不像发送消息给对方那样简单，总会涉及到一些其他方面的问题。但是，由于WebRTC数据通道所提供的能力，这种情况正在发生变化。在本篇文章中，我希望通过一个简单的点对点连接来建立聊天以及建立基本的文件传输，为你提供一个更清晰的WebRTC数据通道工作方式。
断点：WebRTC SFU负载测试(一)
2019-11-24 13:50:19如果你允许多人加入WebRTC通话，你可能会以SFU结束。计划如何分配容量比较困难-通常会进行估计，SFU应该放在哪里，它们将会消耗多少带宽，你需要何种服务器。
为了帮助网络架构和WebRTC工程师作出决定，Alex博士和他的CoSMo Softwae团队将负载测试元件放在一起来测量负载和视频质量。他们公布了所有主流的开源WebRTC SFU的测试结果。这个元件基于KITE并且在webrtc.org上用来显示互通状态。CoSMo团队还开发了一个基于机器学习的视频质量评估框架来优化实时交流。
首先注意：问哪种SFU是最好的就相当于问哪种汽车是最好的。如果你只要求速度快，那你应该买F1赛车，但是它不能帮助你送孩子上学。供应商从来不会对这些测试感兴趣因为它将它们的功能仅仅总结成一些性能指标。这些指标可能在它们的测试中不起主要作用，并且也不是判别产品好坏的主要标准。对于WebRTC SFU,仅仅因为SFU可以负载许多流，但是可能还有别的限制条件，用户行为，花费优化等原因使得他们不能这样做。负载测试同样不会深究用户体验，开发难度，或其它对服务的成功有帮助的部分。
当建立花费模型时，有很多情况我本人都想获得数据。Alex和他的团队已经做了很多深度工作，这是WebRTC开源生态系统逐渐成熟的一个好的象征。这个测试并不完美，但是我相信它会对WebRTC社群具有参考价值。
