On Tue, May 20, 2014 at 3:34 AM, Ashok Kumar Mishra <[email protected]> wrote: > > > >> ------------------------------ >> >> Message: 2 >> Date: Mon, 19 May 2014 18:33:37 -0500 >> From: Steve Borho <[email protected]> >> To: Development for x265 <[email protected]> >> Subject: Re: [x265] [PATCH] fix : square chroma transform expected >> error message >> Message-ID: >> >> <cacd6pqn6derjb5ye3t7pqkmraniefpcq1-a6q0ybdfcamcf...@mail.gmail.com> >> Content-Type: text/plain; charset=UTF-8 >> >> On Mon, May 19, 2014 at 8:49 AM, <[email protected]> wrote: >> > # HG changeset patch >> > # User Ashok Kumar Mishra<[email protected]> >> > # 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 _______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
