Opened 5 years ago
Closed 5 years ago
#519 closed defect (fixed)
MIsmatch with vtm on cu chroma qp offset enabling
Reported by: | forayr | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | spec | Version: | |
Keywords: | Cc: | ksuehring, XiangLi, fbossen, jvet@… |
Description
The specification decides to enable cu_chroma_qp_offset tools only at the PPS level, whereas VTM checks also a flag at the slice level (after 'slice_joint_cbcr_qp_offset').
Is this a VTM issue ?
Attachments (1)
Change history (4)
comment:1 Changed 5 years ago by delagrangep
comment:2 Changed 5 years ago by forayr
- Component changed from VTM to spec
- Milestone VTM-6.2 deleted
- Summary changed from MIsmatch with spec on cu chroma qp offset enabling to MIsmatch with vtm on cu chroma qp offset enabling
comment:3 Changed 5 years ago by bbross
- Resolution set to fixed
- Status changed from new to closed
Thanks for reporting and suggesting a fix.
This will be fixed in JVET-P2001-vA.
Note: See TracTickets for help on using tickets.
Thanks for raising the issue.
This code is inherited from HEVC, and this is rather a spec issue: we make use of "cu_chroma_qp_offset_enabled_flag" which is undefined in VVC Draft.
Actually in JVET-O1168 we forgot to port the slice-level flag from HEVC, just before "if( deblocking_filter_override_enabled_flag )":
if( chroma_qp_offset_list_enabled_flag )
I apologize for having missed it.
We may discuss this issue at the next meeting, however the meeting notes seem to suggest alignment with HEVC in the discussion of JVET-O0737: "Hypothetically, we could just basically do what is in HEVC (“variant 0”)", that "variant 0" being what was adopted as JVET-O1168.
I can provide the spec fix if everyone is ok.