H264 in WebRTC的那些坑

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中的