Opened 5 years ago
Closed 5 years ago
#691 closed defect (fixed)
issue in pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 in constant-slice setting
Reported by: | ccc2384823 | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | spec | Version: | VVC D7 vE |
Keywords: | Cc: | ksuehring, bbross, XiangLi, fbossen, jvet@… |
Description
Description :
The pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 is possible to be conflict with ph setting of max_num_merge_cand_minus_max_num_triangle_cand
For one example, if setting pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 to 5 => will implicitly force ph level to be 5-1 = 4
And,
MaxNumTriangleMergeCand =
MaxNumMergeCand − pic_max_num_merge_cand_minus_max_num_triangle_cand
Therefore, for one certain picture (refer to current pps), if accidently setting MaxNumMergeCand = 3 in this picture ->
MaxNumTriangleMergeCand = 3 – 4 = -1, that is illegal and un-defined for this picture.
Suggested fix:
Modifiy this sentence in semantices (of pic_max_num_merge_cand_minus_max_num_triangle_cand) :
When MaxNumTriangleMergeCand is equal to 0, triangle merge mode is not allowed for the slices associated with the PH.
=>
When MaxNumTriangleMergeCand is <= 1, triangle merge mode is not allowed for the slices associated with the PH.
By the modification, the error example will become valid now.
Change history (10)
comment:1 Changed 5 years ago by ccc2384823
- Version changed from VVC D7 vB to VVC D7 vC
comment:2 Changed 5 years ago by yjchang
comment:3 Changed 5 years ago by bbross
- Version changed from VVC D7 vC to VVC D7 vD
comment:4 Changed 5 years ago by ccc2384823
I agree, sorry for my wrong example, but I agree with your concern that, "how pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 understands the value of MaxNumMergeCand, which might be different values in different PHs." Therefore, it's strange to put the MaxNumMergeCand in the constraint of semantics of pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 .
Moreover, this concern has been addressed in the proposal : JVET-P0427 in last meeting.
The current semantics constraint of pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 will result that, when setting pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1, it need to make sure every MaxNumMergeCand value of all associated picture header (belonging to the pps), that's strange and complicated.
It's suggested to remove the constraint of MaxNumMergeCand in the semantics of pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1, and only modify a few characters in semantices (of pic_max_num_merge_cand_minus_max_num_triangle_cand) :
Suggested fix:
Modifiy this sentence in semantices (of pic_max_num_merge_cand_minus_max_num_triangle_cand) :
When MaxNumTriangleMergeCand is equal to 0, triangle merge mode is not allowed for the slices associated with the PH.
=>
When MaxNumTriangleMergeCand is <= 1, triangle merge mode is not allowed for the slices associated with the PH.
Therefore, by only modifying several characters, we can solve the strange-constraint in semantics of pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1, and also making sure there is no bug when wrong setting, and it's conceptually very clear to do final checking ( MaxNumTriangleMergeCand is <= 1 -> turn off TPM)
comment:5 Changed 5 years ago by bbross
- Version changed from VVC D7 vD to VVC D7 vE
comment:6 Changed 5 years ago by yjchang
Thanks for what you agree on the comments to the current design.
However, I disagree the solution you provided, which will add a new feature to the current design to allow some PHs to totally disable triangle merge mode even if the regular merge list is enough (the number of merging candidates is larger than or equal to 2). Your design would cause performance loss, and no one is gonna use this feature.
Back to the issue we are discussing, why are you not addressing this from the beginning, e.g., PPS. Several 1-line simple solutions can address this issue without adding any unnecessary features for nothing. One example is adding a conformance to disallow pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 to be larger than 0 if pps_six_minus_max_num_merge_cand_plus1 is 0.
comment:7 Changed 5 years ago by zhou
This dependent signaling of max_num_merge_cand and max_num_triangle_cand in the current design seems to be no good after introduction of picture header, maybe it is time to re-evaluate the idea discussed during the March'19 Geneva meeting, i.e.
1) having the regular merge list derived for 6 candidates all the time regardless of signaled max_num_merge_cand.
2) having independent signaling of max_num_merge_cand and max_num_triangle_cand.
This looks like an HLS topic for the next meeting to see if a cleaner design exists.
comment:8 Changed 5 years ago by jeromnhsu
@yjchang:
It is not a new feature to allow PH to disable TPM even if the regular merge number is enough.
From the semantics of pic_max_num_merge_cand_minus_max_num_triangle_cand in current spec, no matter how you set the syntax, if MaxNumTriangleMergeCand is equal to 0, it is to disable TPM.
However, I agree with you that forcing both pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 and pps_six_minus_max_num_merge_cand_plus1 to be 0 is a possible solution, which implies determining both syntax either in PPS or in PH together. Another possible way is what I comment in the following.
@zhou:
I think in PH these syntax won't introduce any ambiguity or issues in current spec. So it may not be necessary to go back to your two solutions (I am ok to reopen these if other concerns). The problem is caused by constant slice parameter in PPS. So, one possible solution is to remove pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 from constant slice parameter or simply just remove all of them.
comment:9 Changed 5 years ago by yjchang
The new feature comes from the wrong design in pic_max_num_merge_cand_minus_max_num_triangle_cand, and again, no obvious benefit for this new feature. When reviewing the final HLS BoG adoptions, Gary and experts already made decision to fix the bugs if there is bugs in constant picture parameters scheme, instead of simply removing it. It is ridiculous that constant picture parameters can give you benefits, and you want to remove some parameters from it just because of a small bug, which actually can be fixed.
However, I will have no opinion if people want to remove all of this scheme if you can provide some insights and show that it is useless in the current PPS-PH structure. You might need to take a look into O0238 which shows some compression gain due to the design.
Regarding reopening the issue what Minhua brought up, I think he is talking about the contributions N0851 and N0447. If the group feel it is still interesting, as a proponent I can bring the contribution again next Brussel meeting. However, before that, could Minhua explain more on the motivation?
comment:10 Changed 5 years ago by bbross
- Resolution set to fixed
- Status changed from new to closed
Thanks for reporting!
This has been fixed in JVET-Q2001-v7.
In the semantics of pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1, there is a conformance as below:
"The value of pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 shall be in the range of 0 to MaxNumMergeCand − 1."
Therefore, your example, i.e., MaxNumMergeCand = 3 and pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 to 5, is not allowed now.
I think the issue here is how pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 understands the value of MaxNumMergeCand, which might be different values in different PHs.