Opened 4 years ago

Closed 4 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 4 years ago by delagrangep

Good catch.

As you said:

Local chroma QP adjustment is made of

  • a flag to enable it (otherwise offset is zero): cu_chroma_qp_offset_flag
  • if enabled, an index into offset tables: cu_chroma_qp_offset_idx

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.

comment:2 Changed 4 years ago by bbross

  • Version changed from VVC D7 vB to VVC D7 vC

comment:3 Changed 4 years ago by bbross

  • Version changed from VVC D7 vC to VVC D7 vD

comment:4 Changed 4 years ago by bbross

  • Version changed from VVC D7 vD to VVC D7 vE

comment:5 Changed 4 years ago by bbross

  • Resolution set to fixed
  • Status changed from new to closed

Thanks for reporting!

This is fixed in JVET-Q2001-v3.

Note: See TracTickets for help on using tickets.