OK I committed the d_mv_bits out-of-bouds memory access bustage.
Unfortunately the fix is not correct. For some negative vectors which land in the range mv_table[64-34]..[64-64], the correct value seems to be 11 not 12.
I added an assertion that fails when incorrectly-estimated vector is coded.
I am not sure if the logic is incorrect in one place, or maybe the entire mv_bits can't be calculated in such "smart", branchless way. Following the code from CodeVector is surely correct but unfortunately measurably slower.
We should just use a LUT.
Anyway, overestimating cost by one in those rare cases (I need to encode over 200 frames to hit the assertion) should have absolutely no effect on quality.
__________________
Visit #xvid or #x264 at irc.freenode.net
Last edited by sysKin; 28th April 2007 at 17:49.
|