[x264-devel] X264 recovery_frame_cnt is out of spec

[Chris Brien]

On 15.09.2010 20:04, Jason Garrett-Glaser wrote:
> On Wed, Sep 15, 2010 at 8:16 AM, Chris
> Brien<chris.brien at tandberg.com>  wrote:
>> The H.264 spec section D.2.7 says "recovery_frame_cnt shall be in
>> the range of 0 to MaxFrameNum-1, inclusive".
>
> That's rather lame.  Seems like we'll have to make MaxFrameNum larger
> when intra refresh is on then.

It is a bit lame. But then its meaning isn't "count this many frames 
until the picture is refreshed", but rather "this is what frame_num will 
be when the picture is refreshed", which means that if frame_num were to 
wrap past its original value, then the end-point of the recovery would 
be ambiguous. It also takes into account 
gaps_in_frame_num_value_allowed_flag.

As to the off-by-one in recovery_frame_cnt - the value X264 writes is
correct, according to its idea of what it is doing. It does spend 22
frames refreshing a CIF image, because it doesn't realise that on the
21st frame, the rightmost macroblock of the refresh boundary, which is
on the right edge of the frame, does not get corrupted by deblocking,
because there is nothing to deblock with.

For a CIF image, the refresh pattern looks like this (time is on the Y 
axis):
   1 RRxxxxxxxxxxxxxxxxxxxx
   2 -RRxxxxxxxxxxxxxxxxxxx
   3 --RRxxxxxxxxxxxxxxxxxx
   4 ---RRxxxxxxxxxxxxxxxxx
.....
  19 ------------------RRxx
  20 -------------------RRx
  21 --------------------RR
  22 ---------------------R

On the 21st frame, the whole picture has been refreshed, but on the 22nd 
frame, the final column of macroblocks is refreshed once more for good 
measure. X264 could skip doing this, and save bits.

Chris