[x265] [PATCH] rc: fix bug in ABR 2 pass, calculate aq-offset only for unreferenced frame in 2 pass

[Steve Borho]

On Mon, Mar 30, 2015 at 12:02 PM, Aarthi Priya Thirumalai
<aarthi at multicorewareinc.com> wrote:
>
> For the last pass in multi pass encodes, slice types are taken from the
> stats file before the frame is added into the lookahead queue. We would not
> do slice type analysis here and just stick with slice types read from the
> file.

This should be true of middle passes, I guess, since stats-write is
not considered?

> So, at this point, we would already know slice types along with CUTree
> offsets which we also copy  from the previous pass for all referenced
> slices. Only for the unreferenced frames, we would need to recompute
> aqoffsets as the data for those won't be written in the log files.

that combinatorial logic is making my head spin, can it be refactored
to something like:

if (m_param->rc.bStatRead && IS_REFERENCED(preFrame))
    /* already read from stats file */;
else if (m_bAdaptiveQuant)
    m_tld[tld].calcAdaptiveQuantFrame(preFrame, m_param);

or

if (m_bAdaptiveQuant && !m_param->rc.bStatRead)

If necessary we can add a bool member to Frame or Lowres that says the
AQ data was read from a file.

> Since calcAdaptive() rewrites all the arrays - both AQ&CUTree offsets, we
> should not do this and overwrite the values for referenced frames. This flow
> was broken when the NUMA related commits were pushed in.

This is unrelated to NUMA, it was the introduction of the
pre-lookahead which moved downscale and AQ init out of the API thread
and turned them into worker jobs that run before slicetypeDecide.

-- 
Steve Borho