[x265] [PATCH] analysis:add logic for calculate qp for a given cu size
Steve Borho
steve at borho.org
Fri Mar 13 16:29:26 CET 2015
On 03/13, Deepthi Nandakumar wrote:
> I think the point is, m_cuTreeStats.qpBuffer contains the Fix8 values for
> 2-pass, but the m_lowres buffers keep double offsets for both AQ and
> cutree.
>
> We can push this patch, so Gopu can proceed with the rest of fine grained
> AQ. Sreelakshmy, your next task should be to modify both the double buffers
> in m_lowres, so FIX8 versions are used by ratecontrol.
I'm fine with doing FIX8 improvements in a later patch; but Aarthi's
comment requires a new patch.
> On Thu, Mar 12, 2015 at 1:45 PM, Sreelakshmy Govindan <
> sreelakshmy at multicorewareinc.com> wrote:
>
> > Hi Steve,
> >
> > I think the FIX8 version of qpCuTreeOffset and qpAqOffset are not
> > present as such in our code.
> > There is a FIX8 version of qpbuffer which is calculated in
> > ratecontrol.cpp as below
> >
> > m_cuTreeStats.qpBuffer[0][i] =
> > (uint16_t)(curFrame->m_lowres.qpCuTreeOffset[i] * 256.0);
> >
> > But I am not able to find it for Aq and Cutree offsets.
> >
> >
> > On Thu, Mar 12, 2015 at 10:30 AM, Sreelakshmy Govindan <
> > sreelakshmy at multicorewareinc.com> wrote:
> >
> >> Okay Aarthi, Thanks. I will check that too .
> >>
> >>
> >>
> >> On Thu, Mar 12, 2015 at 10:26 AM, Aarthi Priya Thirumalai <
> >> aarthi at multicorewareinc.com> wrote:
> >>
> >>> Also, since vbv may be changing the qp for each row, you need to pick up
> >>> the base qp from
> >>> curEncData.m_cuStat[cuAddr].baseQp instead of
> >>> m_frame->m_encData->m_avgQpRc;
> >>>
> >>> On Thu, Mar 12, 2015 at 10:25 AM, Sreelakshmy Govindan <
> >>> sreelakshmy at multicorewareinc.com> wrote:
> >>>
> >>>> Thanks Steve. I will make the changes and resend the patch.
> >>>>
> >>>>
> >>>> Regards,
> >>>> Sreelakshmy
> >>>>
> >>>> On Thu, Mar 12, 2015 at 9:32 AM, Steve Borho <steve at borho.org> wrote:
> >>>>
> >>>>> On Wed, Mar 11, 2015 at 10:36 PM, <sreelakshmy at multicorewareinc.com>
> >>>>> wrote:
> >>>>> > # HG changeset patch
> >>>>> > # User Sreelakshmy V G <sreelakshmy at multicorewareinc.com>
> >>>>> > # Date 1426131126 -19800
> >>>>> > # Thu Mar 12 09:02:06 2015 +0530
> >>>>> > # Node ID c7182de7496906e81b57cb94278d60cbcc446648
> >>>>> > # Parent b931c50d55011a1ddc08f0a230b9632fcb4674d7
> >>>>> > analysis:add logic for calculate qp for a given cu size
> >>>>>
> >>>>> the commit message should mention that the commit is adding the
> >>>>> function but that it is not yet used, for the convenience of reviewers
> >>>>>
> >>>>> > diff -r b931c50d5501 -r c7182de74969 source/encoder/analysis.cpp
> >>>>> > --- a/source/encoder/analysis.cpp Wed Mar 11 21:58:02 2015
> >>>>> -0500
> >>>>> > +++ b/source/encoder/analysis.cpp Thu Mar 12 09:02:06 2015
> >>>>> +0530
> >>>>> > @@ -1895,3 +1895,41 @@
> >>>>> >
> >>>>> > return false;
> >>>>> > }
> >>>>> > +
> >>>>> > +int Analysis::calculateQpforCuSize(CUData& ctu, const CUGeom&
> >>>>> cuGeom)
> >>>>> > +{
> >>>>> > + x265_emms();
> >>>>>
> >>>>> it doesn't appear that this function needs to use floats, so EMMS
> >>>>> should eventually be unnecessary
> >>>>>
> >>>>> > + int depth = cuGeom.depth;
> >>>>> > + uint32_t ctuAddr;
> >>>>> > + ctuAddr = ctu.m_cuAddr;
> >>>>> > + double qp = m_frame->m_encData->m_avgQpRc;
> >>>>> > +
> >>>>> > + uint32_t width = m_frame->m_fencPic->m_picWidth;
> >>>>> > + uint32_t height = m_frame->m_fencPic->m_picHeight;
> >>>>> > + uint32_t block_x = ctu.m_cuPelX +
> >>>>> g_zscanToPelX[cuGeom.absPartIdx];
> >>>>> > + uint32_t block_y = ctu.m_cuPelY +
> >>>>> g_zscanToPelY[cuGeom.absPartIdx];
> >>>>> > + uint32_t maxCols = (m_frame->m_fencPic->m_picWidth + (16 - 1))
> >>>>> / 16;
> >>>>> > + uint32_t blockSize = g_maxCUSize / (uint32_t)pow(2, depth);
> >>>>>
> >>>>> g_maxCUSize >> cuGeom.depth
> >>>>>
> >>>>> > + double qp_offset = 0;
> >>>>> > + uint32_t cnt = 0;
> >>>>> > + uint32_t idx;
> >>>>> > +
> >>>>> > + /* Use cuTree offsets if cuTree enabled and frame is
> >>>>> referenced, else use AQ offsets */
> >>>>> > + bool isReferenced = IS_REFERENCED(m_frame);
> >>>>> > + double *qpoffs = (isReferenced && m_param->rc.cuTree) ?
> >>>>> m_frame->m_lowres.qpCuTreeOffset : m_frame->m_lowres.qpAqOffset;
> >>>>>
> >>>>> the lookahead is generating FIX8 versions of these values, so integer
> >>>>> math can be used in later parts of the encoder.
> >>>>>
> >>>>> > + for (uint32_t block_yy = block_y; block_yy < block_y +
> >>>>> blockSize && block_yy < height; block_yy += 16)
> >>>>> > + {
> >>>>> > + for (uint32_t block_xx = block_x; block_xx < block_x +
> >>>>> blockSize && block_xx < width; block_xx += 16)
> >>>>> > + {
> >>>>> > + idx = ((block_yy / 16) * (maxCols)) + (block_xx / 16);
> >>>>> > + qp_offset += qpoffs[idx];
> >>>>> > + cnt++;
> >>>>> > + }
> >>>>> > + }
> >>>>> > +
> >>>>> > + qp_offset /= cnt;
> >>>>> > + qp += qp_offset;
> >>>>> > + return x265_clip3(QP_MIN, QP_MAX_MAX, (int)(qp + 0.5));
> >>>>> > +}
> >>>>> > +
> >>>>> > diff -r b931c50d5501 -r c7182de74969 source/encoder/analysis.h
> >>>>> > --- a/source/encoder/analysis.h Wed Mar 11 21:58:02 2015 -0500
> >>>>> > +++ b/source/encoder/analysis.h Thu Mar 12 09:02:06 2015 +0530
> >>>>> > @@ -139,6 +139,8 @@
> >>>>> > /* generate residual and recon pixels for an entire CTU
> >>>>> recursively (RD0) */
> >>>>> > void encodeResidue(const CUData& parentCTU, const CUGeom&
> >>>>> cuGeom);
> >>>>> >
> >>>>> > + int calculateQpforCuSize(CUData& ctu, const CUGeom& cuGeom);
> >>>>> > +
> >>>>> > /* check whether current mode is the new best */
> >>>>> > inline void checkBestMode(Mode& mode, uint32_t 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
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> x265-devel mailing list
> >>>> x265-devel at videolan.org
> >>>> https://mailman.videolan.org/listinfo/x265-devel
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> x265-devel mailing list
> >>> x265-devel at videolan.org
> >>> https://mailman.videolan.org/listinfo/x265-devel
> >>>
> >>>
> >>
> >
> > _______________________________________________
> > x265-devel mailing list
> > x265-devel at videolan.org
> > https://mailman.videolan.org/listinfo/x265-devel
> >
> >
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
--
Steve Borho
More information about the x265-devel
mailing list