一、X264
1)X264优点
- 码控算法质量较好,不会出现码率压不下来,就掉帧现象。
- 十种preset:"ultrafast", "superfast", "veryfast", "faster", "fast", "medium", "slow", "slower", "veryslow", "placebo"
- 七种profile:"baseline", "main", "high", "high10", "high422", "high444",
- 支持如下level。
2)X264缺点
- 变帧率特性支持不是很友好。需要在调度测规避。在webrtc中合入X264编码器时,可以参考下面处理方式,规避X264变帧率问题。
int32_t H264EncoderImpl::SetRateAllocation(
const BitrateAllocation& bitrate_allocation,
uint32_t framerate) {
if (bitrate_allocation.get_sum_bps() <= 0 || framerate <= 0)
return WEBRTC_VIDEO_CODEC_ERR_PARAMETER;
frame_rate_ = static_cast<float>(framerate);
if (frame_rate_)
target_bps_ = bitrate_allocation.get_sum_kbps()*(max_frame_rate_/frame_rate_);
else
target_bps_ = bitrate_allocation.get_sum_kbps();
return WEBRTC_VIDEO_CODEC_OK;
}
- 不支持SVC功能(视频会议对网络丢包比较敏感。传统AVC编码丢失一帧,对整个GOP的解码都会有影响。SVC编码接收端发现网络丢包,可以通过按层丢帧,降低帧率,保证视频质量的流畅性。目前webrtc里面的vp8已经使用svc编码)。导致NACK + FEC + SVC一套比较完善的提升QOS的方法无法使用。降低了webrtc的抗丢包特性。
- 不支持LTR功能,若是接收端 检测出长时间没有I帧解码,会发送一个大Size的IDR帧,对网络带宽影响比较大。
二、OpenH264
1)openh264优点
变帧率、SVC、LTR在openh264上都有实现。
2)openh264缺点
码控质量较差:1、运动和静止场景码率波动非常大;2、当画面运动复杂,码率压不下来,openh264会通过掉帧方式,压低码率。但是这样下来,视频流畅性就不那么完美。
具体参见WelsRcInitFuncPointers:
CheckFrameSkipBasedMaxbr:
三、总结
- X264是为点播,可接收一定延时的直播场景设计的。在实时音视频传输上没有花很大精力。
- openh264是专门为实时音视频传输场景打造的,但是码控模块的做的实在有点尴尬。对帧率有些挑剔的场景,就不太好用。