As can be seen from here: ​https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/merge_requests/1944#note_17322

When implementing the following constraint:

When there are multiple SEI messages with a particular value of payloadType not equal to 133 that are associated with a particular AU or DU and apply to a particular OLS or layer, regardless of whether some or all of these SEI messages are scalable-nested, the SEI messages shall have the same SEI payload content.

A bug in the text of the constraint was identified. If a picture has four subpictures, each of which is associated with an SEI message, e.g., the decoded picture hash SEI message, contained in a scalable nesting SEI message with sn_subpic_flag equal to 1, then per the current wording of the constraint, the four SEI messages shall have the same payload content. That's incorrect and not the intent.

Therefore, in the constraint, "OLS or layer" should be changed to be "OLS, layer, or subpicture", which is the intent.

p.178 definition of inferred value for sb_coded_flag[xS][yS] is as follows:

When sb_coded_flag[ xS ][ yS ] is not present, it is inferred to be equal to 1.

Notably, this is different than HEVC's definition for the inferred value of coded_sub_block_flag[xS][yS]:

When coded_sub_block_flag[ xS ][ yS ] is not present, it is inferred as follows: – If one or more of the following conditions are true, coded_sub_block_flag[ xS ][ yS ] is inferred to be equal to 1: – ( xS, yS ) is equal to ( 0, 0 ). – ( xS, yS ) is equal to ( LastSignificantCoeffX >> 2, LastSignificantCoeffY >> 2 ). – Otherwise, coded_sub_block_flag[ xS ][ yS ] is inferred to be equal to 0.

Since sb_coded_flag[xS][yS] is only signaled for subblock indices of (i<lastSubBlock && i > 0) (as per p. 81 table), this implies that sb_coded_flag for subblock indices >= lastSubBlock should be inferred to be 1. This appears to cause unintended behaviour.

An example of potential unintended behaviour for this can be seen in the following case: Regular (non-transform-skip) flow, TU size is 8x8, and lastSubBlock==2. Thus:

subblock 3 @ (1,1): no coeffs subblock 2 @ (1,0): lastSubBlock, has coeffs subblock 1 @ (0,1): has coeffs subblock 0 @ (0,0): (don't care about coeffs)

sb_coded_flag will not be signaled on i==3 or i==2 as it is only signaled for i<lastSubBlock. However, sb_coded_flag will be signaled on i==1. On i==1, the process for deriving ctxInc for sb_coded_flag[0][1] is executed and will use eq.1548 on p. 433:

csbfCtx += sb_coded_flag[ xS + 1 ][ yS ]

Thus, csbfCtx for [0][1] will query value of sb_coded_flag[1][1]. But as [1][1] position corresponds to i==3 (>= lastSubBlockPos), sb_coded_flag[1][1] has not been signaled: it will follow the non-signaled inference rule and have a value of 1. So csbfCtx on [1][0] will be initialized as though there is a coded subblock in [1][1] when there actually is not. This does not seem to follow the intent of querying the flag in eq.1548.

Notably, VTM appears to use the HEVC flow for the configuration of sb_coded_flag in CABACReader::residual_coding_subblock:

// swarrington note: cctx.m_sigCoeffGroupFlag is zero before this point.

  bool sigGroup = ( isLast || !minSubPos );
  if( !sigGroup )
  {
    sigGroup = m_BinDecoder.decodeBin( cctx.sigGroupCtxId() );
  }
  if( sigGroup )
  {
    cctx.setSigGroup();
  }

Because m_sigCoeffGroupFlag is initially zeroed for all positions, then is always set to 1 if either sb_coded_flag is present or this is either i==lastSubBlock or i==0. This has the effect of following the H.265 flow for coded_sub_block_flag rather than the VVC spec for sb_coded_flag. Following the VVC spec it seems this code should rather initialize all positions to 1 and then conditionally set to 0 if there is a flag present with value 0.

Because of the reasoning above I think this is a spec issue rather than a VTM issue.

In spec the bp_cpb_removal_delay_delta_val[ i ] is defined as:

for( i = 0; i <= bp_num_cpb_removal_delay_deltas_minus1; i++ )
    bp_cpb_removal_delay_delta_val[ i ]

We see from definition of bp_num_cpb_removal_delay_deltas_minus1 that bp_cpb_removal_delay_delta_val max size is equal to 16.

But in VTM we found:

    sei_read_uvlc( pDecodedMessageOutputStream, code, "num_cpb_removal_delay_deltas_minus1" );               sei.m_numCpbRemovalDelayDeltas = code + 1;
    for( i = 0; i < sei.m_numCpbRemovalDelayDeltas; i ++ )
    {
      sei_read_code( pDecodedMessageOutputStream, ( sei.m_cpbRemovalDelayLength ), code, "cpb_removal_delay_delta[i]" );
      sei.m_cpbRemovalDelayDelta[ i ] = code;
    }

where m_cpbRemovalDelayDelta defined as

  uint32_t m_cpbRemovalDelayDelta    [15];

So there can happen a situation when m_numCpbRemovalDelayDeltas = 16 and only 15 "cells" for m_cpbRemovalDelayDelta, which will cause error.