WebRTC协议栈
WebRTC TURN协议初识及turnserver实践
2019-12-28 11:33:05WebRTC实时通信协议详解
2019-12-28 11:20:42webRTC是怎么应对网络变化的
2019-12-28 11:19:45在视频通信的技术领域WebRTC已成为主流的技术标准，WebRTC包涵了诸多优秀的技术，譬如：音频数字信号处理技术（AEC, NS, AGC）、编解码技术、实时传输技术、P2P技术等，这些技术目的都是为了实现更好实时音视频方案。但是在高分辨率视频通信过程中，通信时延、图像质量下降和丢包卡顿是经常发生的事，甚至在WiFi环境下，一次视频重发的网络风暴可以引起WiFi网络间歇性中断，通信延迟和图像质量之间存在的排斥关系是实时视频过程中的主要矛盾。分析WebRTC是如何解决这个矛盾之前，先来看看我们在在线教育互动的生产环境统计到的视频延迟和人感官的关系，大致如下：
延迟 感官描述
0 ~ 400毫秒 人感觉不到视频在通信过程中的延迟
400 ~ 800毫秒 人能感觉到轻微延迟，但不影响通信互动
800毫秒以上 人能感觉到延迟而且影响通信互动。
也就是说，通信过程中最好将视频延迟控制在800毫秒以内。除了延迟，视频图像质量也是个对人感官产生差异的关键因素，我们以640x480分辨率每秒24帧的H264编码情况下视频码率和人感官之间的关系（这组数据是我们通过小范围线上用户投票打分的数据）：
码率 感官描述
800kbps以上 人对视频清晰度满意,感觉不到视频图像中的信息丢失
Phone 人对视频清晰度基本满意，有时能感觉到视频图像中的信息丢失
Pipe 人对视频清晰度不满意，大部分时候无法辨认图像中的细节信息
从上面的描述可以知道视频质量保持在一个可让人接受的质量范围是需要比较大的带宽码率支持的，如果加上控制延迟，则更需要网络有很好速度和稳定性。但是很不幸，我们现阶段的移动网络和家用WiFi并不是我们想象中的那么好，很难做到在实时视频通信中一个让人非常满意的程度。为了解决以上几个问题，WebRTC设计了一套基于延迟和丢包反馈的拥塞机制（GCC）和带宽调节策略来保证延迟、质量和网路速度之间平衡，这是一个持续循环过程，如下图：
构建轻量级H.264 WebRTC堆栈
2019-12-25 06:28:03自WebRTC编解码器战争以缓和告终以来，已经有几年时间了。H.264也已经存在了超过15年，因此很容易掩盖运用中的多种复杂问题。
|pipe| CTO Tim Panton正在研究一个无人机项目，他需要为WebRTC提供一个轻量级H.264堆栈，而他决定自己构建一个。这当然不是我推荐给大多数人的一个运用，但Tim表示，如果不是一个简单的运用，那么这可能是一种启发性的体验。在这篇文章中，Tim一步步地向我们展示了他在努力让视频播放时的发现。除了阅读H.264介绍的RFCs规范之外，还可以通过它获得一个有趣的替换方案!
webrtc代码走读十六（Jitter延时的计算）
2019-12-25 06:23:39一、延时计算原理
1）jitter延时计算公式
JitterDelay由两部分延迟造成：传输大帧引起的延迟和网络噪声引起的延迟。计算公式如下：
JitterDelay = theta[0] * (MaxFS – AvgFS) + [noiseStdDevs * sqrt(varNoise) – noiseStdDevOffset]
该公式详细推导过程，请参见大牛的文章《WebRTC视频接收缓冲区基于KalmanFilter的延迟模型》
theta[0]：信道传输速率的倒数
MaxFS：自会话开始以来所收到的最大帧大小
AvgFS：表示平均帧大小
noiseStdDevs：表示噪声系数2.33
varNoise：表示噪声方差
noiseStdDevOffset：是噪声扣除常数30
2）jitter延时更新流程
webrtc代码走读十五（X264编码FEC弱网效果差问题解析）
2019-12-25 06:19:47一、问题描述
1）预置条件
1、配置webrtc抗丢包方法为FEC Only。
启动配置的时候，可以选NACK Only 或FEC Only 或NACK、FEC混合模式。
为了测试webrtc的X264 FEC抗丢包性能，在启动配置的时候，选择FEC Only模式。
配置方法请参考：VCMLossProtectionLogic::SetMethod
2、使用Network Emulator Client配置网络丢包模型为随机丢包，随机丢包概率为5%
2）测试用例
1、建立X264编码视频连接，查看视频清晰度及流畅性。
2、建立VP8编码视频连接，查看视频清晰度及流畅性。
3）预期效果
视频无长时间卡顿，至少X264编解码效果要与VP8一致。
为WebRTC服务选择H.264的四个理由
2019-12-25 06:17:39H.264被设定为取代VP8成为WebRTC服务的视频编解码器。
微软上周在他们的Edge开发博客上宣布， Edge的ORTC开始支持H.264/AVC。
· 是的，它是ORTC而不是WebRTC
· 是的，它仅通过运行时标志就可以开启
· 是的，它只在Edge浏览器可用，IE浏览器不行
但话又说回来，这是目前唯一能够在Firefox、Chrome和Edge之间跨浏览器进行视频通话的方法。VP8和VP9至多能让你在Chrome和Firefox之间建立视频通话。
这也是我写这篇文章的原因。Edge在ORTC中对H.264的支持并不多。从更大的视角来看，这甚至谈不上有意义。相比于其他浏览器Edge几乎没有市场份额，那么为什么还要为它花费心思呢？但是这件事仍然标志着一个转折——我们应当问自己：当我们要开发一个基于WebRTC的产品时，我们应该选择什么样的视频编解码器。
去年的时候，这个答案可能是“VP8”。
几个月前，答案可能是“看情况”。
现在，答案将会是“除非必须用VP8，否则就用H.264”。
H.264被列入了WebRTC所需的编码器
2019-12-25 06:16:48WebRTC 把H264和VP8都列入了WebRTC所必需要支持的视频编码器。同时联播可以同时使用多个编码器提供同一个媒体不同的分辨率来供人们选择以适应带宽波动（和其它）。不幸的是，libwebrtc没有实现对带有H.264编解码器的同时联播的支持。H.264实际上是间接的编解码器，因此只支持H.264的Safari不能实现与VP8和其他浏览器相同程度的编解码质量。本篇博客将详述如何解决此问题，实现方法与设计，和WebRTC产品的影响。
WebRTC VideoEngine超詳細教程（一）——視訊通話的基本流程
2019-12-25 06:15:57在前一篇文章中，講解了如何將OPENH264編解碼器整合到WebRTC中，但是OPENH264只能編碼baseline的H264視訊，而且就編碼質量而言，還是X264最好，本文就來講解一下如何將X264編碼器整合到WebRTC中，為了實現解碼，同時要用到ffmpeg。總體流程和之前一樣，分為重新封裝編解碼器和註冊呼叫兩大步驟，註冊呼叫這一步沒有任何不同，主要是重新封裝這一步驟有較大區別。
重新封裝X264編碼功能
首先當然還是要下載X264原始碼編譯出相應的庫以供呼叫。在windows下使用mingw進行編譯，再使用poxports工具匯出庫，最後得到libx264.dll和libx264.lib，同時把x264.h和x264_config.h總共四個檔案放到工程目錄下，並在專案屬性中進行相應配置。
WebRTC支持H264编解码
2019-12-25 06:13:34众所周知，Chrome/WebRTC中的视频编解码器一直使用Google自己开发的VP8/VP9，而对于业界广泛使用的H264则支持有限。他们这么做除了推广自家产品外，还有一个很好的理由：专利。VP8/VP9是免专利费的，而H264则需要专利授权。因此，Google Chrome在2011年的时候甚至放弃对H264的支持。
但是，随着H264的发展，Chrome不得不再次考虑对H264的支持问题，特别是思科发布H264开源实现openh264后。最近，Google宣布从Chrome50开始支持H264视频编解码，用户在打开Chrome时通过如下命令行参数即可启用：
--enable-features=WebRTC-H264WithOpenH264FFmpeg
这无疑是一个好消息，尤其对研究WebRTC的开发者来说，在WebRTC中启用H264可以明显带来如下收益：
1. 浏览器互操作：除Chrome和Firefox外，目前微软Edge浏览器的ORTC也开始支持H264/AVC。
2. 移动设备支持：移动设备基本上都支持H264硬件编解码。
3. 遗留系统互连：遗留视频系统基本上都使用H264，绝大多数不支持VP8。使用H264可使得WebRTC和这些系统方便互通。