Opened 14 years ago

Closed 13 years ago

#128 closed defect (fixed)

Wrap-around problem with return variables from xCheckBestMVP

Reported by: nsprljan Owned by:
Priority: minor Milestone:
Component: HM Version: HM-3.4
Keywords: Cc: fbossen, ksuehring, davidf, jct-vc@…

Description

In some cases the ME (xMotionEstimation) is bypassed, but the function xCheckBestMVP is still invoked. In those cases the input variable uiBitsTemp holds the number of bits of the partition, but without the MV bits.

Here's what happens in xCheckBestMVP:

uiBitsTemp = uiBitsTemp - iOrgMvBits + iBestMvBits

where iOrgMvBits is the bit-cost when original predictor is used, and iBestMvBits is the bit-cost for the new best predictor. It can happen that the difference of the original MV bits and new MV bits is larger than uiBitsTemp. This results in wrap around to the values from the upper end of the UInt range. Consequently, ruiBits and ruiCost (uiBitsTemp and uiCostTemp) values returned from the function xCheckBestMVP are wrong. This may affect result of the selection of MVs since uiBits[iRefList] = uiBitsTemp, and uiBits is used later in mode selection. Probably has only a minor effect on the results as the conditions are relatively rare.

Attachments (1)

ticket-128bugfix.patch​ (2.5 KB) - added by nsprljan 14 years ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 14 years ago by nsprljan

Update on the conditions under which this bug affects the performance:

  • in the current default settings (HM 2.0) this bug will not affect the performance
  • if the first list in the bidirectional ME is changed to L0 (e.g. fast encoder is not used in the settings), the wrapped-around value saved in uiBits[1] will propagate to variable uiBitsTemp that is used in function xMotionEstimation, thus affecting the performance

Changed 14 years ago by nsprljan

comment:2 Changed 14 years ago by nsprljan

The bug described above reappeared again in HM3.0, but affects only RA configuration.

It does not occur often - only in the instances when a better than the initial MVP is found for L1 list references, and when the difference in bits is larger then the already counted bits. To detect it it is enough to set a breakpoint on bits counter in the MVP estimation function that triggers when it goes to negative value.

Patch that can be applied to HM-3.0 is attached (ticket-128bugfix.patch, should be fine for HM-3.1 too). Note that a simplex fix is possible where a negative value us prevented by clipping to zero, however that does not lead to a gain as with the provided fix.

The full sequence results obtained for HM-3.0-dev-bugfix indicate average gain of 0.1%:

Random access Random access LC

Y BDr U BDr V BDr Y BDr U BDr V BD-r

Class A -0.1 -0.2 0.1 -0.2 -0.3 -0.1
Class B -0.1 -0.1 0.0 -0.1 -0.1 0.0
Class C -0.1 0.0 -0.1 -0.1 -0.1 -0.2
Class D -0.1 -0.1 -0.3 -0.1 -0.2 0.0

All -0.1 -0.1 -0.1 -0.1 -0.2 -0.1

comment:3 Changed 13 years ago by fbossen

  • Resolution set to fixed
  • Status changed from new to closed
  • Version set to HM-3.4

Fixed in r1008

comment:4 Changed 13 years ago by davidf

  • Component set to HM

Updating component after adding WD (Text) tickets

comment:5 Changed 13 years ago by davidf

  • Cc fbossen ksuehring davidf added

comment:6 Changed 13 years ago by davidf

  • Cc jct-vc@… added
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

  • David Flynn(Subscriber, Participant)
  • Frank Bossen(Subscriber, Participant)
  • jct-vc@…(Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Subscriber, Always)
  • Nikola Sprljan(Reporter, Participant)