众所周知，WebRTC的拥塞控制和码率估计算法采用GCC算法[1]。该算法充分考虑了网络丢包和网络延迟对码率估计的不同影响，分别基于丢包率和网络延迟进行码率估计，最后综合这另种码率得出最优值。在算法实现上，基于丢包率的码率估计在发送端进行，基于网络延迟的码率估计在接收端进行。最后在发送端计算出最优值，作用于Codec和PacedSender模块。GCC算法能够较好地基于网络实时状况估计网络带宽，为网络实时通信应用打下坚实基础[2][3][4]。

然而，随着时间推移，在实际测试中发现GCC算法逐渐显出一些弊端，比如不能适应所有网络模型，应对网络峰值能力差，等等。为此，Google官方从M55版本引进最新的拥塞控制算法Sendside-BWE，把所有码率计算模块都移到发送端进行，并采用全新的Trendline滤波器取代之前的Kalman滤波器[5]。实测表明，新的算法实现能够更好更快地进行码率估计和网络过载恢复。

本文基于WebRTC的M66版本和相关RFC，深度分析学习最新Sendside-BWE算法的实现。

2 GCC算法回顾

关于GCC算法已经有很多分析和论述[6][7]，本文只回顾其算法框架，并分析其在实际应用中存在的问题。

 

More...

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...

WebRTC 自诞生之日起, 就代表了实时通信领域的最好的技术. 不过很长时间里, 它所支持的视频编码器只有VP8, 后来随着H265/VP9为代表的下一代视频编码器的诞生, WebRTC里出现了VP9 Codec. 而当前应用最广泛的H264 却一直不受待见. 一直到Cisco 宣布旗下的H264 Codec开源为OpenH264, 并且替所有OpenH264的使用者支付了H264的专利费， 以次为契机， 在IETF的WebRTC会议中， 把H264和VP8都列入了WebRTC所必需要支持的视频编码器。 接下来， Google终于在WebRTC中增加了对H264的支持， 在PC平台(Windows和MAC), 编码器是用OpenH264, 解码器是用FFMPEG， 在iOS平台上， 编码器和解码器既可以使用OpenH264和FFMPEG, 也可以用apple的VideoToolbox所支持的硬件编解码器. 在Android平台, 可以用 OpenH264, FFMPGE, 也可以用 MediaCodec. 这个对于广大需要H264的公司来说是一大福音. 在下载的WebRTC代码中做稍许配置， 就可以使用H264了.

More...

最近实验了下如何让WebRTC支持H264编码，记录下，供有需要的人参考。

说明一下，我是在 Ubuntu Server 14.04 下编译的 WebRTC ，使用 native（C++） api 开发 WebRTC 应用。所以我的调整都是基于 native 代码。

最终的效果是浏览器可以用H264发送视频，也可以接收H264视频。

注意，WebRTC 使用 OpenH264 来做 encoder （见 h264_encoder_impl.cc），使用 ffmpeg 来做 decoder （见 h264_decoder_impl.cc ）。

代码版本
本文对应的代码是2017年2月8号的，可以使用 gclient revinfo -a来查看具体版本，如下：

More...

1. <div>
2.  
   音频输入: <select id="audioInput"></select>
3.  
   音频输出: <select id="audioOutput"></select>
4.  
   视频输入: <select id="videoInput"></select>
5.  
   <video id="video" playsinline autoplay ></video>
6.  
    
7.  
   </div>
8.  
    
9.  
   </body>
10.  

More...

More...

基于Webrtc和Janus的多人视频会议系统开发2---Janus建立连接过程的角色关系图
原创睏哥RTC 发布于2018-08-08 14:36:08 阅读数 1982 收藏
展开

本篇文章开始讲解如何开发windows和mac下的原生c++的janus客户端SDK。

项目组几个人搜编百度，谷歌，bing，一直没找到Janus的c++原生SDK的demo，只有ios,android和web的demo, 但是我们windows和Mac下都要支持原生APP的SDK接入，最后无奈之下只好自己动手丰衣足食。

根据资料参考，webrtc源码的example下有个peerconnection_client和peerconnection_server， 可以演示c++的webrtc视频p2p通话，只要这个连通了，在加上Janus协议的支持，应该就可以支持janus的C++客户端，不过开始时是对整个连通过程一头雾水，下图是正确的客户端和Janus服务器关系的正确关系，帮助初入坑的兄弟们理解：

More...

More...

More...

目录

More...