记录下今天编译WebRTC 安卓Native code遇到的一个问题。相关错误提示如下： [crayon-616e7f49476d1344574296/] 执行gclient sync命令后过一会儿报Failed to download错误，我用浏览器或者wget命令去下载一点问题都没。之前都没遇到过这问题。谷歌搜了下，发现有人遇到过类似问题，还都是国人，问题出在代理上，在有些代理环境下，gclient sync下的某些命令连接会失败。以前用SS（IP封得太厉害放弃了现在）就没遇到过，现在用的VPN走全局就遇到了，…
前面文章WebRTC研究：包组时间差计算-InterArrival讲到了相关包组时间差计算，输出包组发送时间差，到达时间差等参数。本篇文章主要介绍下这些参数在判断网络拥塞情况方面的应用。 到达时间模型 在WebRTC研究：包组时间差计算-InterArrival说到了到达时间模型，主要包含几个包组时间差计算的概念： 到达时间差：\(t_{i} - t_{i-1}\) 发送时间差：\(T_{i} - T_{i-1}\) 时延变化：\(d_{i} = t_{i} - t_{i-1} - (T_{i} - T_{i-1}…
视频编解码分为硬件加速以及非硬件加速。硬件加速是指通过显卡，FPGA等硬件进行视频编解码，由于硬件有专门优化，所以性能高，能耗低，非硬件加速编解码是指通过CPU进行视频编解码，性能就没那么高（虽然有相关CPU指令优化），由于视频编解码计算量很大，所以能耗也很高。在PC平台上主流的硬件加速编解码有Intel集成显卡，Nvidia显卡。Nvidia平台的编解码用的比较多，网上资料也多，接口也很简单，但是相对成本会高些。Intel集显平台视频编解码成本就低很多了，只要是最近几年带集显的CPU基本都支持硬件加速编解码，但是…
在新版GCC（Google Congestion Control）也就是Sendside BWE中，包含两种拥塞控制模型。一种是基于丢包的，一种是基于时延的，全部在发送端计算。Sendside BWE最后综合这两种估计值取小的那个作为目标码率。 基于时延的拥塞控制算法主要由四部分组成：预处理（pre-filtering）, 到达时间滤波器（arrival-time filter）, 过载检测器（over-use detector），码率控制器（and a rate controller）。本文主要介绍其中的到达时间…
在WebRTC GCC(Google Congestion Control)中，有一个叫做AlrDetector（应用受限区域探测器，Application limited region detector）的模块。该模块利用某段时间值，以及这段时间发送的字节数判断当前输出网络流量是否受限。这些限制主要跟应用程序本身输出网络流量的能力有关，例如编码器性能，不能编码出设置的目标码率。下面举个简单例子说明下。 假设我们经过带宽预测后，获取到一个目标码流target_bitrate_bps，此时我们程序需要按照该码率大小进…
根据W3C的WebRTC 1.0: Real-time Communication Between Browsers规范，WebRTC的源码中定义了两套主要的C++接口，分别是MediaStream与PeerConnection相关的API。本篇文章主要介绍下MediaStream API中一些概念，方便理解内部代码如何处理。 MediaStream 相关API定义在源码api\media_stream_interface.h中。里面主要涉及这4个概念：source，sink，mediatrack，mediastr…
使用RTP协议封装数据时，我们可以通过RTP报头的序列号连续性判断是否丢包。但由于RTP报头序列号只有两字节表示，值范围[0,65535]，存在回绕问题（参考之前文章：WebRTC研究：RTP中的序列号以及时间戳比较，建议先阅读一遍此文章）。所以判断序列号连续性时得考虑回绕问题。下面我们就结合WebRTC这相关源码，讲下如何有效地根据序列号进行丢包判断。 首先看下这块代码，代码位于jitter_buffer.cc中： [crayon-616e7f494c2e8507433385/] IsNewerSequenceN…
近期评论
robotcop on 流媒体网络性能指标——抖动好厉害