Opened 4 years ago

Closed 4 years ago

#788 closed defect (fixed)

JVET-P1001 related: chroma QP for remote CU is wrong if the remote CU is local dual-tree

Reported by: wzeng Owned by:
Priority: minor Milestone: VTM-7.2
Component: VTM Version: VTM-7.1
Keywords: Cc: ksuehring, XiangLi, fbossen, jvet@…

Description

In VTM-7.1 LoopFilter.cpp, chroma QP for deblocking is derived as follows.

const TransformUnit& tuQ = *cuQ.cs->getTU(posQ, cuQ.chType);
const TransformUnit& tuP = *cuP.cs->getTU(posP, cuQ.chType);
const QpParam cQP(tuP, ComponentID(chromaIdx + 1));
const QpParam cQQ(tuQ, ComponentID(chromaIdx + 1));

Assuming current CU is cuQ, cuP and cuQ are sitting at CTU boundary, cuP is local dual tree while cuQ is single tree. cuP is also joint CbCr, thus joint_cbcr_qp_offset should be used to derive chroma QP. However, since tuP is obtained using cuQ.chType(which is Luma), cQP is constructed using joint_cbcr=0. Consequently, cb_qp_offset/cr_qp_offset is used to derive chroma QP. When cb_qp_offset/cr_qp_offset is different with joint_cbcr_qp_offset, chroma QP for tuP will be wrong.

Change history (4)

comment:1 Changed 4 years ago by Weijia

MR !1198 was submitted. Please find the details from the link below.
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/1198

comment:2 Changed 4 years ago by wzeng

Thanks Weijia for submitting the MR. I think it fixed the described issue.
Could the proponents of P1001 confirm the issue and the fix?

comment:3 Changed 4 years ago by AnandMeher

We are one of the proponents of P1001/P1002 and we confirm that the bug exists and the merge request MR!1198 fixes the bug.

comment:4 Changed 4 years ago by XiangLi

  • Milestone set to VTM-7.2
  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.