1) From what I understand, the search starts at the 16x16 level. That’s the only way for the 32x32 CB to have access to the 16x16 results. The same logic applies for the 64x64 CBs. This isn’t really a question, but can you confirm?
Yes. MV inference is rooted at the 16x16 level, both up and down.
2) Do the MVF solely hold unsplit results? AFAICT, each MVF has 4 slots (quad tree children). Each slot has 2 reference lists, 8 results per list, hence the mvf_2Nx2N[4][2][8] arrays. So if the best result is 16x8, there is no way to store each partition’s winning MV.
Correct. It's not a problem, the 8x8 blocks have one more degree of freedom than 16x8/8x16.
3) After the assembly function was called with all the prediction information, is the result directly written to the CB? If not, then at what stage is the motion information transferred to it? I’m assuming the CB’s mv[2][2] and ref_idx[2][2] placeholders are still where we are going to store the values to be used for reconstruction and entropy coding.
I assume you mean the function generating the PMVs and MV candidates. The output is written to local arrays. The post-search result is written to the CB after the inter search of the partition, i.e. like now.
4) When you refer to the “unique candidate count”, are you referring to the number of MV we are actually going to test. For instance if we have 5 initial candidates, two of which are (1,1), then we do not have 5 candidates, but 4. The returned list should then contain the 4 candidates to test correct?
Yes. Laurent -- To unsubscribe visit http://f265.org or send a mail to [email protected].
