fishmai的专栏

本文章主要介绍WEBRTC在各平台下调试或日志查看方式,以方便问题排查,包括BS,PC,Android,IOS(本系列文章转载请说明出处,博客园RTC.Blacker). 1,浏览器开发:这种开发方式不需要下载和编译WEBRTC源码(很多人都是"死"在这里的,不过确实很麻烦,原因就不赘述了),直接调用浏览器提供的API,入门相对简单(这并不意味着效果差,恰恰相反,因为浏览器厂商为你

很久没有写了，尤其是技术文章，总感觉很难受。这里总结一下最近的学习内容。官网永远是最重要，但同时也是最容易忽略的学习途径。So you should look official websites firtsly.。先看一看基础概念的解释WebRTC 相關縮寫名詞簡介推荐一种方式，打开官方给的例子，然后通过浏览器调试，定位到控制到就能够看到这个流程了。We

webrtc中rtcp反馈与码率控制模块分析0. 参考文档1 google congestion control1. 简介webrtc的带宽估计分为两部分，一部分为发送端根据rtcp反馈信息进行反馈，另一部分为接收端根据收到的rtp数据进行相应的码率估计[1]。 本文先分析发送端根据rtcp反馈信息进行码率调整的部分代码。具体计算公式: 

1. 概述对于共享网络资源的各类应用来说，拥塞控制技术的使用有利于提高带宽利用率，同时也使得终端用户在使用网络时能够获得更好的体验。在协议层面上拥塞控制是TCP的一个总要的组成部分；但是对于非面向链接的传输层协议，如UDP，其在协议层面上并没有对拥塞控制进行强制性的要求，这样做保证了最优的传输性能，且在拥塞控制的设计上也保留了更大的灵活性。WebRTC为我们提供了强大的音视频媒体引擎，前端开发

不推荐单独编译 WebRTC 中的各个模块出来使用。   昨天有幸在 Google 论坛里询问到 AECM 模块的延迟计算一事，Project member 说捣腾这个延迟实际上对 AECM 的效果没有帮助，这个延迟值仅在 AECM 启动时加快内置延迟估算器的收敛，如果更新的延迟有误，甚至会使 AECM 内置的延迟估算器出现错误的偏移，他建议我使用一个理论上的定值，