No additional clipping has been explicitly added to the RDPCM path, as discussed during presentation of JCTVC-O0066, with meeting notes found in the BoG report JCTVC-O0352.

Once the residual is combined with the prediction it is clipped to the valid video output range; this permits implementations to include clipping to the residual path to limit intermediate values.

This trac-report is perhaps identifying a missing clip in the HM decoder implementation (with the current calculation overflowing in extreme cases) ?

In invRdpcmNxN, the residual values are written to the 16-bit Pel array without clipping. Potentially, for n-bit source data, the values might reach n+log2(32)+sign, which may exceed the 16-bit values. Therefore clipping to 16-bit (size of Pel) should be added to the software. This clipping is not needed in the specification, and the software would be conformant, because if values larger than 16-bit are encountered, these will be clipped to n-bit at the final combination with the prediction.

Thanks for the links to the meeting notes.

I am not sure I quite understand how an implementation can safely include clipping in the accumulator.

Suppose the inputs are 30000,30000,-30000

If we clip the accumulator at 32767 then the final answer will be 2767, while if we compute with full precision won't the final answer be 30000?

The accumulator part cannot be clipped. But the final block of residuals can be.
The software probably needs to change the order that the residuals are combined so that a 32-bit accumulator can be used. On storing to the residual array (which is then not subsequently used by the invRDPCM process), the values can be clipped to fit within the Pel.

Possible fix for software.

Fixed in r4228. No effect on CTCs (except perhaps run-time).