[x265] recent refactors

[Steve Borho]

Hello,

I recently pushed a rather large refactor of the analysis code. There
were two aims with this refactor. One was to expose more parallelism,
ensuring multiple threads can work on the same CTU without stepping on
each other's toes. The other aim was to simply make the code maintainable. 

The two biggest coding style changes you will probably notice are the
increase in the use of references, pass objects by reference when the
called function cannot handle a NULL pointer (which is nearly always),
and the increase in the use of const decorators for arguments and class
methods.

The const-ness is to help with the parallelism work, the compiler will
help us keep track of which methods are safely read-only and do not
require any data locking. If it allows the compiler to improve
performance, this is an accidental benefit.

I've also tried to enforce consistent variable names:

fooFrame   - pointer to a Frame object
fooPic     - pointer to a PicYuv object (orig or recon)
fooYuv     - pointer to a Yuv object (CU orig, pred, recon, etc)
cuData     - reference of CU struct containing geom data
ctuAddr    - index of a CTU in a picture in scan order
absPartIdx - index of a CU/PU/TU part within a CTU in zscan order

It's a large code base, and I haven't cleaned up all of it. I'll gladly
take patches that apply these rules to the parts that I've missed.


The general gist of where I am going with the analysis code is to make
each Mode completely self-contained. A thread should be able to safely
pick up a Mode from another thread and process that prediction and
measure its cost (aka: --pmode). For this to work safely with full RDO,
the functions in search.cpp need to stop using the reconPic as
intermediate storage.  Intra NxN is a special case that will get handled
directly, but otherwise all the other inter and intra paths need to be
cleaned up to keep their grubby paws to themselves. They can use
everything in their Mode instance, and everything in their Search
instance and that is it. If we need to add more Yuv buffers to Search,
that is fine. They are relatively cheap, memory wise.

The rule for reconPic is that the recursive compress functions in
Analysis will write the CU's best mode's reconYuv into reconPic at the
end of each CU's analysis (when the best mode was not a split, because
in that case the recon was already written by the split CUs). That is
the only place where reconPic may be written. Intra must read reconPic
to collect intra samples, everyone else must leave it alone.

-- 
Steve Borho