View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000010 | JVT JM H.264/AVC reference software | encoder | public | 2006-08-16 17:27 | 2006-10-19 02:02 |
| Reporter | Karsten Suehring | Assigned To | Alexis Michael Tourapis | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | any | ||||
| Product Version | JM 10.2 | ||||
| Fixed in Version | JM 12.0 | ||||
| Summary | 0000010: JM10.2 encoder seems to output illegal WP values | ||||
| Description | Barry Haskell It seems to violate Eq. (8-294) | ||||
| Tags | No tags attached. | ||||
|
|
Alexis Tourapis: I believe you are correct. weighted_prediction.c has a simple check in the following form: if ( (wf_weight<-64) || (wf_weight>127) ) { wf_weight = default_weight[0]; } No other check seems to be performed, anywhere else in the software. The above seems to protect the negative case, but it is still possible for positive cases to exceed the proper limits. The best way to fix the software, would be to add additional checks within the encoder to send a high cost when the two sum of two weights creates issues. This would have to be done within functions "RDCost_for_8x8blocks", and "RDCost_for_macroblocks" and could be very similar to how we test for direct modes (see "direct_pdir" tests). That is, if the condition is exceeded, then the encoder should avoid checking this particular mode. I am extremelly busy right now so can't get to it right away, but can try to fix this in a couple of weeks. Unless of course someone else wishes to take a look at it. A simple alternative ("bad" in my opinion) hack would be to change luma_log_weight_denom to 5 (or smaller), and constraint wf_weight as to never create the problem. i.e., change above code to: //if ( (wf_weight<-64) || (wf_weight>127) ) //{ //wf_weight = default_weight[0]; //} wf_weight = clip3(-64,(luma_log_weight_denom == 7 ? 63 : 64),wf_weight); Since luma_weight_l0_flag is always set to 1 in the software (and we never use luma_log_weight_denom == 7), this would work ok without creating problems. Btw the text says the following about implicit WP (prior to eq 8-276) "If DiffPicOrderCnt( pic1, pic0 ) is equal to 0 or one or both of pic1 and pic0 is a long-term reference picture or (DistScaleFactor >> 2) < -64 or (DistScaleFactor >> 2) > 128, w0 and w0 are derived as:" Obviously the second w0 should be w1. |
|
|
Extended code to properly support WP. Instead of constraining weights as to always not exceed EQ. 8-294, tests are performed during encoding to penalize/avoid illegal coding modes. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-08-16 17:27 | Karsten Suehring | New Issue | |
| 2006-08-16 17:28 | Karsten Suehring | Note Added: 0000007 | |
| 2006-08-16 17:28 | Karsten Suehring | Status | new => confirmed |
| 2006-09-27 14:52 | Karsten Suehring | Status | confirmed => assigned |
| 2006-09-27 14:52 | Karsten Suehring | Assigned To | => Alexis Michael Tourapis |
| 2006-10-19 02:02 | Alexis Michael Tourapis | Status | assigned => resolved |
| 2006-10-19 02:02 | Alexis Michael Tourapis | Fixed in Version | => JM 11.0-devel |
| 2006-10-19 02:02 | Alexis Michael Tourapis | Resolution | open => fixed |
| 2006-10-19 02:02 | Alexis Michael Tourapis | Note Added: 0000012 |
