JVET-R0334 AHG11: Disabling chroma CU palette mode on under local dual tree [H.-J. Jhu, X. Xiu, Y.-W. Chen, T.-C. Ma, X. Wang (Kwai Inc.)]
In VTM8.0, under local dual tree case, the palette prediction update process is performed after each palette mode coded CU. In other words, a palette mode chroma CU cannot be decoded until all palette mode luma CUs under the same local-dual tree are decoded. This may become be a complexity bottleneck and cause latency in the pipeline.
In this proposal, it is proposed to disable palette mode for chroma CU under local dual tree cases. The results on YUV4:2:0 sequences compared to VTM8.0 are:
Class F: 0.00% AI, 0.00% RA, -0.01% LB
Class SCC: 0.00% AI, 0.03% RA, -0.02% LB
Presented in track B Sun Apr. 19, 0846-0930 (chaired by JRO)
The results are covering 4:2:0, but 4:2:2 would also be affected (not 4:4:4, as no local dual tree concept exists in the latter). 4:2:2 is uncommon for screen content.
The latency problem suggested is not related to parsing. Only predictor update and reconstruction is affected.
Several experts said that with the proposal, implementation would be simplified by using the existing single tree palette would be used just for luma, while chroma is decoded in parallel in some other mode. With local dual tree for palette, chroma needs to wait until luma is finished. However, the process of filling the palette would not yet be the same as single tree, as default values would need to be filled for chroma predictor update.
It is further expressed that the proposal would reduce the latency just for palette, and not for other modes that would be used local dual tree (e.g., CCLM).
Though the benefit is not large, and it only touches a cornercase in potential 4:4:4 profile (where a 4:4:4 stream is carrying 4:2:0 or 4:2:2 content using palette), several experts expressed opinion that this is a reasonable simplification. Cross-checker confirms that the implementation and text are aligned and stable.
Decision (cleanup/text & SW): Adopt JVET-R0334