[x265] x265-devel Digest, Vol 12, Issue 38

[Steve Borho]

On Tue, May 20, 2014 at 3:34 AM, Ashok Kumar Mishra
<ashok at multicorewareinc.com> wrote:
>
>
>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 19 May 2014 18:33:37 -0500
>> From: Steve Borho <steve at borho.org>
>> To: Development for x265 <x265-devel at videolan.org>
>> Subject: Re: [x265] [PATCH] fix : square chroma transform expected
>>         error   message
>> Message-ID:
>>
>> <CACD6pqN6dErJB5ye3t7pQkMraniEFpcQ1-a6Q0YBDfCAMcfBUw at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> On Mon, May 19, 2014 at 8:49 AM,  <ashok at multicorewareinc.com> wrote:
>> > # HG changeset patch
>> > # User Ashok Kumar Mishra<ashok at multicorewareinc.com>
>> > # Date 1400507347 -19800
>> > #      Mon May 19 19:19:07 2014 +0530
>> > # Node ID 8647c7861144eee4a0f96687794607b3e98d7b9f
>> > # Parent  ba2a9f61ea06f0ac799d8c0247eec770065465bb
>> > fix :  square chroma transform expected error message
>> >
>> > diff -r ba2a9f61ea06 -r 8647c7861144
>> > source/Lib/TLibEncoder/TEncSearch.cpp
>> > --- a/source/Lib/TLibEncoder/TEncSearch.cpp     Fri May 16 19:20:46 2014
>> > +0900
>> > +++ b/source/Lib/TLibEncoder/TEncSearch.cpp     Mon May 19 19:19:07 2014
>> > +0530
>> > @@ -2975,7 +2975,7 @@
>> >                  else
>> >                  {
>> >                      int16_t *ptr = resiYuv->getCbAddr(absTUPartIdxC);
>> > -                    X265_CHECK(trWidthC == trHeightC, "square chroma
>> > transform expected\n");
>> > +                    X265_CHECK(widthC == heightC, "square chroma
>> > transform expected\n");
>>
>> this sets off warning bells to me; the blockfill_s primitive is
>> writing (filling) a square block based on trWidthC.  Is this safe for
>> 4:2:2?
>>
>> >
>> > primitives.blockfill_s[(int)g_convertToBit[trWidthC]](ptr,
>> > resiYuv->m_cwidth, 0);
>> >                  }
>> >                  if (absSumV)
>> > @@ -2991,7 +2991,7 @@
>> >                  else
>> >                  {
>> >                      int16_t *ptr =  resiYuv->getCrAddr(absTUPartIdxC);
>> > -                    X265_CHECK(trWidthC == trHeightC, "square chroma
>> > transform expected\n");
>> > +                    X265_CHECK(widthC == heightC, "square chroma
>> > transform expected\n");
>> >
>> > primitives.blockfill_s[(int)g_convertToBit[trWidthC]](ptr,
>> > resiYuv->m_cwidth, 0);
>> >                  }
>> >                  cu->setCbfPartRange(absSumU ? setCbf : 0,
>> > TEXT_CHROMA_U, absTUPartIdxC, tuIterator.m_absPartIdxStep);
>> > @@ -3348,7 +3348,7 @@
>> >                  {
>> >                      int16_t *ptr =
>> > m_qtTempShortYuv[qtlayer].getCbAddr(tuIterator.m_absPartIdxTURelCU);
>> >                      const uint32_t stride =
>> > m_qtTempShortYuv[qtlayer].m_cwidth;
>> > -                    X265_CHECK(trWidthC == trHeightC, "square chroma
>> > transform expected\n");
>> > +                    X265_CHECK(widthC == heightC, "square chroma
>> > transform expected\n");
>> >
>> > primitives.blockfill_s[(int)g_convertToBit[widthC]](ptr, stride, 0);
>> >                  }
>> >
>> > @@ -3416,7 +3416,7 @@
>> >                  {
>> >                      int16_t *ptr =
>> > m_qtTempShortYuv[qtlayer].getCrAddr(tuIterator.m_absPartIdxTURelCU);
>> >                      const uint32_t stride =
>> > m_qtTempShortYuv[qtlayer].m_cwidth;
>> > -                    X265_CHECK(trWidthC == trHeightC, "square chroma
>> > transform expected\n");
>> > +                    X265_CHECK(widthC == heightC, "square chroma
>> > transform expected\n");
>> >
>> > primitives.blockfill_s[(int)g_convertToBit[widthC]](ptr, stride, 0);
>> >                  }
>> >
>>
>>
>> Yes, it is safe for 422, since trWidthC is same as widthC. But trHeightC
>> is getting halved in case of 422 and stored in heightC.

That only answers half the question though.  The other half is whether
it is safe to write a widthC x widthC square block into that buffer,
or whether that buffer was allocated as widthC x heightC.

-- 
Steve Borho