自WebRTC编解码器战争以缓和告终以来，已经有几年时间了。H.264也已经存在了超过15年，因此很容易掩盖运用中的多种复杂问题。
|pipe| CTO Tim Panton正在研究一个无人机项目，他需要为WebRTC提供一个轻量级H.264堆栈，而他决定自己构建一个。这当然不是我推荐给大多数人的一个运用，但Tim表示，如果不是一个简单的运用，那么这可能是一种启发性的体验。在这篇文章中，Tim一步步地向我们展示了他在努力让视频播放时的发现。除了阅读H.264介绍的RFCs规范之外，还可以通过它获得一个有趣的替换方案!
一、延时计算原理
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延时更新流程
1、配置webrtc抗丢包方法为FEC Only。
启动配置的时候，可以选NACK Only 或FEC Only 或NACK、FEC混合模式。
为了测试webrtc的X264 FEC抗丢包性能，在启动配置的时候，选择FEC Only模式。
配置方法请参考：VCMLossProtectionLogic::SetMethod
2、使用Network Emulator Client配置网络丢包模型为随机丢包，随机丢包概率为5%
1、建立X264编码视频连接，查看视频清晰度及流畅性。
2、建立VP8编码视频连接，查看视频清晰度及流畅性。
视频无长时间卡顿，至少X264编解码效果要与VP8一致。
H.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”。
WebRTC 把H264和VP8都列入了WebRTC所必需要支持的视频编码器。同时联播可以同时使用多个编码器提供同一个媒体不同的分辨率来供人们选择以适应带宽波动（和其它）。不幸的是，libwebrtc没有实现对带有H.264编解码器的同时联播的支持。H.264实际上是间接的编解码器，因此只支持H.264的Safari不能实现与VP8和其他浏览器相同程度的编解码质量。本篇博客将详述如何解决此问题，实现方法与设计，和WebRTC产品的影响。
在前一篇文章中，講解了如何將OPENH264編解碼器整合到WebRTC中，但是OPENH264只能編碼baseline的H264視訊，而且就編碼質量而言，還是X264最好，本文就來講解一下如何將X264編碼器整合到WebRTC中，為了實現解碼，同時要用到ffmpeg。總體流程和之前一樣，分為重新封裝編解碼器和註冊呼叫兩大步驟，註冊呼叫這一步沒有任何不同，主要是重新封裝這一步驟有較大區別。
众所周知，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和这些系统方便互通。
最近实验了下如何让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 ）。
1. X264显式支持的一趟码率控制方法有：ABR, CQP, CRF. 缺省方法是CRF。这三种方式的优先级是ABR > CQP > CRF.
if ( bitrate ) rc_method = ABR;
else if ( qp || qp_constant ) rc_method = CQP;
else rc_method = CRF;
bitrate和QP都没有缺省值，一旦设置他们就表示要按照相应的码率控制方法进行编码，CRF有缺省值23，没有任何关于编码控制的设置时就按照CRF缺省值23来编码。
总述
在前一篇文章中，讲解了如何将OPENH264编解码器集成到WebRTC中，但是OPENH264只能编码baseline的H264视频，而且就编码质量而言，还是X264最好，本文就来讲解一下如何将X264编码器集成到WebRTC中，为了实现解码，同时要用到ffmpeg。总体流程和之前一样，分为重新封装编解码器和注册调用两大步骤，注册调用这一步没有任何不同，主要是重新封装这一步骤有较大区别。
重新封装X264编码功能
首先当然还是要下载X264源码编译出相应的库以供调用。在windows下使用mingw进行编译，再使用poxports工具导出库，最后得到libx264.dll和libx264.lib，同时把x264.h和x264_config.h总共四个文件放到工程目录下，并在项目属性中进行相应配置。