Opened 2 years ago

Closed 2 years ago

#164 closed defect (fixed)

Deblocking filter doesn't use correct data for IBC blocks

Reported by: adamjw Owned by:
Priority: major Milestone: VTM-4.0
Component: VTM Version:
Keywords: Cc: ksuehring, XiangLi, fbossen, jvet@…

Description

Please find the attached patch.

The "sameCu" short-cut compares luma-coordiantes with chroma-coordinates and is thus always true for 420, giving the wrong neighboring CU cuP.

The same problem occurs for the tuP/tuQ shortcuts.

Last but not least, when obtaining MotionInfo, miQ and miP, the function that takes luma coordiantes gets chroma coordinates. As far as I could trace it, the chroma motion info is not written into any motion buffer. I don't know the intended behaviour, so I post this as an open question. For this reason, I'm also not doing a merge request.

Attachments (1)

IBC_LoopFilter.diff (2.4 KB) - added by adamjw 2 years ago.

Download all attachments as: .zip

Change history (6)

Changed 2 years ago by adamjw

comment:1 Changed 2 years ago by fbossen

Could you submit the patch as a merge request? Thanks.

comment:2 Changed 2 years ago by adamjw

As mentioned, I don't know how to resolve the third issue.

comment:3 Changed 2 years ago by fbossen

  • Priority changed from minor to major
  • Summary changed from Possible loop-filter/CPR interaction problem to Deblocking filter doesn't use correct data for IBC blocks

comment:4 Changed 2 years ago by kiranmisra

Proposed fix that includes the TU/CU get fix from merge request 249. As I understand, per M0471, chroma boundary strength is not impacted by MV/RefPic.

https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/292

comment:5 Changed 2 years ago by ksuehring

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

MR 292 was merged

Note: See TracTickets for help on using tickets.