I got a bug report privately about valgrind reporting the decoder to access uninitialized/not existing memory.

Location: IntraPrediction.cpp line 1039

          int c = x + y + 1;
          const Pel left = refSide[c + 1];
          const Pel top = refMain[c + 1];

          pDsty[x] = ClipPel((wL * left + wT * top + (64 - wL - wT) * pDsty[x] + 32) >> 6, clpRng);

left seems to point to an unavailable location at some point.

Test setup:

1 frame BQSquare encoded with VTM config QP=32 on Linux/gcc 7.2.1, decoder running with valgrind.

My be an interaction between JVET_K0063_PDPC_SIMP and JVET_K0500_WAIP implementations.

In the VTM encoder the statistics to adaptively determine a maximum BT size are reset on I slices instead of IRAPs. This should be corrected to avoid mismatches when using segment-based encoding.

There is an editor's note in 8.5.5.9 of JVET-R2001-v10. [Ed. (BB): This way four 2×2 chroma subblocks (4×4 chroma block) share the same motion vector which is derived from the average of two 4×4 luma subblock motion vectors. In the decoding process motion compensation is still performed on 2×2 chroma blocks which is however a motion compensation on a chroma 4×4 block because all chroma MVs inside a 4×4 chroma block are the same. I would prefer an editorial change that makes it more clear that affine chroma MC is performed on 4×4 chroma blocks.]

To address this note, changes can be made to 8.5.6.1 as below the attached.