Opened 13 years ago

Closed 13 years ago

#412 closed defect (fixed)

Deblocking processing order in Draft Text does not match HM

Reported by: pieterkapsenberg Owned by: bbross
Priority: minor Milestone: D7
Component: Text Version: D6 (H1003) dI/dJ/dK
Keywords: deblock deblocker order ordering Cc: bbross, wjhan, jct-vc@…

Description

The draft text specifies that for each CU in coding order (I assume this means the leaf CU, not the largest CU), first all vertical edges are filtered, then all horizontal edges are filtered. HM6.0 does all vertical edges for the whole picture first, then all horizontal edges for the whole picture. This is a different data dependency. For HM, all vertical edges use pre-deblocked pixels as input, whereas the draft spec suggests that the vertical filters may sometime use horizontally deblocked pixels as inputs. Which one is correct/intended? A picture-based ordering has buffer implications for hardware implementations.

Attachments (2)

JCTVC-H1003_dK_deblock_d4.zip​ (104.0 KB) - added by teruhiko 13 years ago.
The proposed draft to fix filtering process of deblocking filter
JCTVC-H1003_dK_deblock_d5.zip​ (103.9 KB) - added by teruhiko 13 years ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 13 years ago by DefaultCC Plugin

  • Cc bbross wjhan jct-vc@… added

comment:2 Changed 13 years ago by qhuang

There seems no conflict in the below sentence. Let's remove it.

"For HM, all vertical edges use pre-deblocked pixels as input, whereas the draft spec suggests that the vertical filters may sometime use horizontally deblocked pixels as inputs. Which one is correct/intended?"

Changed 13 years ago by teruhiko

The proposed draft to fix filtering process of deblocking filter

comment:3 in reply to: ↑ description Changed 13 years ago by teruhiko

I tried to clean up the text on deblocking filter to fix this problem.
Please check the attached document, JCTVC-H1003_dK_deblock_d4.zip
I hope this could resolve the inconsistency between HM6 software and the text.

Replying to pieterkapsenberg:

The draft text specifies that for each CU in coding order (I assume this means the leaf CU, not the largest CU), first all vertical edges are filtered, then all horizontal edges are filtered. HM6.0 does all vertical edges for the whole picture first, then all horizontal edges for the whole picture. This is a different data dependency. For HM, all vertical edges use pre-deblocked pixels as input, whereas the draft spec suggests that the vertical filters may sometime use horizontally deblocked pixels as inputs. Which one is correct/intended? A picture-based ordering has buffer implications for hardware implementations.

Changed 13 years ago by teruhiko

comment:4 Changed 13 years ago by bbross

  • Milestone changed from WD6 to D7

comment:5 Changed 13 years ago by bbross

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

Fixed in D7 (I1003) d2

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)
  • Pieter Kapsenberg(Reporter)
  • Qian Huang(Participant)
  • Teruhiko Suzuki(Participant)
  • Woo-Jin Han(Subscriber)