remove unused recon[] from assembly code
calcQpForCU: remove m_pic input parameter.
Backed out changeset: a6930bfbd908

This changeset causes crashes. Needs to be re-examined.
Merge from stable
param: set aq strength to 0 in CQP
param: fix typo in if-check.
frameencoder: fix white-space nit, add comment
cleanup m_cuColocated[]
remove unused parameter *recon from assembly code
testbench: use different stride on calcrecon
dpb: Allow two L1 refs when b-pyramid is enabled [CHANGES OUTPUTS]

Consider this common case: if we have 5 consecutive (display order frames) that
are determined to be P1-B1-B2-B3-P2 by the lookahead. When b-pyramid is
enabled, the middle B will be encoded first and used as a reference by the two
following B frames (in encode order); P1-P2-B2ref-B1-B3

frame	L0	  L1
P1
P2	P1
B2ref	P1	  P2
B1	P1	  P2 B2ref
B3	B2ref P1  P2

When B1 is encoded, both B2ref and P2 should be available as L1 references,
this will improve the encode compression efficiency when b-pyramid is enabled
(closes #12)
Merge with stable
frameencoder: store the reference state of the picture in FrameEncoder

We find that reference state of the reference frame changed during the encode
when we use frame-thread > 1 this cause the CU level QP for the frame is
non-deterministic, this is leading the non-deterministic encoded output for the
frame, to avoid this store the reference state of the frame to
FrameEncoder->m_isReferenced and when the QP is calculate for CU, refer the
reference state of the frame from FrameEncoder->m_isReferenced this stat will
never change during the encode

Moved slice reference state initialization from dpb to FrameEncoder initSlice()
Merge with stable
frameencoder: comment nit
frameencoder: use m_isReferenced when configuring SAO in compressFrame()

In some pessimal situations, the slice's reference state could even be changed
by the time compressFrame() starts.  This prevents any race hazard.
param: enforce a minimum picture size

Do not allow the user to configure a picture smaller than at least one CTU
param: nit reorder of RC mode checks to avoid uncrustify problems

uncrustify was seeing FOO(bar < x || bar > y) and assuming this was a template
instantiation and changing it to FOO(bar<x || bar> y).  Reordering the two
comparisons avoids this problem
rest: nit
TEncEntropy: nit