[x265] [PATCH] analysis:add logic for calculate qp for a given cu size

Deepthi Nandakumar deepthi at multicorewareinc.com
Fri Mar 13 06:12:48 CET 2015


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.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20150313/0aa1557a/attachment-0001.html>


More information about the x265-devel mailing list