BMS software bug on 64x64 ternary split restriction

[parkmw]

At the last meeting, it was decided to prohibit ternary split of anything bigger than 64 in width or height.
But, BMS software sometimes allows ternary split when width or height is bigger than 64.
If you look at line 465 in UnitPartitioner.cpp file, you can see code deciding whether specific split is allowed as below.

• Current

    switch( split )
    {
    case CU_HORZ_SPLIT:
      if( area.height <= minBtSize || area.height > maxBtSize )     return false;
      break;
    case CU_VERT_SPLIT:
      if( area.width <= minBtSize || area.width > maxBtSize )       return false;
      break;
    case CU_TRIH_SPLIT:
      if( ( cs.sps->getSpsNext().getMTTMode() & 1 ) != 1 )          return false;
      if( area.height <= 2 * minTtSize || area.height > maxTtSize ) return false;
      break;
    case CU_TRIV_SPLIT:
      if( ( cs.sps->getSpsNext().getMTTMode() & 1 ) != 1 )          return false;
      if( area.width <= 2 * minTtSize || area.width > maxTtSize )   return false;
      break;
    default:
      break;
    }
  

With this decision rule, for example, if the current CU size is 128x64, then triple split in horizontal direction (CU_TRIH_SPLIT) can be allowed even though width of the current CU is greater than 64 since the condition only checks height.
So, we need to consider width and height together when doing this. I can suggest two possible fixes as follows.

• Option 1 : by checking whether other side not to be split is greater than the maximum ternary split size

    switch( split )
    {
    case CU_HORZ_SPLIT:
      if( area.height <= minBtSize || area.height > maxBtSize )     return false;
      break;
    case CU_VERT_SPLIT:
      if( area.width <= minBtSize || area.width > maxBtSize )       return false;
      break;
    case CU_TRIH_SPLIT:
      if( ( cs.sps->getSpsNext().getMTTMode() & 1 ) != 1 )          return false;
      if( area.height <= 2 * minTtSize || area.height > maxTtSize || area.width > maxTtSize) return false;
      break;
    case CU_TRIV_SPLIT:
      if( ( cs.sps->getSpsNext().getMTTMode() & 1 ) != 1 )          return false;
      if( area.width <= 2 * minTtSize || area.width > maxTtSize || area.height > maxTtSize)  return false;
      break;
    default:
      break;
    }
  

• Option 2 : by checking whether other side not to be split is greater than 64

    switch( split )
    {
    case CU_HORZ_SPLIT:
      if( area.height <= minBtSize || area.height > maxBtSize )     return false;
      break;
    case CU_VERT_SPLIT:
      if( area.width <= minBtSize || area.width > maxBtSize )       return false;
      break;
    case CU_TRIH_SPLIT:
      if( ( cs.sps->getSpsNext().getMTTMode() & 1 ) != 1 )          return false;
      if( area.height <= 2 * minTtSize || area.height > maxTtSize || area.width > 64) return false;
      break;
    case CU_TRIV_SPLIT:
      if( ( cs.sps->getSpsNext().getMTTMode() & 1 ) != 1 )          return false;
      if( area.width <= 2 * minTtSize || area.width > maxTtSize || area.height > 64)  return false;
      break;
    default:
      break;
    }
  

It affects VTM software as well.

[ksuehring]

Fixed in BMS 2.1 following option #1, see

​https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_BMS/merge_requests/111