Custom Query (1442 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (46 - 48 of 1442)

Ticket Resolution Summary Owner Reporter
#842 fixed 8.5.3 minor editorial fix bbross crosewarne
Description

Subclause 8.5.3 is only invoked with nPbW and nPbH being specified in luma samples and within the body of the subclause nPbW and nPbH these are described as being in luma samples, so the interface to this subclause should also describe these parameters as being in luma samples.

In K1003-v9:

8.5.3 Decoding process for prediction units in inter prediction mode:

...

  • a variable nPbW specifying the width of the current prediction block,
  • a variable nPbH specifying the width of the current prediction block, ... Replace with: ...
  • a variable nPbW specifying the width of the current prediction block in luma samples,
  • a variable nPbH specifying the width of the current prediction block in luma samples, ...
#875 fixed 8.5.3.1.1 : singleMCLFlag = 1 leads to the same vector for every PB of the CB bbross Jing-Jing Chung
Description

In the 8.5.3.1.1 chapter, singleMCLFlag is used :

"When singleMCLFlag is equal to 1, xP is set equal to xC, yP is set equal to yC, and both nPbW and nPbH are set equal to nCS. NOTE – When singleMCLFlag is equal to 1, all the prediction units of the current coding unit share a single merge candidate list, which is identical to the merge candidate list of the 2Nx2N prediction unit."

At the end of the chapter we have:

"The following assignments are made with N being the candidate at position merge_idx[ xP][ yP ] in the merging candidate list mergeCandList ( N = mergeCandList[ merge_idx[ xP][ yP ] ] ) and X being replaced by 0 or 1: mvLX[ 0 ] = mvLXN[ 0 ] (8 79) mvLX[ 1 ] = mvLXN[ 1 ] (8 80) refIdxLX = refIdxLXN (8 81) predFlagLX = predFlagLXN (8 82)"

============ So when singleMCLFlag = 1, since xP=xC and yP=yC for every PB of the CB, in this case every PB of the CB has the same result : mvLX, refIdxLX, predFlagLX.

My understanding is that, according to the note, the aim of singleMCLFlag=1, is that every PB of the CB has the same candidate list, and not necessarily the same vector. Moreover, there is a value of merge_idx[][] for every PB of the CB in the bitstream and here we only use the first one of the CB.

My proposal is that the initial values of xP and yP are kept and used in merge_idx. The text would be modified this way :

Let's set xP_init to xP, and yP_init to yP. "When singleMCLFlag is equal to 1, xP is set equal to xC, yP is set equal to yC, and both nPbW and nPbH are set equal to nCS." ... "The following assignments are made with N being the candidate at position merge_idx[ xP_init][ yP_init ] in the merging candidate list mergeCandList ( N = mergeCandList[ merge_idx[ xP_init][ yP_init ] ] ) and X being replaced by 0 or 1:"

#757 fixed 8.5.3.1.7 unvalued refIdxCol and listCol used bbross conrad.ho
Description

The spec said: "The variables mvLXCol and availableFlagLXCol are derived as follows.

– If one or more of the following conditions are true, both components of mvLXCol are set equal to 0 and availableFlagLXCol is set equal to 0.

–colPb is coded in an intra prediction mode. -colPb is marked as "unavailable". –slice_temporal_mvp_enable_flag is equal to 0. –LongTermRefPic( currPic, refIdxLX, ListX ) is not equal to LongTermRefPic( colPic, refIdxCol, listCol ).

– Otherwise, the motion vector mvCol, the reference index refIdxCol, and the reference list identifier listCol are derived as follows.

..."

However, for the 4th condition, the values of refIdxCol and listCol are specified in "otherwise" part; thus LongTermRefPic(colPic, refIdxCol, listCol) is vague.

Note: See TracQuery for help on using queries.