webRtc与H264的那些事

为什么webRtc使用H264会黑屏？

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 需要被冲传