X264代码走读二（intra_refresh实现）

一、RTC遇到问题

实时音视频传输对延时要求很严苛，I P size大小不均是引入延时的主要原因之一。尤其Pacer模块要平滑发送视频数据，超大I帧必然引入比较大的传输延时。《Motion Adaptive Intra Refresh for the H.264 Video Coding Standard》paper介绍，intra_refresh解决这类问题。

如果都是I帧，码率持续比较高，目前网络带宽无法承受；若是单纯的IP帧模型，I帧相对于P帧的大小悬殊，实时传输时，会引入比较大的I帧传输延时；若使用intra_refresh模式，码率上下幅度不那么剧烈，根据paper测试素材显示，上下幅度小于15%。

 

二、设计思路

 

在一个GOP内，将一帧数据分解成GOP Size个块。然后每次编码时，根据（POC%（GOP Size））决定intracoded regions。并且该模式有个限制，i_frame_reference必须为1。也就是说第N帧，只能参考第（N-1）帧。

X264代码为例，实现细节：

x264_encoder_encode：根据i_poc和i_keyint_max计算intracoded regions。计算intra编码的start和end宏块ID索引。

mb_analyse_init：配置指定宏块区域intra编码。

x264_rc_analyse_slice：intra编码区域的SATD的计算。

三、总结

intra_refresh编码模式，可以有如下优点：

１、码率稳定。所有的P帧都有一条区域使用帧内预测模式，其他区域运行率失真优化选择最优模式，因此每个Ｐ帧的大小波动不会太大。
２、降低时延。避免出现超大Ｉ帧。该模式把I帧数据平分在GOP中的每个P帧上，起始I帧质量压力没有之前那么大，可以不必分配过多码率，保证后面P帧的质量。
３、错误恢复，每帧中的区块都是参考其前一帧的相应位置的块。假设第一帧丢失，那么第二帧有第二条区域可以正常解码，第三帧的第二条参考第二帧的第二条，那么第三帧的第二条和第三条可以正常解码依次类推，一个GOP期内可以恢复回来。

 

但是实际应用时，需要注意错误恢复这块，实现这个功能的前提是需要把残帧送给解码器，解码器在一个GOP自动恢复。

1、webrtc上在调度侧会对帧的完整性做一次判断，发现是残帧，直接丢弃一整帧。所以正常情况下，错误恢复这个功能在webrtc上是不起作用的。

2、通常情况下，人宁可看到卡顿的视频，也不喜欢看到局部花屏的视频。这种错误恢复的机制，不见得能提升用户的直观感受。

 

 

参考：

R. M. Schreier, A. Rothermel, Senior Member, IEEE 《Motion Adaptive Intra Refresh for the H.264 Video Coding Standard》

https://blog.csdn.net/ccc_cccd/article/details/113871394

https://blog.csdn.net/Purepromise/article/details/72956947?spm=1001.2014.3001.5501