Opened 6 years ago
Closed 6 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)
Change history (6)
Changed 6 years ago by adamjw
comment:1 Changed 6 years ago by fbossen
comment:2 Changed 6 years ago by adamjw
As mentioned, I don't know how to resolve the third issue.
comment:3 Changed 6 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 6 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 6 years ago by ksuehring
- Resolution set to fixed
- Status changed from new to closed
MR 292 was merged
Could you submit the patch as a merge request? Thanks.