[x265] [PATCH] Adapting weightp primitive for pixel input

Shazeb Khan shazeb at multicorewareinc.com
Tue Oct 22 14:08:47 CEST 2013


On Tue, Oct 22, 2013 at 12:51 AM, Steve Borho <steve at borho.org> wrote:

>
>
>
> On Mon, Oct 21, 2013 at 6:21 AM, <shazeb at multicorewareinc.com> wrote:
>
>> # HG changeset patch
>> # User Shazeb Nawaz Khan <shazeb at multicorewareinc.com>
>> # Date 1382354467 -19800
>> #      Mon Oct 21 16:51:07 2013 +0530
>> # Node ID 3e732910246416da437183675b0892f6ebb43005
>> # Parent  f987c24c7bf2d3e6df0f96b2c75f3e71ab15a85e
>> Adapting weightp primitive for pixel input
>>
>>
> queued, but I have a question
>
>
>> by simulating shift & round as in convertPixelToShort Primitive
>>
>> diff -r f987c24c7bf2 -r 3e7329102464 source/common/pixel.cpp
>> --- a/source/common/pixel.cpp   Mon Oct 21 16:15:22 2013 +0530
>> +++ b/source/common/pixel.cpp   Mon Oct 21 16:51:07 2013 +0530
>> @@ -516,8 +516,7 @@
>>      }
>>  }
>>
>> -template<typename T>
>> -void weightUnidir(T *src, pixel *dst, intptr_t srcStride, intptr_t
>> dstStride, int width, int height, int w0, int round, int shift, int offset)
>> +void weightUnidir(int16_t *src, pixel *dst, intptr_t srcStride, intptr_t
>> dstStride, int width, int height, int w0, int round, int shift, int offset)
>>  {
>>      int x, y;
>>
>> @@ -525,15 +524,31 @@
>>      {
>>          for (x = width - 1; x >= 0; )
>>          {
>> -            // note: luma min width is 4
>> -            dst[x] = (pixel)Clip3(0, ((1 << X265_DEPTH) - 1), ((w0 *
>> (src[x] + IF_INTERNAL_OFFS) + round) >> shift) + offset);
>> -            x--;
>> +            // note: width can be odd
>>              dst[x] = (pixel)Clip3(0, ((1 << X265_DEPTH) - 1), ((w0 *
>> (src[x] + IF_INTERNAL_OFFS) + round) >> shift) + offset);
>>              x--;
>>
>
> is there a reason the loop criteria are so wierd?  If weights rows
> backwards (from right to left) and top to bottom but y counts from bottom
> to top?
>

That's the way it had been. Indeed, the x-- can be a source of crash due to
overwriting meta data in dynamic allocation when used without caution.
Wrote a patch to remedy this.


>
>
>>          }
>>
>>          src += srcStride;
>> -        dst  += dstStride;
>> +        dst += dstStride;
>> +    }
>> +}
>> +
>> +void weightUnidirPix(pixel *src, pixel *dst, intptr_t srcStride,
>> intptr_t dstStride, int width, int height, int w0, int round, int shift,
>> int offset)
>> +{
>> +    int x, y;
>> +    for (y = height - 1; y >= 0; y--)
>> +    {
>> +        for (x = width - 1; x >= 0; )
>> +        {
>> +            // simulating pixel to short conversion
>> +            short val = src[x] << (IF_INTERNAL_PREC - X265_DEPTH);
>> +            dst[x] = (pixel) Clip3(0, ((1 << X265_DEPTH) - 1), ((w0 *
>> (val) + round) >> shift) + offset);
>> +            x--;
>> +        }
>> +
>> +        src += srcStride;
>> +        dst += dstStride;
>>      }
>>  }
>>
>> @@ -856,8 +871,8 @@
>>      p.transpose[3] = transpose<32>;
>>      p.transpose[4] = transpose<64>;
>>
>> -    p.weightpUniPixel = weightUnidir<pixel>;
>> -    p.weightpUni = weightUnidir<int16_t>;
>> +    p.weightpUniPixel = weightUnidirPix;
>> +    p.weightpUni = weightUnidir;
>>
>>      p.pixelsub_sp = pixelsub_sp_c;
>>      p.pixeladd_pp = pixeladd_pp_c;
>> diff -r f987c24c7bf2 -r 3e7329102464 source/common/vec/pixel-sse41.cpp
>> --- a/source/common/vec/pixel-sse41.cpp Mon Oct 21 16:15:22 2013 +0530
>> +++ b/source/common/vec/pixel-sse41.cpp Mon Oct 21 16:51:07 2013 +0530
>> @@ -5659,8 +5659,8 @@
>>      p.sse_pp[LUMA_64x48] = sse_pp_64<48>;
>>      p.sse_pp[LUMA_64x16] = sse_pp_64<16>;
>>
>> -    p.weightpUniPixel = weightUnidirPixel;
>> -    p.weightpUni = weightUnidir;
>> +//    p.weightpUniPixel = weightUnidirPixel;
>> +//    p.weightpUni = weightUnidir;
>>  #endif /* !HIGH_BIT_DEPTH */
>>  }
>>  }
>> _______________________________________________
>> x265-devel mailing list
>> x265-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x265-devel
>>
>
>
>
> --
> Steve Borho
>
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20131022/2ac09de5/attachment.html>


More information about the x265-devel mailing list