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 < > [email protected]> 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 < > > [email protected]> wrote: > > > >> Okay Aarthi, Thanks. I will check that too . > >> > >> > >> > >> On Thu, Mar 12, 2015 at 10:26 AM, Aarthi Priya Thirumalai < > >> [email protected]> 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 < > >>> [email protected]> 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 <[email protected]> wrote: > >>>> > >>>>> On Wed, Mar 11, 2015 at 10:36 PM, <[email protected]> > >>>>> wrote: > >>>>> > # HG changeset patch > >>>>> > # User Sreelakshmy V G <[email protected]> > >>>>> > # 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 > >>>>> > [email protected] > >>>>> > https://mailman.videolan.org/listinfo/x265-devel > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Steve Borho > >>>>> _______________________________________________ > >>>>> x265-devel mailing list > >>>>> [email protected] > >>>>> https://mailman.videolan.org/listinfo/x265-devel > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> x265-devel mailing list > >>>> [email protected] > >>>> https://mailman.videolan.org/listinfo/x265-devel > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> x265-devel mailing list > >>> [email protected] > >>> https://mailman.videolan.org/listinfo/x265-devel > >>> > >>> > >> > > > > _______________________________________________ > > x265-devel mailing list > > [email protected] > > https://mailman.videolan.org/listinfo/x265-devel > > > > > _______________________________________________ > x265-devel mailing list > [email protected] > https://mailman.videolan.org/listinfo/x265-devel -- Steve Borho _______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
