[x264-devel] X264 recovery_frame_cnt is out of spec

[Chris Brien]

The H.264 spec section D.2.7 says "recovery_frame_cnt shall be in the 
range of 0 to MaxFrameNum-1, inclusive". This constrains the maximum 
number of frames used in a recovery period. X264 uses more than 
MaxFrameNum frames to recover using intra-refresh (depending on the 
picture width). This confuses the JM decoder, as it calculates the 
target frame_num to start output using modulo MaxFrameNum arithmetic. 
Instead of entirely hiding the recovery period if there are no frames to 
display, it starts output somewhere during the recovery period.

For example, when MaxFrameNum is 16 (log2_max_frame_num_minus4 is zero) 
and using intra-refresh on a CIF image, X264 takes 21 frames to wipe the 
whole picture, and so writes recovery_frame_cnt=21. The JM decoder reads 
this as the picture being ready for output when frame_num=(current 
frame_num + 21)%16==(current frame_num + 5)%16, which is the sixth 
recovery frame.

Also, I think recovery_frame_cnt is off by one. The picture is indicated 
to be recovered when frame_num is equal to 
(frame_num+recovery_frame_cnt)%MaxFrameNum. If recovery_frame_cnt=0, 
then the recovery takes a single frame, 1 means two frames - i.e. 
recovery_frame_cnt is one less than the number of frames in the recovery 
sequence. At CIF, X264 uses 21 frames to cover the whole picture 
(=pic_width_in_mbs*2-1), and writes recovery_frame_cnt=21, when it 
should be 20.

Chris