<div dir="ltr">ok. Another thing we could check is, if restricting lowres MV candidates to 2Nx2N searches would give more consistent results.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 18, 2015 at 8:04 PM, Steve Borho <span dir="ltr"><<a href="mailto:steve@borho.org" target="_blank">steve@borho.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/18, Deepthi Nandakumar wrote:<br>
> Gopu,<br>
><br>
> initSubCU accounts for the CU's partIdx while setting absPartIdx, that<br>
> means the expression in your patch should be changed to:<br>
><br>
> uint32_t block_x = cu.m_cuPelX;<br>
><br>
> Now, if you want to account for the PU offsets, you can do<br>
> uint32_t block_x = cu.m_cuPelX + g_zscanToPelX[pu.puAbsPartIdx];<br>
><br>
> Why do you need to add pu.width/2 ?<br>
<br>
</span>to find the middle of the PU. If we're going to only take one lowres MV,<br>
it might as well be from the middle of the prediction block<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Steve Borho<br>
_______________________________________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
</div></div></blockquote></div><br></div>