Opened 5 months ago

Closed 5 months ago

#1625 closed defect (invalid)

Inconsistency between spec and vtm for alf_ctb_cc_cb_idc/alf_ctb_cc_cr_idc ctxInc

Reported by: peterderivaz Owned by:
Priority: minor Milestone:
Component: spec Version:
Keywords: Cc: ksuehring, bbross, XiangLi, fbossen, jvet@…


In section "Derivation process of ctxInc using left and above syntax elements", the spec says:

For the syntax elements alf_ctb_flag[ cIdx ][ ctbX ][ ctbY ], alf_ctb_cc_cb_idc[ ctbX ][ ctbY ], and alf_ctb_cc_cr_idc[ ctbX ][ ctbY ], ... cIdx equal to 1 for alf_ctb_cc_cr_idc[ ctbX ][ ctbY ] and cIdx equal to 2 for alf_ctb_cc_cr_idc[ ctbX ][ ctbY ].


The location ( xNbL, yNbL ) is set equal to ( x0 − 1, y0 ) and the derivation process for neighbouring block availability
as specified in clause 6.4.4 is invoked with the location ( xCurr, yCurr ) set equal to ( x0, y0 ), the neighbouring location
( xNbY, yNbY ) set equal to ( xNbL, yNbL ), checkPredModeY set equal to FALSE, and cIdx as inputs, and the output
is assigned to availableL.

However, in the VTM code for CABACReader.cpp:

void CABACReader::ccAlfFilterControlIdc(CodingStructure &cs, const ComponentID compID, const int curIdx,
                                        uint8_t *filterControlIdc, Position lumaPos, int filterCount)

  const Position leftLumaPos  = lumaPos.offset(-(int) cs.pcv->maxCUWidth, 0);
  const Position aboveLumaPos = lumaPos.offset(0, -(int) cs.pcv->maxCUWidth);

  const uint32_t curSliceIdx = cs.slice->getIndependentSliceIdx();
  const TileIdx  curTileIdx  = cs.pps->getTileIdx(lumaPos);

  const bool leftAvail =
    cs.getCURestricted(leftLumaPos, lumaPos, curSliceIdx, curTileIdx, ChannelType::LUMA) != nullptr;
  const bool aboveAvail =
    cs.getCURestricted(aboveLumaPos, lumaPos, curSliceIdx, curTileIdx, ChannelType::LUMA) != nullptr;

the availability uses ChannelType::LUMA.

This means that the VTM code is equivalent to if the spec set cIdx equal to 0 for alf_ctb_cc_cr_idc and alf_ctb_cc_cr_idc.

I believe the availability depends on cIdx, so this is not just an implementation detail.

Change history (2)

comment:1 Changed 5 months ago by fbossen

I don't think this matters since the intent is to check the availability of a neighbouring CTU. It also looks like that the spec and software access different locations in the neighbouring CTU, but that shouldn't matter either.

comment:2 Changed 5 months ago by peterderivaz

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

Good point!

I tried an experiment in which I changed ChannelType::LUMA to ChannelType::CHROMA. This made some test streams fail which made me think it was important - but now I realize that the failures were my fault because the getCuRestricted method assumes the position is given for the given channel.

Thanks for taking a look so quickly, and sorry for wasting your time!

Note: See TracTickets for help on using tickets.