剑痴乎

  • 首页
  • 文章分类
    • 音视频
    • WebRTC
    • 编程之美
    • Linux
    • Windows
    • 生活点滴
    • 校园生活
  • 参考
    • API参考
    • 实用工具
    • 测试音视频
    • 文档
  • 留言板
  • 关于
WebRTC
WebRTC

WebRTC安卓Native code编译下载失败问题

记录下今天编译WebRTC 安卓Native code遇到的一个问题。相关错误提示如下: [crayon-628f6289b3500375576183/] 执行gclient sync命令后过一会儿报Failed to download错误,我用浏览器或者wget命令去下载一点问题都没。之前都没遇到过这问题。谷歌搜了下,发现有人遇到过类似问题,还都是国人,问题出在代理上,在有些代理环境下,gclient sync下的某些命令连接会失败。以前用SS(IP封得太厉害放弃了现在)就没遇到过,现在用的VPN走全局就遇到了,…

2020年3月23日 0条评论 973点热度 0人点赞 Jeff 阅读全文
WebRTC

WebRTC研究:Trendline滤波器-TrendlineEstimator

前面文章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}…

2019年11月29日 19条评论 2560点热度 7人点赞 Jeff 阅读全文
WebRTC

WebRTC研究:包组时间差计算-InterArrival

在新版GCC(Google Congestion Control)也就是Sendside BWE中,包含两种拥塞控制模型。一种是基于丢包的,一种是基于时延的,全部在发送端计算。Sendside BWE最后综合这两种估计值取小的那个作为目标码率。 基于时延的拥塞控制算法主要由四部分组成:预处理(pre-filtering), 到达时间滤波器(arrival-time filter), 过载检测器(over-use detector),码率控制器(and a rate controller)。本文主要介绍其中的到达时间…

2019年11月12日 21条评论 3174点热度 5人点赞 Jeff 阅读全文
WebRTC

WebRTC研究:应用受限区域探测器-AlrDetector

在WebRTC GCC(Google Congestion Control)中,有一个叫做AlrDetector(应用受限区域探测器,Application limited region detector)的模块。该模块利用某段时间值,以及这段时间发送的字节数判断当前输出网络流量是否受限。这些限制主要跟应用程序本身输出网络流量的能力有关,例如编码器性能,不能编码出设置的目标码率。下面举个简单例子说明下。 假设我们经过带宽预测后,获取到一个目标码流target_bitrate_bps,此时我们程序需要按照该码率大小进…

2019年11月4日 8条评论 1837点热度 4人点赞 Jeff 阅读全文
WebRTC

WebRTC研究:MediaStream概念以及定义

根据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…

2019年10月22日 1条评论 1240点热度 5人点赞 Jeff 阅读全文
WebRTC

WebRTC研究:丢包判断

使用RTP协议封装数据时,我们可以通过RTP报头的序列号连续性判断是否丢包。但由于RTP报头序列号只有两字节表示,值范围[0,65535],存在回绕问题(参考之前文章:WebRTC研究:RTP中的序列号以及时间戳比较,建议先阅读一遍此文章)。所以判断序列号连续性时得考虑回绕问题。下面我们就结合WebRTC这相关源码,讲下如何有效地根据序列号进行丢包判断。 首先看下这块代码,代码位于jitter_buffer.cc中: [crayon-628f6289bb972806991797/] IsNewerSequenceN…

2019年9月2日 3条评论 1174点热度 6人点赞 Jeff 阅读全文
WebRTC

WebRTC研究:RTP中的序列号以及时间戳比较

在使用RTP协议时,如果需要网络对抗,保障QoS(Quality of Service,服务质量),我们需要通过序列号以及时间戳的比较,进行丢包判断。但是有个问题,比如一个RTP包,序列号为number1:5000,另一个RTP包序列号为number2:60000,可以说60000一定比5000大,是个更新的RTP包吗? 当然不是了,首先我们先重温下RTP数据包的结构。 在RFC3550中RTP固定报头结构按如下定义: [crayon-628f6289bcf21097963353/] 可以看到,RTP序列号sequ…

2019年7月6日 3条评论 1491点热度 9人点赞 Jeff 阅读全文
WebRTC

WebRTC研究:关键帧请求

WebRTC采用UDP传输流媒体数据,不可避免存在丢包情况。WebRTC主要采用FEC(Forward Error Correction,前向纠错)以及NACK(negative-acknowledge character,否定应答)对抗网络丢包。对于NACK,遇到丢包了才通知发送端重传对应数据包,但不是所有情况下某个包丢了就一定重传该包,有些场景下,重传该包会带来其它问题,例如增大延时,缓存过大,同时也可能发送端没有该数据包缓存,导致无法重传,此时会放弃重传该包。由于关键帧可以单独解码出图像,不参考前后视频帧,所…

2019年5月28日 8条评论 1902点热度 12人点赞 Jeff 阅读全文
12345
版权声明

为支持原创,创作更好的文章,未经许可,禁止任何形式的转载与抄袭,如需转载请邮件私信!本人保留所有法定权利。违者必究!

近期评论
  • Richard on WebRTC研究:Encoded Transform楼主你好,图片不见了,可以更新一下嘛?
  • flash91120 on Windows平台WebRTC编译-VS2017楼主,能不能出一期qt上使用webrtc…
  • damon on WebRTC音视频传输基础:NAT穿透太细了,看了眼我自己的笔记,果断直接删除…
  • k on Windows平台WebRTC编译(持续更新)麻烦问一下,我在src文件夹下,运行gn…
  • 小胖子 on WebRTC研究:Transport-cc之RTP及RTCP请教一个问题,在tcc的包里面的base…

COPYRIGHT © 2022 jianchihu.net. ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang