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:38WebRTC中的完美协商(三)
2019-11-24 13:54:23WebRTC中的完美协商(一)
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涉及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社群具有参考价值。