<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">------------------------------<br>
<br>
Message: 2<br>
Date: Mon, 19 May 2014 18:33:37 -0500<br>
From: Steve Borho <<a href="mailto:steve@borho.org">steve@borho.org</a>><br>
To: Development for x265 <<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a>><br>
Subject: Re: [x265] [PATCH] fix : square chroma transform expected<br>
        error   message<br>
Message-ID:<br>
        <<a href="mailto:CACD6pqN6dErJB5ye3t7pQkMraniEFpcQ1-a6Q0YBDfCAMcfBUw@mail.gmail.com">CACD6pqN6dErJB5ye3t7pQkMraniEFpcQ1-a6Q0YBDfCAMcfBUw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Mon, May 19, 2014 at 8:49 AM,  <<a href="mailto:ashok@multicorewareinc.com">ashok@multicorewareinc.com</a>> wrote:<br>
> # HG changeset patch<br>
> # User Ashok Kumar Mishra<<a href="mailto:ashok@multicorewareinc.com">ashok@multicorewareinc.com</a>><br>
> # Date 1400507347 -19800<br>
> #      Mon May 19 19:19:07 2014 +0530<br>
> # Node ID 8647c7861144eee4a0f96687794607b3e98d7b9f<br>
> # Parent  ba2a9f61ea06f0ac799d8c0247eec770065465bb<br>
> fix :  square chroma transform expected error message<br>
><br>
> diff -r ba2a9f61ea06 -r 8647c7861144 source/Lib/TLibEncoder/TEncSearch.cpp<br>
> --- a/source/Lib/TLibEncoder/TEncSearch.cpp     Fri May 16 19:20:46 2014 +0900<br>
> +++ b/source/Lib/TLibEncoder/TEncSearch.cpp     Mon May 19 19:19:07 2014 +0530<br>
> @@ -2975,7 +2975,7 @@<br>
>                  else<br>
>                  {<br>
>                      int16_t *ptr = resiYuv->getCbAddr(absTUPartIdxC);<br>
> -                    X265_CHECK(trWidthC == trHeightC, "square chroma transform expected\n");<br>
> +                    X265_CHECK(widthC == heightC, "square chroma transform expected\n");<br>
<br>
this sets off warning bells to me; the blockfill_s primitive is<br>
writing (filling) a square block based on trWidthC.  Is this safe for<br>
4:2:2?<br>
<br>
>                      primitives.blockfill_s[(int)g_convertToBit[trWidthC]](ptr, resiYuv->m_cwidth, 0);<br>
>                  }<br>
>                  if (absSumV)<br>
> @@ -2991,7 +2991,7 @@<br>
>                  else<br>
>                  {<br>
>                      int16_t *ptr =  resiYuv->getCrAddr(absTUPartIdxC);<br>
> -                    X265_CHECK(trWidthC == trHeightC, "square chroma transform expected\n");<br>
> +                    X265_CHECK(widthC == heightC, "square chroma transform expected\n");<br>
>                      primitives.blockfill_s[(int)g_convertToBit[trWidthC]](ptr, resiYuv->m_cwidth, 0);<br>
>                  }<br>
>                  cu->setCbfPartRange(absSumU ? setCbf : 0, TEXT_CHROMA_U, absTUPartIdxC, tuIterator.m_absPartIdxStep);<br>
> @@ -3348,7 +3348,7 @@<br>
>                  {<br>
>                      int16_t *ptr = m_qtTempShortYuv[qtlayer].getCbAddr(tuIterator.m_absPartIdxTURelCU);<br>
>                      const uint32_t stride = m_qtTempShortYuv[qtlayer].m_cwidth;<br>
> -                    X265_CHECK(trWidthC == trHeightC, "square chroma transform expected\n");<br>
> +                    X265_CHECK(widthC == heightC, "square chroma transform expected\n");<br>
>                      primitives.blockfill_s[(int)g_convertToBit[widthC]](ptr, stride, 0);<br>
>                  }<br>
><br>
> @@ -3416,7 +3416,7 @@<br>
>                  {<br>
>                      int16_t *ptr =  m_qtTempShortYuv[qtlayer].getCrAddr(tuIterator.m_absPartIdxTURelCU);<br>
>                      const uint32_t stride = m_qtTempShortYuv[qtlayer].m_cwidth;<br>
> -                    X265_CHECK(trWidthC == trHeightC, "square chroma transform expected\n");<br>
> +                    X265_CHECK(widthC == heightC, "square chroma transform expected\n");<br>
>                      primitives.blockfill_s[(int)g_convertToBit[widthC]](ptr, stride, 0);<br>
>                  }<br>
><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>
<br>
<br>
--<br>
Steve Borho<br>
<br>
<br>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.<br></blockquote><div><br></div><div>Regards</div><div>Ashok </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Subject: Digest Footer<br>
<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>
<br>
------------------------------<br>
<br>
End of x265-devel Digest, Vol 12, Issue 38<br>
******************************************<br>
</blockquote></div><br></div></div>