JVET-R0076 AHG9: Chroma QP mapping table cleanups [J. Xu, L. Zhang, Y.-K. Wang, K. Zhang, Z. Deng (Bytedance)]
This contribution proposes the following HLS changes to chroma QP mapping tables:
- Change qp_table_start_minus26 to qp_table_start and update the semantics accordingly.
This would allow the table to start in the negative range, but the proponent said there would be no desire to have an offset in this range. The coding of this would be unsigned rather than signed as currently.
This table is sent in the SPS.
There seemed to be no need for action on this.
- Change num_points_in_qp_table_minus1 to num_points_in_qp_table and update the semantics accordingly. num_points_in_qp_table equal to 0 indicates that for each QpY QpChroma is equal to QpY.
There is no shortcut for an identity mapping. The way to signal that is to send 0 for the val_minus1 and 1 for the diff_val. This is done in the VTM (there had been a bug in this, which has been fixed). The proponent said this is not very intuitive and would prefer that if no pivot points are sent, an identity mapping is inferred.
It was commented that similar proposals had previously been discussed with no action taken, and that it was undesirable to add more special cases, and that the reference software can help inform people of what to do, so no action was taken on this.
- Use separate chroma QP mapping tables for I slices and B/P slices.
Currently, our CTC uses different tables for AI versus RA/LB/LP. They are not very different, and it was commented that these had probably not really been optimized. This may have been to try to have some offset to balance the dual tree gain for chroma. The difference appeared to be very minor (off by one QP value in part of the range). Lower-level chroma QP offset can alternatively be used for a very similar effect if desired. There seemed to be no clear need for action on this, so no action was taken.
It was commented that we should check the luma/chroma balance used in the CTC and consider using offsets to adjust that.