Custom Query (1442 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (28 - 30 of 1442)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Ticket Resolution Summary Owner Reporter
#743 wontfix Deblocking filter : neighboring information bbross Jing-Jing Chung
Description

In chapter 8.7.2.3 : "derivation process of boundary filtering strength" of JCTVC-J1003_d7, we need to keep some prediction block informations to determine the bS of the current prediction block boundary : for example : prediction mode (inter/intra) , PartMode, motion vectors and reference pictures.

Let's consider the case where the current boundary is a prediction block boundary, and q0 and p0 are both coded with inter prediction.

====== For horizontal edge, if p0 and q0 do not belong to the same coding tree block (CTB), we may use another p0, not necessarily the top neighbor of q0 (See attached schematics):

"– When edgeType is equal to EDGE_HOR and yC + yDj − 1 is less than (( yC >> Log2CtbSizeY ) << Log2CtbSizeY), sample p0 = recPictureL[ xL ][ yC + yDj – 1 ] where xL is equal to ((( xC + xDi ) >> 3) << 3) + ((( xC + xDi ) >> 3) & 1) * 7"

My understanding is that, if we consider a deblocking process that works on picture CTB row basis, we only need to have from the top CTB row, at most 2 prediction block information per 16 pixel of horizontal boundary (instead of 4 at most). This is done to reduce bandwidth.

====== The current deblocking function has been optimized, in terms of bandwidth, for a CTB process in picture raster scan. This scan order is not the order used in the other functions of chapter 8.

The intention of our proposal is to reduce bandwidth when we are doing the deblocking filter in tile scan order (i.e. the same order as the other functions). The proposed idea is the same as the one used for horizontal edge.

Our proposal (to be done after the previous point on horizontal edge):

  • When edgeType is equal to EDGE_VER and TileId[ctbAddrTS_p0] is different from TileId[ctbAddrTS_q0], sample p0 = recPictureL[ xC + xDi - 1 ][ yL ]

where : yL = ((( yC + yDj ) >> 3) << 3) + ((( yC + yDj ) >> 3) & 1) * 7 ctbAddrTS_p0 = ctbAddrRStoTS[ ctbAddrRS_p0 ] ctbAddrRS_p0 = ((xC + xDi -1) >> Log2CtbSize) + ((yC + yDj) >> Log2CtbSize) * PicWidthInCtbsY ctbAddrTS_q0 = ctbAddrRStoTS[ ctbAddrRS_q0 ] ctbAddrRS_q0 = ((xC + xDi) >> Log2CtbSize) + ((yC + yDj) >> Log2CtbSize) * PicWidthInCtbsY

Note : this could also be done for slice vertical boundaries. Note that a slice vertical boundary that does not coincide with a tile boundary is only 1 CTB high.

Note 2 : In this proposal we do not take into account the potential quality loss on tile boundaries.

#816 duplicate 8.4.4.2.5 : wrong index for dcVal calculation bbross Jing-Jing Chung
Description

In chapter 8.4.4.2.5 of JCTVC-K1003_v4, the variable nS is used for the calculation of dcVal. nS is not defined in this chapter, but earlier as 1 << Log2CbSize. I think there is a typo there. nT (the transform block size) should be used instead of nS.

#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:"

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Note: See TracQuery for help on using queries.