Opened 12 years ago Closed 12 years ago #830 closed defect (fixed)mismatch between WD and HM for inferring significant_coeff_flag at last position in TU
Description
There seems to be a mis-match between semantics, syntax table and HM regarding whether significant_coeff_flag should be inferred for the last position in the TU.
In the WD semantics it says that significant_coeff_flag is inferred for the last position; however, this is not the case in HM-9.0.
Note that this also means the ctxIdxMap must be defined for i=15 (ctxIdxMap[15]=8), since there can be a possible to signal significant_coeff_flag at (3,3) position of 4x4 TU.
In WD9 (7.4.9.11 Residual coding semantics):
In HM-9.0, significant_coeff_flag is only inferred when numNonzero=0; however, for last position numNonZero is set to 1.
...
if( uiSigCoeffGroupFlag[ iCGBlkPos ] )
Change History (3)comment:1 Changed 12 years ago by DefaultCC Plugin
comment:2 Changed 12 years ago by tung.nguyencomment:3 Changed 12 years ago by bbross
Note: See
TracTickets for help on using
tickets. | This list contains all users that will be notified about changes made to this ticket. These roles will be notified: Reporter, Owner, Subscriber, Participant
|
I think the implementation in HM9 match the WD text.
For the last significant scan position in processing order, i.e., in reverse scan order, the processing of significant_coeff_flag is out of the loop. This behaviour is obtained through
if( iScanPosSig == (Int) uiScanPosLast )
{
}
Hence, the case (3,3), which is equal to a scan position value of 15, never occurs for 4 by 4 transform block.