The exact code is:

  Bool bSeparateLumaChroma = true; // choose estimation mode
  UInt uiPreCalcDistC      = 0;
  if( !bSeparateLumaChroma )
  {
    m_pcPredSearch->preestChromaPredMode( rpcTempCU, m_ppcOrigYuv[uiDepth], m_ppcPredYuvTemp[uiDepth] );
  }

The question is whether there is any benefit in setting bSeparateLumaChroma to false. If there is it may be worthwhile making it a configurable option.

This setting was explored in the early days of RExt, having spent a little
while making it work correctly (it had not been maintained/tested in the
main HM branch for a long time)

• see JCTVC-K0181,

file "ResultsFromConfigurationChangesTo422and444_r4.xlsx",
experiment "03a_encSearchYc"

The BD-rate performance then was:

Format	Y	U	V	Enc. Time
4:2:2	0.0%	-0.2%	-0.3%	141%
4:4:4	+0.2%	-0.5%	-0.5%	166%

(there is no change in decoding time)

The option seemed to just move the operating point, improving chroma at
the expense of luma, and there was a large increase in the encoding time.

For that reason, the option was not recommended for further RExt
development.

Since then, the option has remained, but the changing of 4:2:2 to
use square blocks rather than rectangular has unfortunately broken
the feature again.

The results using the latest RExt RGB & 4:4:4 test conditions are:

Tier	Format	Y	U	V	Enc. Time
Main	RGB	+0.8%	0.0%	0.0%	170%
High	RGB	+0.5%	-0.2%	-0.1%	170%
Super-high	RGB	+0.4%	-0.3%	-0.2%	170%
Main	4:4:4	+0.2%	-0.5%	-0.6%	162%
High	4:4:4	+0.3%	-0.4%	-0.4%	162%
Super-high	4:4:4	+0.3%	-0.4%	-0.4%	162%

(there is no change in decoding time)

The main 4:4:4 (above) results are similar to the results seen
back in K0181 (top).

Since:

1/ this feature still offers no significant BD-rate improvement
2/ this feature costs a lot in terms of encoding time
3/ it adds complexity to the software
4/ it was not used in the CTC of HM, and it was also broken in HM
5/ the committee decided that RExt didn't need this in the CTC
6/ and it is currently broken for 4:2:2,

... I recommend removing this feature from the code.

Given the performance data, I agree that the code can be removed.

In an inactive state, it is always hard to maintain and easily forgotten with changes in related code.

Removed in r4235.