<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 25, 2013 at 8:06 AM, chen <span dir="ltr"><<a href="mailto:chenm003@163.com" target="_blank">chenm003@163.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-height:1.7;font-size:14px;font-family:arial"><pre>At <a href="tel:2013-09-25%C2%A020" value="+12013092520" target="_blank">2013-09-25 20</a>:06:45,"Derek Buitenhuis" <<a href="mailto:derek.buitenhuis@gmail.com" target="_blank">derek.buitenhuis@gmail.com</a>> wrote:
>On 9/25/2013 6:29 AM, Min Chen wrote:
>> # HG changeset patch
>> # User Min Chen <<a href="mailto:chenm003@163.com" target="_blank">chenm003@163.com</a>>
>> # Date 1380086952 -28800
>> # Node ID 57efca19f5b8d8b5bdc22a0bb9fbfc6169724266
>> # Parent  bdd26fd0325acf0f36409e994bdc262b11fa70f4
>> Reduce half HPEL interpolate works by merge nest point
>
>"half HPEL" == QPEL, no? Or do you mean something else?
half works of HPEL, my English problem</pre><pre> </pre><pre><div class="im">>> In the square1[9], the candidate pixel below:
>> 
>>  5 1 7
>>  3 x 4
>>  6 2 8
>> 
>> The main idea is in the HPEL ME, every two pixel distance is unit '1',
>> so we can merge 1-2, 3-4, 5-6-7-8 with one interpolate </div>by increment 1 extra row/col.
>
>[...]
I means many pixel may share in that time, so we can reduce interpolate operators.</pre><pre><div class="im">
>> -    assert(height % 2 == 0);
>> +    if (N == 4)
>> +        assert(height % 2 == 0);
>
>I don't think this is what </div>asserts are meant for.
The 4-tap interpolate will process 2 rows every loop, so we keep this code, if someone change caller, we can know it need to sync.</pre><pre><div class="im">
>>      fenc = (pixel*)X265_MALLOC(pixel, MAX_CU_SIZE * MAX_CU_SIZE);
>> -    subpelbuf = (pixel*)X265_MALLOC(pixel, MAX_CU_SIZE * MAX_CU_SIZE);
>> -    immedVal = (short*)X265_MALLOC(short, MAX_CU_SIZE * (MAX_CU_SIZE + NTAPS_LUMA - 1));
>> +    subpelbuf = (pixel*)X265_MALLOC(pixel, (MAX_CU_SIZE + 1) * (MAX_CU_SIZE + 1));
>> +    immedVal = (short*)X265_MALLOC(short, (MAX_CU_SIZE + 1) * (MAX_CU_SIZE + 1 + NTAPS_LUMA - 1));
>
>Aside: We really should not be using the 'short' datatype.</div> It is not portable.
Keep old code only, I think we need update all of short when we want to support high_bit_depth</pre></div></blockquote><div><br></div><div>Derek's point here, which we need to take into account in a new patch, is that we should use int16_t here instead of short because short is not always 16bits.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-height:1.7;font-size:14px;font-family:arial"><pre><div class="im">>> +void MotionEstimate::subpelInterpolate2(pixel *fref, intptr_t lumaStride, </div>
int xFrac, int yFrac, int dir)
>> +{
>> +    assert(yFrac | xFrac);
>
>See above.
This function for subpel only, so it will report when invalid used.</pre><div class="im"><pre>>- Derek
>
>_______________________________________________
>x265-devel mailing list
><a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a>
><a href="https://mailman.videolan.org/listinfo/x265-devel" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a>
</pre></div></div><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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Steve Borho
</div></div>