[x265] [PATCH] rc: fixes inconsistent output in linux because of RC Lock issue in CQP/CRF

Steve Borho steve at borho.org
Fri Jun 26 21:15:10 CEST 2015


On 06/26, aarthi at multicorewareinc.com wrote:
> # HG changeset patch
> # User Aarthi Thirumalai
> # Date 1434973816 -19800
> #      Mon Jun 22 17:20:16 2015 +0530
> # Node ID 1c6744174bfcfc031492c041243e1d9a9c02a5cd
> # Parent  1e5c4d155ab85e8e8dd199bb3515801766ea9e88
> rc: fixes inconsistent output in linux because of RC Lock issue in CQP/CRF

It's not clear why this is a race-hazard. Is there something in rate
control that must be protected, or is this just covering up for
insufficient amounts of ref-lag? What is the race hazard?

It's a bit of a layering violation to be mucking about
with rate-control internal here, but that can be dealt with in a
follow-up patch.

> diff -r 1e5c4d155ab8 -r 1c6744174bfc source/encoder/frameencoder.cpp
> --- a/source/encoder/frameencoder.cpp	Thu Jun 25 13:42:29 2015 +0530
> +++ b/source/encoder/frameencoder.cpp	Mon Jun 22 17:20:16 2015 +0530
> @@ -1056,18 +1056,26 @@
>              rowCount = X265_MIN((m_numRows + 1) / 2, m_numRows - 1);
>          else
>              rowCount = X265_MIN(m_refLagRows, m_numRows - 1);
> -        if (row == rowCount)
> +    }
> +    if (row == rowCount)
> +    {
> +        m_rce.rowTotalBits = 0;
> +        if (m_param->rc.rateControlMode == X265_RC_ABR || bIsVbv)
>          {
> -            m_rce.rowTotalBits = 0;
>              if (bIsVbv)
>                  for (uint32_t i = 0; i < rowCount; i++)
>                      m_rce.rowTotalBits += curEncData.m_rowStat[i].encodedBits;
>              else
>                  for (uint32_t cuAddr = 0; cuAddr < rowCount * numCols; cuAddr++)
>                      m_rce.rowTotalBits += curEncData.m_cuStat[cuAddr].totalBits;
> -
>              m_top->m_rateControl->rateControlUpdateStats(&m_rce);
>          }
> +        /* do not allow the next frame to enter rateControlStart() until this
> +         * frame has updated its mid-frame statistics */
> +        m_top->m_rateControl->m_startEndOrder.incr();
> +
> +        if (m_rce.encodeOrder < m_param->frameNumThreads - 1)
> +            m_top->m_rateControl->m_startEndOrder.incr(); // faked rateControlEnd calls for negative frames
>      }
>  
>      /* flush row bitstream (if WPP and no SAO) or flush frame if no WPP and no SAO */
> diff -r 1e5c4d155ab8 -r 1c6744174bfc source/encoder/ratecontrol.cpp
> --- a/source/encoder/ratecontrol.cpp	Thu Jun 25 13:42:29 2015 +0530
> +++ b/source/encoder/ratecontrol.cpp	Mon Jun 22 17:20:16 2015 +0530
> @@ -1086,19 +1086,6 @@
>          }
>      }
>      m_framesDone++;
> -
> -    /* CQP and CRF (without capped VBV) doesn't use mid-frame statistics to 
> -     * tune RateControl parameters for other frames.
> -     * Hence, for these modes, update m_startEndOrder and unlock RC for previous threads waiting in
> -     * RateControlEnd here.those modes here. For the rest - ABR
> -     * and VBV, unlock only after rateControlUpdateStats of this frame is called */
> -    if (m_param->rc.rateControlMode != X265_RC_ABR && !m_isVbv)
> -    {
> -        m_startEndOrder.incr();
> -
> -        if (rce->encodeOrder < m_param->frameNumThreads - 1)
> -            m_startEndOrder.incr(); // faked rateControlEnd calls for negative frames
> -    }
>      return m_qp;
>  }
>  
> @@ -1625,16 +1612,6 @@
>  
>      m_cplxrSum += rce->rowCplxrSum;
>      m_totalBits += rce->rowTotalBits;
> -
> -    /* do not allow the next frame to enter rateControlStart() until this
> -     * frame has updated its mid-frame statistics */
> -    if (m_param->rc.rateControlMode == X265_RC_ABR || m_isVbv)
> -    {
> -        m_startEndOrder.incr();
> -
> -        if (rce->encodeOrder < m_param->frameNumThreads - 1)
> -            m_startEndOrder.incr(); // faked rateControlEnd calls for negative frames
> -    }
>  }
>  
>  void RateControl::checkAndResetABR(RateControlEntry* rce, bool isFrameDone)
> _______________________________________________
> 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