Opened 12 years ago

Closed 12 years ago

#844 closed defect (fixed)

Deblocking filter typos

Reported by: laurent.birtz@… Owned by: bbross
Priority: minor Milestone: HM-9.1
Component: Text Version: D9 (K1003) v9
Keywords: Cc: bbross, wjhan, jct-vc@…

Description

8.7.2.3: Derivation process of boundary filtering strength

"where xL is equal to
((( xC + xDi ) >> 3) << 3) + ((( xC + xDi ) >> 3) & 1) * 7"

Is this a removal oversight from Draft 9? The same condition was removed
from 8.5.3.1.2: Derivation process for spatial merging candidates.


8.7.2.4.3: Decision process for luma block edges

"The variable dqp is set equal to 2*dpq0."

Should be dpq instead of dqp.


8.7.2.4.5: Filtering process for chroma block edges

"Q = Clip3( 0, 53, QPC + 2 * ( bS − 1 ) + ( tc_offset_div2 << 1 ) )"

Should be qPi instead of QPC.


8.7.2.4.7: Filtering process for a luma sample

"each of the filtered sample values, pi' with i = 0..nDp−1, is
substituted by the corresponding input sample value pi"

Correct, but setting nDp = 0 is simpler.


8.7.2.4.1: Vertical edge filtering process:

Quoting the unanswered question from Harish Mahendrakar which seems
pertinent (I'd like to know the answer as well):

HEVC draft mentions a grid of 8x8 for chroma deblocking with filtering done for 4 pixels at a time.

What is the need for an 8x8 grid in chroma? Since chroma deblocking uses only 2 pixels each on both sides of the edge being filtered and only one pixel on each side is modified a grid of 8x8 is not needed. In luma filtering without 8x8 grid, all vertical edges (or all horizontal edges) cannot be filtered in parallel because, edge at a given 4 pixel boundary will need output from previous filter. But in chroma this problem does not arise because only one pixel on each side is modified. So 4x4 grid for chroma will not have any problems in multi-core implementation and also will ensure all intra edges (at luma 8x8 grid) will be filtered in both luma and chroma.

Or was 8x8 grid for chroma specified to keep the computational complexity down?

Change History (3)

comment:1 Changed 12 years ago by DefaultCC Plugin

  • Cc bbross wjhan jct-vc@… added

comment:2 in reply to: ↑ description Changed 12 years ago by bbross

Replying to laurent.birtz@…:

8.7.2.3: Derivation process of boundary filtering strength

"where xL is equal to
((( xC + xDi ) >> 3) << 3) + ((( xC + xDi ) >> 3) & 1) * 7"

Is this a removal oversight from Draft 9? The same condition was removed
from 8.5.3.1.2: Derivation process for spatial merging candidates.

(BB) Yes this part should be removed to as suggested by adopted JCTVC-K0101


8.7.2.4.3: Decision process for luma block edges

"The variable dqp is set equal to 2*dpq0."

Should be dpq instead of dqp.

(BB) Correct


8.7.2.4.5: Filtering process for chroma block edges

"Q = Clip3( 0, 53, QPC + 2 * ( bS − 1 ) + ( tc_offset_div2 << 1 ) )"

Should be qPi instead of QPC.

Actually QPC is correct since qPi is used to derive QPC to be used in the formula above.


8.7.2.4.7: Filtering process for a luma sample

"each of the filtered sample values, pi' with i = 0..nDp−1, is
substituted by the corresponding input sample value pi"

Correct, but setting nDp = 0 is simpler.

(BB) Agree, that would be consistent within the process. Changed it to:
"When nDp is greater than 0 and one or more of the following conditions are true for i = 0..nDp−1, nDp is set equal to 0."
and
"When nDq is greater than 0 and one or more of the following conditions are true for j = 0..nDq−1, nDq is set equal to 0."


8.7.2.4.1: Vertical edge filtering process:

Quoting the unanswered question from Harish Mahendrakar which seems
pertinent (I'd like to know the answer as well):

HEVC draft mentions a grid of 8x8 for chroma deblocking with filtering done for 4 pixels at a time.

What is the need for an 8x8 grid in chroma? Since chroma deblocking uses only 2 pixels each on both sides of the edge being filtered and only one pixel on each side is modified a grid of 8x8 is not needed. In luma filtering without 8x8 grid, all vertical edges (or all horizontal edges) cannot be filtered in parallel because, edge at a given 4 pixel boundary will need output from previous filter. But in chroma this problem does not arise because only one pixel on each side is modified. So 4x4 grid for chroma will not have any problems in multi-core implementation and also will ensure all intra edges (at luma 8x8 grid) will be filtered in both luma and chroma.

Or was 8x8 grid for chroma specified to keep the computational complexity down?

(BB) This is a design question and should be answered by JCTVC experts and not considered as a bug report.

comment:3 Changed 12 years ago by bbross

  • Resolution set to fixed
  • Status changed from new to closed
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

  • Benjamin Bross(Owner, Subscriber, Participant)
  • jct-vc@…(Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Always)
  • laurent.birtz@…(Reporter)
  • Woo-Jin Han(Subscriber)