Opened 5 years ago
Closed 5 years ago
#659 closed defect (fixed)
CuQpOffset Reset
Reported by: | bheng | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | spec | Version: | VVC D7 vE |
Keywords: | Cc: | ksuehring, bbross, XiangLi, fbossen, jvet@… |
Description
The CuQpOffset values (Cb/Cr/CbCr) should be reset to 0 at the start of each chroma QP offset group. Same as how CuQpDeltaVal is reset at the start of each quantization group.
Specifically, in the two places where IsCuChromaQpOffsetCoded is reset to 0, the CuQpOffset values should be reset to 0 as well.
if( cu_chroma_qp_offset_enabled_flag && qgOnC && cbSubdiv <= CuChromaQpOffsetSubdiv )
{
IsCuChromaQpOffsetCoded = 0
CuQpOffsetCb = 0
CuQpOffsetCr = 0
CuQpOffsetCbCr = 0
}
In the current text, the values are only reset at the start of a slice. They can propagate across quantization groups, across entropy_coding_sync points, and across tiles.
These propagated values only affect non-coded TUs, since the first coded TU in each quantization group must explicitly code a new value. So, this used to be irrelevant. However, with the addition of JVET-P1001, the chroma QP affects the deblocking filter. Therefore, the actual chroma QP must be determined, even for non-coded TUs.
Change history (5)
comment:1 Changed 5 years ago by delagrangep
comment:2 Changed 5 years ago by bbross
- Version changed from VVC D7 vB to VVC D7 vC
comment:3 Changed 5 years ago by bbross
- Version changed from VVC D7 vC to VVC D7 vD
comment:4 Changed 5 years ago by bbross
- Version changed from VVC D7 vD to VVC D7 vE
comment:5 Changed 5 years ago by bbross
- Resolution set to fixed
- Status changed from new to closed
Thanks for reporting!
This is fixed in JVET-Q2001-v3.
Good catch.
As you said:
Local chroma QP adjustment is made of
The CuQpOffsetCxx variables are derived from that, after initialization to 0 at the beginning of a slice.
For leading cbf==0 blocks in a "chroma adjustment group", CuQpOffsetCxx variables are propagated from previous coded blocks.
You suggest to reset them to zero instead, which has an impact on DBF since adoption of JVET-P1001.
Cons: creates "holes" (zero-offset -- for DBF only) between coded chroma blocks with valid offset
Pros: removes the dependency between last block of a CTU row and first block of next CTU row, which is definitely a problem
Since this only impacts DBF from time to time, I would tend to agree with your fix.
I guess an alternative would be to reset only when starting a CTU row, or whatever needed for independent/parallel decoding.