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

[Ashok Kumar Mishra]

------------------------------
>
> 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);
> >                  }
> >
> > _______________________________________________
> > x265-devel mailing list
> > x265-devel at videolan.org
> > https://mailman.videolan.org/listinfo/x265-devel
>
>
>
> --
> Steve Borho
>
>
> 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.
>

Regards
Ashok

>
> Subject: Digest Footer
>
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
>
> ------------------------------
>
> End of x265-devel Digest, Vol 12, Issue 38
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140520/b90c8c3f/attachment.html>