WebRTC 自诞生之日起, 就代表了实时通信领域的最好的技术. 不过很长时间里, 它所支持的视频编码器只有VP8, 后来随着H265/VP9为代表的下一代视频编码器的诞生, WebRTC里出现了VP9 Codec. 而当前应用最广泛的H264 却一直不受待见. 一直到Cisco 宣布旗下的H264 Codec开源为OpenH264, 并且替所有OpenH264的使用者支付了H264的专利费， 以次为契机， 在IETF的WebRTC会议中， 把H264和VP8都列入了WebRTC所必需要支持的视频编码器。 接下来， Google终于在WebRTC中增加了对H264的支持， 在PC平台(Windows和MAC), 编码器是用OpenH264, 解码器是用FFMPEG， 在iOS平台上， 编码器和解码器既可以使用OpenH264和FFMPEG, 也可以用apple的VideoToolbox所支持的硬件编解码器. 在Android平台, 可以用 OpenH264, FFMPGE, 也可以用 MediaCodec. 这个对于广大需要H264的公司来说是一大福音. 在下载的WebRTC代码中做稍许配置， 就可以使用H264了.
WebRTC是以其出色的QoS而著称的， 其VP8和VP9 的视频在比较差的网络条件下都可以保持流畅， 而且其质量相对于当前的网络带宽， 也非常不错。 如果把Codec换成H264, 其质量是否能跟VP8/VP9相提并论呢？
揣着这个问题, 我们对H264的质量做了下评估， 虽然在限带宽和设置丢包的条件下， H264还比较流畅， 但是其出现卡顿的几率明显高于VP8/VP9, 时延也大于VP8/VP9, 有时候质量也会比较差， 出现明显的块状效应， 很容易判断这类块状效应是由编码质量损失造成的。 理论上， 一个好的QoS设计实现， 不应该跟Codec的类型有关， 而且公认的H264的RD性能是优于VP8的， 为什么在WebRTC中的H264质量要差一些呢？
带着这个问题，我们对WebRTC做了深入分析. WebRTC的QoS策略主要是码率评估(类似可用带宽评估)， NACK重传, FEC(前向纠错), PLI 请求等, 这些控制都应该跟Codec类型无关呀。 但是真相却并非如此, 在WebRTC的实现中，如果Codec选择为H264的时候, FEC是被关闭的. VP8/VP9有支持时间分级, OpenH264虽然也支持时间分级， 但是在WebRTC中却不能打开.
关于FEC, Google的解释如下：
// Payload types without picture ID cannot determine that a stream is complete
// without retransmitting FEC, so using FEC + NACK for H.264 (for instance) is
// a waste of bandwidth since FEC packets still have to be transmitted. Note
// that this is not the case with FLEXFEC.
翻译成中文是： h264没有picture id, 所以无法判断流完整性， 所以使用FEC+NACK是浪费带宽了， 因为FEC 需要被冲传.
这个到底是不是真相呢？
答案是， 这个只是真相的一部分.
真正的真相是

1. 当H264的FEC 被启用后， 会导致重传包被丢弃。 接收端的JitterBuffer却一直傻傻等待， 从而导致长时间的等待
2. H264的FEC恢复隐藏着BUG, 容易引发流完整性判断出错导致解码失败， 引发视频卡顿.
3. 就是Google所说的原因， Picture ID 是VP8/VP9的概念， 用于标示视频帧的连续性， 而H264却只能依赖RTP序列号来判决连续。

H264不能启用时间分级的原因是， H264的rtp 组包协议里，无法包含视频参考层级关系的信息， 从而无法判决不同分层是否完整， 而VP8/VP9的rtp组包协议却包含着丰富的信息， 足以判断流完整性.

所以，根本原因是VP8/VP9是Google 亲生的，一切都为它们量身订造， 而H264是抱养的， 只能硬往这个框框里套了.

不过知道这些原因， 就容易找到对策， 实现一个质量胜过VP8的H264 方案了.

注: 本文所讨论的WebRTC， 其版本号为52, 最新的代码可能会有所出入

Reference
www.webrtc.org
rfc6386 - VP8 Data Format and Decoding Guide
rfc6184 - RTP Payload Format for H264 Video