<div dir="ltr"><div>Psy-energy is not always measured at the CU level. estIntraPredQT makes RD decisions at the PU level (search.cpp: 1532). Also, chroma uses the psy-rd 4x4 cost loop for 8x8 CUs. <br><br></div>I see the concern though about performance reduction due to an in-loop if (size) check. There's no neat way around this, though. <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 12:33 PM, Steve Borho <span dir="ltr"><<a href="mailto:steve@borho.org" target="_blank">steve@borho.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/17, Divya Manivannan wrote:<br>
> The encoder uses 4x4 block size by testing with these two videos<br>
> NebutaFestival_2560x1600_60_10bit_crop.yuv and 720p50_parkrun_ter.y4m.<br>
> Since there is no similar function definition, I have generated the new<br>
> function definition for 4x4.<br>
<br>
</span>It can encode intra 4x4, but the CU in that case is still 8x8 and<br>
psy-energy is always measured at the CU level (for pixels, for residual<br>
it might measure 4x4 shorts).<br>
<br>
But why make a function that can only measure one half of the psy-value<br>
when there already exists a function prototype for generating the full<br>
energy score?<br>
<br>
I can guess where this is headed, where you write one function that<br>
fills in an array of costs and then call it twice and have the C code<br>
sum the abs(diff) of those costs, but if this is the direction you are<br>
headed then the function prototype needs to be the same for all block<br>
sizes.  Adding conditional paths for different block sizes will make the<br>
function slower, in whole, as will requiring two function calls to make<br>
one energy measurement.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Steve Borho<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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></div>